critique
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.
mkdir -p ~/.claude/commands && curl -fsSL https://raw.githubusercontent.com/plugin87/ux-ui-agent-skills/HEAD/.claude/commands/critique.md -o ~/.claude/commands/critique.mdcritique.md
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). ## 1. Refuse to critique blind 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. ## 2. Gather the numbers the critic will need ``` 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. ## 3. Hand it to the critic 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. ## 4. Report, then decide 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.
Audit a UI or design against WCAG 2.2 AA/AAA and ARIA patterns, returning criterion-referenced findings with severity and specific fixes. Use when the user wants an accessibility check, contrast verification, keyboard/screen-reader review, or wants to confirm a component meets POUR.
Apply a visual direction — an archetype (high-end agency, editorial minimal, brutalist, soft-SaaS, dark-tech) or one of 138 named design systems (apple, linear-app, stripe, vercel, notion, material, shadcn, spotify, tesla…) — by resolving it into the token system. Use when the user wants a specific look/vibe/brand feel, or asks to make a design feel premium/expensive/non-generic.
Generate a complete, accessible brand design system from a brief — primitive → semantic → component DTCG tokens (color, type, spacing, radius, shadow, motion), light + dark, plus a single theme.css — verified for WCAG. Use when the user wants a from-scratch brand/design foundation, a new palette + type system, or a themeable token kit for a product.
Generate production-ready, accessible, token-driven component code for ANY framework — React+Tailwind, Next.js, SwiftUI, Vue, Svelte, Angular, Solid, Web Components/Lit, React Native, Flutter, Jetpack Compose, vanilla CSS, or CSS-in-JS. Use when the user wants working UI code for a component or screen in a specific stack.
Design a UI component spec to the house quality bar — anatomy, variants, sizes, the 8 states, token mapping, and accessibility. Use when the user wants to design or document a component (button, input, tabs, toast, combobox, date picker, modal, etc.) at the spec level before or alongside code. For generating framework code, use design-code.
Set up or run design QA gates — token + hardcoded-value lint, automated a11y (axe), contrast, visual regression across variants/states/themes/RTL, and the manual a11y checklist. Use when the user wants CI quality gates, to prevent design regressions, or to QA a component/screen before shipping.
Review or audit a design/UI across 6 weighted dimensions with Nielsen's 10 heuristics and a prioritized findings table. Use when the user wants a design critique, quality score, heuristic evaluation, or audit of an existing screen, page, or product before/after build.
Generate, extend, or audit design tokens in DTCG format with the 3-tier architecture (primitive → semantic → component). Use when the user wants a color palette, type scale, spacing/shadow/radius/motion tokens, multi-brand theming, or wants to validate token files. Covers colors, typography, spacing, shadows, borders, breakpoints, motion, gradients, opacity, blur, sizing, states, theming.