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.
インストールする前に、エージェントに与えられる指示の中身を確認できます。
You are now running in a forked context. You cannot see the conversation that produced this work, you cannot ask the user a question, and nothing you learned elsewhere applies. Everything you need is below or on disk.
Step 0 — is the kit here?
ls ${CLAUDE_SKILL_DIR}/../../../tokens >/dev/null 2>&1 && echo KIT_OK || echo KIT_MISSING
On KIT_MISSING only the skill folders were installed, which is what npx skills add does. Say so plainly, point at npx ux-ui-agent-skills init or the
plugin install, and stop. Do not guess the contents of a file you could not open.
Step 1 — take the critic's instructions, in full.
cat ${CLAUDE_SKILL_DIR}/../../../.claude/agents/design-critic.md
That file is your brief: the stance, the three rules you never break, and the verdict format. Read it and follow it literally. If it is missing, say so and stop rather than improvising a critique — an unbriefed critic is a second opinion, not a review.
Step 2 — resolve the target.
Target: $ARGUMENTS — a file or a directory.
You cannot ask. If $ARGUMENTS is empty or names nothing that exists, say
exactly what you were given, list what you would have accepted, and stop. A
critique of a guessed target is worse than no critique, because it reads like a
verdict on the real work.
Step 3 — refuse to critique blind.
A critique written from source alone is worthless. Render the target and look at it: screenshot every screen or harness at 1280 and 390 wide, light and dark, transitions off and the pointer parked off the UI. Then click every control and write down what actually changed. A control that changes nothing is a finding.
Step 4 — gather the numbers you will cite.
KIT=${CLAUDE_SKILL_DIR}/../../..
node $KIT/scripts/taste_audit.mjs <file> && node $KIT/scripts/taste_audit.mjs <file> --dark
node $KIT/scripts/slop_tells.mjs <file> && node $KIT/scripts/slop_tells.mjs <file> --dark
node $KIT/scripts/verify_overflow.mjs <file|dir>
node $KIT/scripts/verify_responsive.mjs <file|dir> --scale=1.25
Report what they actually printed. These are heuristics: they name what you saw, they do not decide whether it is good. A clean run is not a defence: the kit's own seeded-defect fixtures pass every one of these gates, in both themes, and every one of them is work a senior designer would send back.
Step 5 — write the verdict.
In the format design-critic.md specifies: the verdict, the three reasons a
senior designer would send this back, and the findings table with evidence per
finding. Name the file and the element. "The spacing feels off" is not a finding;
"the card's 12px internal gap is the same as the 12px gap between cards, so the
grouping reads as one block" is.
Do not soften it, and do not pad the "what is good" list to balance the tone.
Step 6 — state the scope, every time.
This is judgement, not measurement. It produces no percentage, and no percentage in this repo covers taste. Say so in the output.
For the session that invoked this skill, not for the fork:
Act on it. Fix every Critical and Major finding, re-run /gate, and run this
critique again on what changed. The loop ends when the remaining findings are
Minor or Enhancement — not when you are tired of it.
Scoring the critic itself, rather than the work, is a maintainer task and lives with the harness in the kit's repository - not here. This skill installs into your project, and nothing it tells you to do should name a file your install does not have.
まだレビューはありません。使ってみた感想をお寄せください。
概要と使いどころ
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.
日本語の概要は準備中です。原文の説明を表示しています。
Build a dense, data-heavy screen - an analytics console or a trading terminal - with real charts drawn from tokens: candlestick, volume, depth, stacked area, waterfall, scatter, correlation matrix, donut, gauge, sparklines, heatmaps and order books. Use when the request is a dashboard, terminal, monitoring view, data console, or any screen whose job is to show many numbers at once. Covers the layout sequence, the SVG geometry, the accessibility contract per chart type, and the contrast traps that only appear in dark mode.
日本語の概要は準備中です。原文の説明を表示しています。
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.
日本語の概要は準備中です。原文の説明を表示しています。