A Figma-powered workflow that turns Claude into a design-aware partner — Vuetify-compatible, policy-enforcing, and context-rich from day one.
Design reviews, Figma handoffs, and Vuetify constraint checks require deep product and system knowledge that a generic assistant doesn't have.
Generic Claude doesn't know which Vuetify components your product uses, what's been customized, or what gaps exist in the design system.
Design decisions must follow product policy (RTL, accessibility baseline, state coverage). A generic assistant can't enforce rules it doesn't know about.
Describing a design in chat is slow and lossy. The context should come directly from the Figma file — components, tokens, flows, and states.
Generic Claude suggests adding scope beyond what the PM approved in the wireframe — creating tension between design and product management.
Same 4-layer model as the PM workflow. The key difference: Layer 2 (the interview) is Figma-powered — Claude reads the design file directly instead of asking questions.
~/.claude/ and claude-workflow/policy/claude-workflow/interview/designer-interview.md · reads Figma via MCPCLAUDE.md, .claude/skills/product-designer/*/context.mdCLAUDE.local.md, .claude/settings.local.json · gitignoredKey difference from PM: The designer interview doesn't ask questions. It connects to Figma via MCP, reads your design system and product screens directly, and generates all 11 context files from the Figma file content.
The designer setup generates 11 files — fewer than the PM (14), because Figma data replaces several manual interview answers.
The same 4-layer merge applies to every designer command. Here's what happens when you run /design-review.
Claude Code injects CLAUDE.md into every session. It contains the designer's profile, product design language, Vuetify version, design system boundaries, and working language.
~/.claude/commands/product-designer/design-review.md defines the chain: design-policy-review → vuetify-constraint-check → unified review report. Each step has a defined output format.
~/.claude/skills/product-designer/design-policy-review/SKILL.md defines what to check and how — Vuetify coverage check, RTL layout rules, state coverage requirements, microcopy standards, accessibility baseline.
.claude/skills/product-designer/design-policy-review/context.md contains your product's design system — component inventory extracted from Figma, known gaps, customized components, and team-specific rules.
SKILL.md (check instructions) + context.md (your Figma-extracted design system) + CLAUDE.md (designer profile) + design-standard.md (output format with flag system) = a review that knows your product, your components, and your rules.
SKILL.md answers "how to review". context.md answers "against which design system and constraints". The context was extracted from Figma — no manual description needed.
Unlike the PM interview (647 lines of questions), the designer onboarding connects to Figma via MCP and reads the design system and product screens directly. Two questions. No manual context entry.
Checks whoami via Figma MCP to confirm access is available before starting. If Figma MCP is not connected, provides setup instructions.
Working language (Persian or English) and whether the designer wants to connect an existing git repository. These are the only manual inputs required.
Design system file link + one or more product screen links. These are the source of truth for all generated context.
Uses Figma MCP tools to read components, color tokens, text styles, spacing variables, component variants, and screen flows. No copy-pasting, no manual description.
CLAUDE.md, design-agent.md, handoff-agent.md, design-standard.md, and 7 skill context files. Designer approves each write. Context reflects the actual Figma file.
Shared skills are available to both the PM and the Designer. Designer-specific skills cover the full design workflow from research to handoff.
Checks design against policy: Vuetify coverage, RTL layout, state coverage, microcopy quality, and accessibility baseline.
For every UI component, verifies Vuetify 3 coverage. Maps each element to a component, checks theming, flags gaps with options.
QA-perspective review of a design: checks all states are covered, identifies implementation ambiguities before handoff.
Generates a complete handoff document for engineering with component mapping, state specs, and Vuetify prop recommendations.
Translates Figma screens into Vue + Vuetify code with correct component choices, props, and responsive behavior.
Writes UI copy (labels, placeholders, error messages, empty states) following product voice and tone guidelines.
Structures research questions, synthesizes user feedback, and surfaces insights in a format PMs can act on.
Compares Figma design against the built Vue/Vuetify component — identifies gaps and produces a structured report.
Scans design system before new UI is requested — prevents duplicate components.
Mid-fidelity HTML wireframe covering all states using existing design system components.
Converts design decisions or review findings into ready-to-paste Linear tasks with four-part structure.
Generates polished single-file HTML slide decks following the product design system.
Prepares structured agendas and extracts decisions and action items from design critiques.
Analyzes and rewrites prompts to improve Claude output quality for design reviews and requests.
Designer commands cover the full design cycle — from research and review through Figma-to-code translation and final handoff.
Understand the design context before starting visual work — existing patterns, component inventory, and open UX decisions that could affect the design direction.
"What components are already in use", "what design patterns exist for this", "before I start designing", or picking up a feature for the first time. Typically the first skill a designer runs on a new feature.
Existing design patterns relevant to the feature, component inventory (available vs. missing), open UX decisions that need to be made, and a starting checklist before running design-policy-review.
Invoke: /design-research [feature or area to research]
Check design work-in-progress against design-policy.md while changes are still cheap — before the design is finalized and rework becomes expensive.
"Check my design direction", "is this RTL-safe", "does this follow our rules", "I'm designing this, does it look right so far". Use WHILE designing — not after. Do NOT use on a completed design; use design-qa for that.
Policy compliance status with severity flags (🔴 Blocker / 🟡 Important / 🟢 Suggestion). Checks: Vuetify coverage (surface), RTL layout, state coverage, microcopy quality, accessibility baseline.
Not the same as design-qa: policy-review is mid-process; design-qa is the final gate check before handoff.
Systematically verify that every UI element in a design has a corresponding Vuetify 3 component — flag any gaps before the design goes to engineering.
"Check Vuetify compatibility", "can this be built with Vuetify", "verify component coverage", "are there any Vuetify gaps", or as Step 1 in /design-handoff before generating the handoff document.
A component coverage map: each UI element → Vuetify 3 component + key props + theming compliance. Gaps flagged with options: extend existing component, use a different component, or custom implementation needed.
Runs as Step 2 in /design-review (after policy check) and as Step 1 in /design-handoff (before handoff doc). Ensures every component is implementable.
The final gate check before engineering gets the file — policy compliance, Vuetify compatibility, state coverage, and microcopy quality in one pass.
"QA this design", "is this ready for handoff", "run a final check", "check the design before I send it to engineering". Use ONLY when the design is complete — not during active design work.
Combined review: policy compliance + Vuetify coverage + state coverage (all user and system states covered?) + microcopy quality + handoff readiness checklist. All blockers must be resolved before handoff.
Invoke: /design-qa [feature or Figma link] — all 🔴 Blockers must be resolved before proceeding to /design-handoff
Generate a complete, implementation-ready handoff document that engineering can act on without needing to ask the designer follow-up questions.
"Prepare the handoff", "write the handoff doc", "I'm ready to hand off this feature", "generate the spec for engineering". Requires vuetify-constraint-check to have been run first.
Component-level spec: each element with Vuetify component + props + variants + responsive behavior. State matrix showing all UI states. Microcopy table. Token references. Implementation notes and open questions.
Invoke: /design-handoff [feature name or Figma link] — auto-runs vuetify-constraint-check first to ensure full Vuetify coverage before generating the document
Translate a Figma design directly into Vue 3 + Vuetify 3 component code — read from Figma via MCP, not from screenshots or descriptions.
"Generate code for this design", "turn this into Vue code", "write the Vuetify component for this", "translate my Figma to code". Typically after vuetify-constraint-check confirms all components are implementable.
Vue 3 SFC code with correct Vuetify 3 components, props, and responsive behavior. Follows the project's existing component patterns. Marked as reference code — engineering reviews and adapts before production use.
Reads Figma directly via MCP — no screenshots needed. Invoke: /figma-to-code [Figma file link or frame name]
Write clear, consistent, and on-brand UI copy for any product element — following the microcopy standards in design-policy.md.
"Write copy for this", "help me write the error message", "what should this button say", "review this microcopy", "write the empty state text". Can be called during design, before handoff, or during QA.
UI copy for the requested element type: button labels, error messages, empty states, tooltips, confirmation dialogs, placeholder text. Includes alternatives and rationale for each choice.
Invoke: /microcopy-writer [element type + context] — covers buttons, errors, empty states, tooltips, and any in-product text
Compare the Figma design against the actual Vue/Vuetify implementation — identify every gap and produce a structured report the designer can act on or escalate.
"Does the implementation match the design", "check what was built against Figma", "review the implemented component", "does the code match my design". Run after engineering marks a feature complete, before the designer signs off.
A gap report comparing Figma spec vs. code: visual gaps (spacing, color, typography), component substitutions, missing states, interaction gaps. Each gap classified as Blocker / Minor / Accepted deviation.
Requires Figma MCP access AND repository access. Does not accept screenshots as substitutes. Invoke: /implementation-review [Figma link + component path]
Inventory existing UI components before planning new design work — prevent duplicate components and make sure new requests are truly net-new.
"What components do we have", "do we need to build this UI from scratch", "the designer said we need a new component", "is there already a pattern for this", before starting new UI design work.
Component inventory: available (can reuse as-is), extensible (needs modification), and net-new (must be built). Flags cases where a new component request could be satisfied by extending an existing one.
Invoke: /design-system-check [describe the UI needs]
Generate interactive HTML wireframes showing a feature in multiple states and multiple UX pattern variants — a concrete design starting point before high-fidelity work.
"Show me what this looks like", "generate a wireframe", "I want to see all the states", "what are the different UX options", or as Step 4 in the PM /new-feature chain.
A self-contained HTML file with clickable state transitions: empty state, loading, success, error, and all edge case states. Multiple UX pattern variants presented side-by-side using existing design system components.
Invoke: /wireframe-generator [feature + states to show]
Convert design decisions, reviews, or fixes into ready-to-paste Linear tasks with the team's standard four-part structure.
"Write a Linear task for this design fix", "log this as a task", "create a task from this design-qa finding". Use after any review that produces actionable items that need to be tracked.
A four-part Linear task: (1) Context, (2) User Story, (3) DOD with clear completion criteria, (4) Out of scope. Ready to paste directly into Linear.
Invoke: /task-writer [describe the task]
Prepare structured agendas before design critiques and team meetings, and extract decisions and action items after them.
"Prepare the agenda for the design critique", "what are the action items from today's review", "summarize the design decisions we made", "log the feedback from the stakeholder review".
Pre-meeting: timed agenda, discussion goals, and materials checklist. Post-meeting: structured summary with decisions, action items with owners, and open questions requiring follow-up.
Invoke: /meeting-support [meeting type + context]
Generate polished, single-file HTML slide decks following the team's design system — flat-color, no-shadow, scroll-based, publication-ready.
"Make a presentation", "create slides for this", "I need to present the design to stakeholders". Works for design reviews, system proposals, process documentation, and team updates.
A self-contained HTML file saved to docs/ — title slide, content slides using cards/step rows/arch layers, and a summary slide. Follows the team design system: warm palette, 0.5px borders, font-weight 400–500 only.
Invoke: /presentation-style [topic and content description] — saved to docs/ for GitHub Pages
Analyze, critique, and rewrite prompts to maximize output quality — for both claude.ai conversations and Claude Code skill invocations.
"Optimize this prompt", "how can I get better results", "review my prompt", paste a prompt and ask for feedback. Works for design descriptions sent to Claude, review requests, and any claude.ai conversation prompts.
A critique (what's vague, missing, or over-constrained), a rewritten prompt with specific improvements, and an explanation of each change and why it improves output quality.
Invoke: /prompt-optimizer [paste your prompt]
A complete design review in one command — policy compliance check followed by Vuetify constraint check, producing a unified review report with all blockers and required actions.
Check against design-policy.md — Vuetify coverage (surface level), RTL layout, state coverage, microcopy quality, accessibility baseline. Outputs intermediate status before proceeding.
Deep Vuetify 3 component coverage — map each UI element to a component, check theming compliance, flag gaps with implementation options.
Consolidated findings organized by category (policy / Vuetify / microcopy) with severity flags, required actions (🔴 Blockers), and optional improvements (🟢 Suggestions).
Invoke: /design-review [feature name + states list] — use mid-process while design is still in progress. For completed designs, use /design-qa instead.
Designer rules enforce design boundaries: Vuetify compatibility, policy-first decisions, wireframes before high-fidelity, and authority respect.
design-policy.md before being presented. Policy violations are flagged, never silently ignored.Two commands, two questions, and your Figma links. The design system context is extracted automatically — no copy-pasting component lists, no manual descriptions.
One command. Installs the claude-pm CLI on your machine.
npm install -g claude-pm
Installs all designer skills to ~/.claude/ globally, and scaffolds the policy tree, placeholder context files, two design agents, and an outputs/ folder for deliverables.
cd your-product-repo
claude-pm init --role designer
Launch Claude Code inside the product repo. The interview command checks Figma MCP access automatically and provides setup instructions if Figma is not yet connected.
Type /start-designer-interview. Claude verifies Figma MCP access, then asks two questions: your working language (Persian or English) and whether to connect an existing git repository.
/start-designer-interview
When prompted, paste your Figma design system file URL and one or more product screen URLs. Claude reads the files directly via MCP — components, tokens, variants, and flows are extracted automatically.
Claude shows each file before writing. Review CLAUDE.md (your designer profile), the 7 skill context.md files, and both design agents. Approve each write before Claude saves it.
git add CLAUDE.md .claude/ .gitignore && git commit -m "feat: add designer workflow context"
The design system context is loaded on every session. Start with a review or use /figma-to-code on an existing screen to verify the context is accurate.
/design-review [feature name or Figma link]
Refreshing context: When your Figma design system changes significantly, re-run /start-designer-interview to refresh context files. The interview only updates what changed.
Updating policy: Run claude-pm update to pull the latest skills and rules. Your Figma-generated context files are never overwritten.
Policy Layer updates from the supervisor never touch your CLAUDE.md or context files. No re-interview, no merge conflicts.
Supervisor pushes to product-team-claude-skills repo. Designer runs:
cd claude-workflow && git pull && cd ..
That is the entire update process. Nothing else required.
Context files extracted from Figma are designer-owned — the supervisor never touches them. Policy files and context files live in separate directory trees, so git pull never creates a merge conflict.
Context isn't typed in chat — it's extracted from your Figma file. Component inventory, tokens, and variants are always accurate.
All design suggestions use Vuetify 3 components with correct props. No suggestions that engineering can't implement with your stack.
Policy compliance, state coverage, and authority limits are checked on every response. No manual checklist needed.