-
Notifications
You must be signed in to change notification settings - Fork 6
FAQ
Practical answers for people arriving from a code search or a fresh clone. For the longer product and comparison FAQ, see https://uxskill.laithjunaidy.com/faq.html. For a walkthrough, see Getting Started.
A design-intelligence engine for AI coding tools that makes their generated UI distinctive instead of generic. It is a Python package, an MIT-licensed open-source project, it runs fully offline, and it never calls an LLM.
The engine itself is deterministic Python over versioned JSON data. When you run ux recommend or ux lint, no network request is made and no model is invoked; the same input always yields the same output. The AI coding tool you already use (Claude Code, Cursor, and so on) is still the thing that writes code. ux-skill is the layer that constrains and checks that tool. So there are two parts: your assistant does the generation, and ux-skill supplies the structure and the verification around it.
Seventeen: Claude Code, Cursor, Windsurf, GitHub Copilot, Gemini CLI, Codex, Kiro, Cline, Continue, Aider, Zed, JetBrains AI, Pieces, Tabby, Tabnine, CodeWhisperer, and Roo Cline. The same engine sits behind all of them; uxskill init detects which one you are in and installs the matching artifact. If your tool reads a rules or instructions file (most do), the linter and guardrails are usable even where deep slash-command integration is not.
A prompt lives inside one session, drifts as the context fills, and varies run to run. ux-skill is a versioned engine with 12 data manifests, 25 commands, and a deterministic linter. The recommendation is reproducible across machines and the linter exits with a real status code, which a prompt cannot do. Put simply: a prompt is advice the model may forget; this is structure the model works inside, plus a check that runs in CI.
Those are runtime dependencies you import and ship. ux-skill ships nothing into your bundle. The components manifest (148 entries) is a specification the engine reasons over to direct generation; it is not code you install. You can use ux-skill alongside any component library or design system you already have, including generating new components that respect an existing one.
No to all three. There is no sign-up, no key, and no data leaves your machine. Any learning the engine does, through the local decisions ledger at .ux/decisions.jsonl, stays in your project. There is no global aggregate and nothing is phoned home.
They are the same binary. The package installs both as entry points so you can type whichever reads better. ux lint . and uxskill lint . do the same thing.
The brand is ux-skill (with a hyphen). The installable package on both PyPI and npm is uxskill (no hyphen). The GitHub repository is Laith0003/ux-skill. They all refer to the same project.
Three paths. In Claude Code, use the marketplace: /plugin marketplace add Laith0003/ux-skill then /plugin install ux@ux-skill. Anywhere with Python: pip install uxskill then uxskill init. With no Python to manage: npx uxskill init, which bootstraps pipx on first run. Full detail on the Getting Started page.
Run ux stats (or /ux-stats in Claude Code). It prints the version and the entry counts for the core manifests. At v3.1.0 you should see 84 styles, 176 palettes, 70 type pairs, 148 components, 184 industries, 35 chart types, 25 tech stacks, 112 UX laws, 57 motion presets, 152 anti-patterns, and 160 brand specs. A count of zero means a data file failed to load.
That means the JSON file behind that manifest did not load, usually a partial install or a packaging issue. Reinstall with pip install --upgrade --force-reinstall uxskill, run ux stats again, and if it persists, open an issue with the full ux stats output at https://github.com/Laith0003/ux-skill/issues.
Yes. The linter is standalone and is the most common entry point for existing codebases. uxskill lint . scans the current directory; bash bin/ux-lint.sh --ci --fail-on high is the CI form. It reports findings and never edits your files. The 152 rules are documented on the Anti-Patterns Reference page.
It might be. The linter is regex-based and tuned to avoid firing on legitimate code, but false positives happen. If a rule fires on code you are confident is correct, that is worth an issue, including the snippet and the rule id, at https://github.com/Laith0003/ux-skill/issues. False-positive reports directly improve the rule set.
Both. /ux-design handles full pages and app shells, /ux-component handles single components with all four interaction states, and /ux-dashboard is a dedicated path for data-dense surfaces with tabular numerals and sparing motion rather than a marketing layout. The recommender adapts to the project type you give it in discovery.
The README ships in 17 languages, and the engine is region-aware: discovery has a region field, and the recommender uses it to shape guardrails and exemplars. Right-to-left support is treated as first-class rather than an afterthought, which matters for Arabic and other RTL markets.
Nothing. It is free and MIT-licensed. The cheapest way to support the project is a star on GitHub, which is how others find it.
The highest-value contributions are new brand specs, new anti-pattern rules (each with a detection signature, a reason it reads as slop, and a fix), and false-positive reports against the linter. Open an issue or a pull request at https://github.com/Laith0003/ux-skill. See also the contributing notes in the README.
Open an issue at https://github.com/Laith0003/ux-skill/issues. Browse examples at https://uxskill.laithjunaidy.com/showcase.html. The full reference is the README, and the longer product FAQ is at https://uxskill.laithjunaidy.com/faq.html.