There are now dozens of AI skills, extensions, and plugins for front-end and UI/UX work, and installing them is free. So most people install all of them. That instinct is what broke our stack.
I run operations for several companies as a fractional COO, and front-end work stopped being occasional this year. A dashboard redesign is gating a rebuild, one product has an open component-library branch, and this site needs a second content wave. All of that gets executed through AI skills, and the skill layer underneath it had never been audited. So we audited it, in a project we called FEDAudit, and the result was not what I expected. The tools were mostly good. The stack was still unreliable.
This article is the audit process, written so you can run it on your own stack. It also answers the two questions everyone asks when they see the list: which UI/UX tool is actually best, and why not just install all of them.
The problem is collision, not quality
The first thing we did was generate an inventory instead of writing one from memory. That machine registered 181 distinct skills. Of those, 41 scored as front-end or UI/UX relevant, and about 15 survived a reading of what they actually do. Those 15 names spanned 18 registrations, because two of them existed on more than one surface at once.
Two findings landed before we opened a single tool.
One skill named frontend-design existed as three different files under one name: a workspace copy, a marketplace copy, and an app-bundled copy. The session resolves exactly one of them. The other two are dead weight competing for the same trigger, and nothing tells you which one you got.
The second finding was worse. The best tool in the set, a UI polish skill with 110 files of real tooling behind it, carried an 895-character description that named 13 of the 20 jobs we had defined. Redesign, components, tokens, accessibility, typography, color, motion, dashboards, critique, UX copy, responsive behavior, anti-patterns, design systems. That is not a description. It is a claim over the whole domain.
Once we mapped every tool’s description against a fixed 20-job taxonomy, the shape of the problem was undeniable: 14 of 20 jobs were contested, 5 were clean, 1 was uncovered. Six different tools claimed “critique this page.” Five claimed “handle design tokens.” The collision was not a handful of duplicates. It was the normal condition of the namespace.
Why installing all of them makes output worse
The instinct to install everything assumes tools compose. In an AI stack they compete. Five specific costs, all of which we measured.
The router selects on description, not on quality. Your model picks a skill by reading descriptions and matching them to your request. A tool claiming 13 of 20 jobs wins nearly every routing decision by default, which means the specialists you installed never fire. You are paying for coverage you cannot reach.
Duplicate names silently resolve to one file. Three copies of frontend-design, one winner, no notification. You cannot debug behavior you cannot attribute.
More checkers destroy attribution. When three tools flag overlapping issues, you get a number you cannot act on. On our real dashboard run, the raw output was 48 findings. Grouped by rule rather than by file, 36 of them were a single contrast rule, and that rule traced to four token values. Forty-eight problems and four problems are different projects.
Silent degradation scales with tool count. The polish skill’s HTML analysis needs four parser packages. None were resolvable on that machine, the skill ships no manifest declaring them, and the code wrapped the import in a bare catch that fell back to plain text matching. Every HTML scan in the project had been running the degraded path. Re-measured with parsers installed, a test fixture went from 2 findings to 8, and one file that had reported a clean 0 was actually carrying 5, including two instances of the exact anti-pattern the skill exists to ban. We filed that upstream.
A skipped tool and a clean tool both report zero. This is the failure mode that should scare you most. Our own composed review skill listed which legs were skipped but said nothing about which legs ran, so a check that executed and found nothing looked identical to one that never executed. More tools means more legs, and more legs means more zeros you cannot interpret.
The rule we ended on: every tool you add should be paid for by a retirement, and every job should have exactly one primary owner among the tools you control. Not because tools are expensive. Because ambiguity is.
So which UI/UX tool is best?
There is no single best one, and any article that names one is selling something. What there is, after we ran controlled evaluations, is a clear winner per job. Each of these was tested against an oracle matched to what the tool actually claims to do, not against a generic rubric.
| Job | What wins | Evidence from our evals |
|---|---|---|
| Mechanical accessibility scanning | AccessLint (scan, diff, audit) | Computes against the rendered page. Found a gray that passes on white at 4.61:1 and fails on the app canvas, which a source review calls compliant |
| Anti-pattern detection in generated UI | impeccable | Rewriting a deliberately bad page: 8 banned patterns without the skill, 0 with it |
| Retrieving real design references | ui-ux-pro-max | 4 of 4 hex values traceable to a corpus row, versus a plausible but entirely invented palette without it |
| Phased, implementation-ready redesign plan | design-audit | 3 distinct phases versus 0, and 40 concrete CSS properties versus 9 |
| React performance | react-best-practices | Uncontested. Nothing else in the set claims it credibly |
| Design token enforcement | Nothing existed, so we wrote it | All five token tools define or extract. None enforce. That was the one real gap |
| One reconciled number for a merge gate | Nothing existed, so we wrote it | 6 of 6 recall on seeded defects, identical across 3 runs |
Read that table twice and the actual answer appears. The best tool for a job is the one with the narrowest description that still covers it. Breadth in a description is not capability. It is interference. The tool that claimed 13 jobs kept every one of its 24 commands and all 32 reference files after we narrowed its description to 2 jobs. Nothing was lost. It simply stopped winning arguments it should not have been in.
How to run this audit on your own stack
Nine steps. Steps 1 through 5 are where nearly all the value is; do not skip ahead to authoring new tools.
1. Generate the inventory, never write it
Script a pass over every directory your assistant loads skills from and emit structured data: name, path, surface, description, file count, size. Then treat that file as the source of truth. When a number in a document disagrees with it, the file wins and the document gets corrected.
Do not trust the script on the first run. Ours parsed description: with a flat regex, so the 33 skills using a YAML block scalar had their entire description reduced to a single character. That silently undercounted the in-scope set until an independent reader disagreed with the tool and the tool turned out to be wrong.
2. Sort by what you can actually change
This step saves you from planning work you are not permitted to do. Ours split three ways:
| Surface | Registrations | What you can do |
|---|---|---|
| Your own workspace | 7 | Edit, retire, retune. Full control |
| App-bundled | 8 | Nothing. Read-only cache |
| Plugin marketplace | 3 | Fork only. An update overwrites your edits |
Only 7 of 18 were editable. That is a hard ceiling on what any de-confliction plan can achieve, and it is much better discovered at the start than at verification. A job whose claimants are all read-only cannot be fixed. It can only be routed around by sharpening the tools you do own.
3. Define jobs, not categories
Write a fixed taxonomy of the jobs you actually need done, in the vocabulary of the work rather than the vocabulary of the tools. We used 20 and later split two of them into 24. Examples: greenfield build, redesign polish, component library wiring, mechanical accessibility scan, typography correctness, palette selection, motion transitions, React performance, responsive verification.
The taxonomy is the whole instrument. Get it from your open work, not from vendor marketing.
4. Build the trigger matrix
For every tool, against every job, mark whether its description claims that job as primary or merely touches it as secondary. Descriptions only. Do not read bodies yet; the router does not read bodies either, so a body-based map measures the wrong thing.
Then invert it: for each job, list the primary claimants and count them. Any job with two or more is contested. Any job with zero is a candidate gap. This inversion is the single most useful artifact of the entire audit.
5. Route, then narrow
Now assign exactly one primary owner per contested job, among the tools you control, and rewrite the losers’ descriptions to say what they do not do. Two things make this work.
Rewrite all descriptions in one pass, against one shared boundary map. Written one at a time, disclaim lines contradict each other. Written together, they interlock. We rewrote 18 in a single sitting for exactly this reason.
Split jobs that are secretly several jobs. Our “critique this live page” job had six claimants, and they were not duplicates. They were heuristic critique, mechanical rule scanning, and functional QA wearing one label. Splitting the job into three gave three tools a clean home each. Our “design tokens” job split into define, extract, and enforce, and that split is what revealed the only real gap in the stack.
6. Use gates before authoring anything new
A gap becomes a new tool only if it clears every gate, and the default answer at gate two is “ship it as a reference file inside a tool you already have.”
| Gate | Test |
|---|---|
| Uncovered | No existing tool claims it as primary |
| Non-mergeable | It cannot live as a reference file inside a keeper |
| Separable trigger | You can write ten positive and ten near-miss prompts a human can label correctly |
| Recurrence | It shows up in at least two live workstreams, not one |
| Checkable payoff | Success is countable, not a matter of taste |
We ran this on our entire gap list and it approved exactly two new tools out of a charter that predicted more. One candidate got demoted from a tool to a reference file inside another tool, which is a real win: it kept the content and avoided adding a sixth claimant to an already crowded job.
7. Retune what you adopt, before you install it
Vendored tools arrive with defaults set for their author’s machine, not yours. Two changes we made before anything went live.
One tool fetched its rule set from a public URL at runtime. That made it useless offline, made every review depend on a third party staying up, and leaked what we were working on. We vendored the rules at a pinned commit and deleted the fetch.
Another shipped an always-on trigger instructing the model to apply every typography rule silently on any file containing visible text, whether or not the user mentioned typography. That would have fired on nearly every front-end task and undone the routing work in step 5.
Record both changes as intentional divergence, with the original upstream hash preserved, so your drift checker does not confuse a deliberate retune with an accidental edit.
8. Verify routing with queries you did not write
This is where most audits quietly cheat. Our first routing test scored 63 of 63, and it was nearly worthless: I wrote both the descriptions and the test queries, so it measured internal consistency rather than routing.
The fix has three parts. Restate each job in deliberately neutral vocabulary that borrows nothing from any description. Have a separate model that has never seen the descriptions generate realistic user messages from those restatements. Then run a second, independent pass that routes those messages against the descriptions.
That corpus scored 36 of 36, and the queries visibly reached for tool names, library names, and file paths that appear in no description anywhere. Combined across both corpora: 99 of 99. Hold that loosely, since 99 queries across 18 tools is about five each, which catches gross overlap but not subtle bias.
9. Prove each keeper earns its place
For every tool you kept, run the same task twice against the same fixture with the same model, changing only whether the tool’s content is in context. Then grade against an oracle that matches the tool’s actual claim.
Mechanical tools get a seeded-defect sandbox: a page with a known, countable number of individually planted defects and a ground-truth file. Compute the expected values independently before seeding, so the answer key does not come from the tool being tested. Grading becomes counting rather than judgment, which is the entire reason to seed rather than to hunt.
Craft tools need an oracle chosen per claim. A tool that claims it avoids banned patterns gets checked against its own published ban list. A tool that claims it retrieves real references gets every returned value traced back to a corpus row. A tool that claims it produces phased plans gets counted for phases. Run at least two baseline samples; one is too thin to separate signal from variance.
What the audit produced
Ten adopted tools installed, two authored, one retired, one demoted to a reference file inside another. Eighteen descriptions rewritten in one interlocking pass. The keystone change, narrowing one description from 13 claimed jobs to 2, resolved or reduced contention on 11 of 24 jobs by itself and was the highest-value edit in the project.
Then we pointed the result at real work: nine dashboard mockups awaiting sign-off, carrying 48 accessibility findings.
| Step | Result |
|---|---|
| Print the project’s real tokens before writing any value | 53 tokens across 2 files |
| Baseline scan | 48 findings, 36 of them one contrast rule |
| Diagnose by computing every token against both backgrounds | 4 token values responsible |
| Fix, luminance only, hue and saturation preserved | 4 values changed |
| Verify | 48 findings to 17. Contrast 36 to 5 |
Thirty-one violations removed by changing four numbers. The biggest cluster was the link blue, not the muted gray I had confidently told everyone it was after the first look. That correction only exists because the tool computed ratios against the rendered background instead of reading the source.
Every number was wrong on the first run
The most durable lesson from FEDAudit has nothing to do with design tools. Every parser written in that project was wrong the first time it ran, and every one was caught by checking a count against something known.
The inventory parser flattened 33 descriptions to a single character. A CSS regex used \s* for trailing whitespace, swallowed the newline plus the next line’s indentation, and dropped every second declaration, costing 17 of 53 tokens. The token reader’s directory list omitted a bare tokens/ folder at the project root, which is one of the most common layouts there is, so our own test sandbox could not find its own token file.
The best of them was the verification run that reported 48 findings before the fix and 48 after. The fix had not failed. Chrome was reusing cached CSS between runs, so the audit was measuring the old stylesheet. That is worse than a false pass: a stale cache means a fix looks like a no-op and a regression looks clean. It was caught only because a zero delta across nine pages was implausible enough to check rather than report.
If you take one habit from this, take that one. When an automated number looks plausible, verify it against an oracle you computed yourself. The same discipline applies to any AI workflow you are considering buying, which is the subject of a companion piece on how to evaluate AI workflows before you buy.
Common mistakes
- Installing on capability and never on boundary. A tool that does ten things well will beat nine specialists to every request. Judge the description, not the feature list.
- Auditing bodies instead of descriptions. The router reads descriptions. A map built from source code measures something your assistant never sees.
- Writing disclaim lines one tool at a time. They only interlock if written together against a shared map. Sequential edits produce contradictions.
- Authoring a new tool for every gap. Most gaps are reference files inside tools you already own. Ours approved two out of a much longer candidate list.
- Grading your own routing test. If the person who wrote the descriptions also wrote the queries, the score measures vocabulary echo. Get an independent author.
- Trusting a zero. Distinguish “ran and found nothing” from “never ran” in every report you generate, or the report will eventually lie to you in the direction you least want.
FAQ
How many AI design tools should I actually have installed? As many as you have distinct jobs, and no more. Our working rule is one primary owner per job among the tools you control, with every addition paid for by a retirement. Raw count matters less than whether any two tools compete for the same request.
Which AI UI/UX tool is the single best one? None of them, and the question itself causes the problem. Mechanical accessibility scanning, anti-pattern detection, reference retrieval, and phased redesign planning are four different jobs with four different winners. Pick per job, then narrow every description so the pick actually holds at runtime.
Why can’t I just install everything and let the model choose? Because the model chooses by reading descriptions, and overlapping descriptions make that choice unpredictable. In our stack one tool’s description claimed 13 of 20 jobs, which meant the specialists we had installed almost never fired. Installing more tools reduced our effective coverage.
How long does an audit like this take? Ours ran as a focused project with roughly nine phases, and the highest-value hours were the inventory, the trigger matrix, and the single pass rewriting all descriptions together. A smaller stack of ten to fifteen tools can get through steps 1 to 5 in a day if the inventory is scripted rather than hand-written.
What if most of my tools are read-only and I cannot edit them? That was our situation: only 7 of 18 registrations were editable. You cannot de-conflict a job whose claimants are all read-only. You can only sharpen the descriptions of the tools you do own so nothing of yours competes, and then document the remaining contention as a known limit rather than pretending it is solved.
Does this apply outside of design tools? Yes. The same collision appears in any stack where an AI assistant selects among overlapping capabilities: research, finance, document generation, sales. The inventory, the job taxonomy, and the one-owner-per-job rule transfer directly. The setup for that broader picture is in the practical AI stack.
