prototype
This skill guides UX work through five fidelity levels (content-first, wireframe, low-fi, high-fi, code), ensuring each prototype answers a specific question before advancing. Use it when you need to create wireframes, map user journeys with error paths and edge cases, plan usability testing with concrete success criteria, or validate design decisions before implementation.
git clone --depth 1 https://github.com/plugin87/ux-ui-agent-skills /tmp/prototype && cp -r /tmp/prototype/.claude/skills/prototype ~/.claude/skills/prototypeSKILL.md
# Skill: Prototype & Research Guide work through the right fidelity level with validation. ## Steps 1. Read `workflows/prototyping.md` (5-level fidelity ladder, journey mapping template, usability-testing script, sample data). 2. Identify the current need and pick the **lowest** fidelity that answers it — never skip levels: - Content-first (info needs) → Wireframe (layout/nav) → Low-fi (task completion) → High-fi (visual/a11y) → Code (feasibility/perf). 3. For flows: produce a user-journey map with decision points, error paths, and edge cases. 4. For validation: define the usability test (tasks, success criteria, 5-user rule) using the script. 5. High-fi/code steps pull tokens (`tokens/*`), components (`components/*`), taste (`taste/*`), and a11y (`accessibility/*`). ## Output The artifact at the chosen fidelity + an explicit "what we validate next" plan. ## Verification (before declaring done) - The fidelity matches the question being answered — no level skipped. - Flows include decision points, **error paths, and edge cases** (empty/loading/overflow), not just the happy path. - A concrete validation step is named (tasks + success criteria), not "test later". - High-fi/code artifacts pass the same token + a11y bar as `design-code` (no hardcoded values, contrast, states).
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.
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.
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.
Adversarial senior design critic. Renders the work, looks at it, and argues for rejection. Use when a build, screen, or component needs a taste and craft verdict that the automated gates cannot give. Runs after the gates are green, never instead of them.
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.