Design Comp: $ARGUMENTS

Turn a PRD into a set of visual design comps that make design decisions visible, reviewable, and referenceable from implementation tickets.

Prerequisites

• A canvas tool must be connected via MCP. See references/paper-mcp.md for Paper.design setup.

Use this when

• A PRD exists and needs a visual design artifact before implementation
• Tickets need a design reference attached
• Stakeholders need to review and approve UI changes before work begins

Phase 1: Understand the problem

1. Parse the PRD path from $ARGUMENTS. If not provided, ask the user which PRD to use.
2. Read the PRD thoroughly.
3. Read the source code of every page and component the PRD touches or references. You cannot design what you haven't read.

Phase 2: Design analysis

Work through these questions before producing any visuals. Write your answers down as a design brief in your response so the user can review your thinking.

Who is the user?

• What role does this person have? What are they trying to accomplish?
• What's their context when they encounter this feature? Are they in a hurry, doing repetitive work, exploring, making a high-stakes decision?
• What do they already understand about the app? Is this a power user workflow or a first-touch experience?
• What matters most to them here — speed, clarity, confidence, control?

What is the design problem?

• What kind of change is this? A new page, a modification, a new interaction pattern, a new feedback mechanism, a data display, a flow?
• What decisions does the PRD leave to the designer? PRDs describe behavior and requirements, not spatial layout, visual hierarchy, or component selection. Identify every choice the comp needs to make.
• What's ambiguous? Where could two reasonable designers disagree about the right approach?

How does this fit the existing design system?

• Precedent: Are there existing patterns in the app that solve a similar problem? A similar form layout, a similar confirmation flow, a similar data display? Start from precedent — don't reinvent when the app already has an answer.
• Congruence: Do the existing components and patterns serve this feature's needs naturally? Can you build this feature entirely from what already exists (buttons, cards, toasts, form fields, layout patterns), or does it require something new?
• Tension: Where does the PRD's requirements push against the existing design system? If the PRD asks for something the current components can't express well, name that tension explicitly. Should the feature adapt to fit the system, or does the system need to extend?
• Consistency: What should look and feel the same as existing pages? What earns the right to look different?

What changes, and what stays the same?

• Draw a clear boundary between what the feature adds/modifies and what remains untouched.
• The surrounding UI that doesn't change is context — it anchors the viewer. Show enough of it to orient.
• The new or changed elements are the payload — they need to be clearly identifiable as what's different.

What are the interaction states?

Not every feature needs the same states. Think about what's specific to this feature:

• Entry: How does the user arrive here? What do they see first?
• Engagement: What does the core interaction look like? Is it a single action, a multi-step flow, a repeated task?
• Feedback: How does the system respond? What does success look like? What does failure look like? What does "in progress" look like?
• Recovery: If something goes wrong, what does the user see? Can they fix it without starting over?
• Edge cases: What happens with empty data, too much data, long strings, missing fields, first-time use, nth-time use?

Only show states that communicate something a reviewer or implementer needs to see. Don't pad with states that are obvious.

Phase 3: Plan the views

Based on your design analysis, propose a specific set of artboards. For each one, state:

• What it shows
• What design decision it communicates
• Why a reviewer needs to see this (what would be lost if you cut it?)

Present this list to the user. Get confirmation or adjustments before rendering.

Phase 4: Render

Follow the rendering reference for the connected canvas tool:

• Paper.design: see references/paper-mcp.md

The key principles regardless of tool:

• Use the app's exact design tokens — colors, fonts, spacing, radii, shadows from the actual codebase
• Use existing component patterns faithfully — if the app uses a specific button style, input style, card structure, match it
• Use realistic placeholder content that fits the app's domain
• Build incrementally so the user sees progress
• Review your work visually as you go

Phase 5: Handoff

1. Summarize what was generated — each artboard and the design decision it communicates.
2. Call out decisions the comp makes that the PRD left unspecified. These are the things the stakeholder should explicitly approve or revise.
3. Call out any tensions discovered in Phase 2 — places where the feature pushes against the existing design system.
4. If the user wants to attach designs to tickets, capture screenshots from the canvas tool for attachment.

Constraints

• Do not write application code. This skill produces design artifacts only.
• Use the app's real design system. Do not invent visual elements that don't exist in the codebase unless the PRD requires something new — and if it does, call it out explicitly as a new pattern being introduced.
• The comp's purpose is communication. It makes design decisions visible and reviewable. It is not pixel-perfect implementation art.