gate
Run the one-command quality gate and report the real N/N result. Use before claiming any build/review is done.
Adversarial design critique of the current work — render it, look at it, and argue for rejection. Run after the gates are green, never instead of them.
> /plugin marketplace add plugin87/ux-ui-agent-skills > /plugin install ux-ui-agent-skills@ux-ui-agent-skills
How it fires
How this command gets triggered: by you, by Claude, or both.
/critiqueContext preview
What this command does when you run it.
Adversarial design critique of the current work — render it, look at it, and argue for rejection. Run after the gates are green, never instead of them.
description: Adversarial design critique of the current work — render it, look at it, and argue for rejection. Run after the gates are green, never instead of them.
The gates prove objective correctness. They cannot tell you whether the work is any good. This command closes that gap the only honest way: render the thing, look at it, and let a critic who is trying to reject it write the findings.
Target: `$ARGUMENTS` (a file, a directory, or the screens changed in this session; ask if it is ambiguous).
If the target has never been rendered, render it first. A critique written from source alone is worthless. Screenshot every screen or harness at 1280 and 390 wide, in light and dark, pointer parked off the UI, then click every control and note what actually changed.
node scripts/taste_audit.mjs <file> && node scripts/taste_audit.mjs <file> --dark node scripts/slop_tells.mjs <file> && node scripts/slop_tells.mjs <file> --dark node scripts/verify_overflow.mjs <file|dir> node scripts/verify_responsive.mjs <file|dir>
Report their real output. These are heuristics: they name what you saw, they do not decide whether it is good.
Delegate to the `design-critic` subagent with the screenshots, the script output, and the file paths. Its stance is adversarial on purpose: the work is mediocre until the render proves otherwise, a passing gate is never evidence of taste, and every finding must name its evidence.
If subagents are unavailable, adopt `.claude/agents/design-critic.md` yourself and follow it literally, including the verdict format.
Relay the verdict, the three rejection reasons, and the findings table as written. Do not soften it, and do not pad the "what is good" list.
Then act on it: fix every Critical and Major finding, re-run `/gate`, and re-run this critique on what changed. The loop ends when the critic's remaining findings are Minor or Enhancement, not when you are tired of it.
Honest scope, always stated with the result: this is judgement, not measurement. It does not produce a percentage, and no percentage in this repo covers taste.
Turn Claude into a senior design architect - DTCG design tokens, 50 components, WCAG 2.2 AA to AAA, 138 design systems, any-framework code, and 38 objective gates that fail the build instead of claiming success. Install as a Claude Code plugin or with npx.
Repo: plugin87/ux-ui-agent-skills
Run the one-command quality gate and report the real N/N result. Use before claiming any build/review is done.
Interrogate the brief before a line is built — ask only the questions whose answers change the work, and put every unasked decision on the record as a stated…
Scaffold a new design-product project that matches the recommended Claude Code layout (the reference structure). Use when starting a fresh product/app that…