design-maker

---

name: design-maker description: Used when the Design Brief is complete and the user needs to generate mockups. Reads Product-Spec.md and Design-Brief.md, then generates a complete set of design deliverables through a design tool MCP, including all pages, state variants, component specifications, design tokens, UI-Spec.md, and DESIGN.md (Google design.md format). version: 1.1.0 updated: 2026-06-27 requires: []

[Task] Read Product-Spec.md and Design-Brief.md, then generate complete design deliverables through a design tool MCP. Ensure that every feature with UI in the Product Spec has a corresponding design page, and every page covers all critical state variants.

**Typical entry**: User just finished `/design-brief-builder` and chose option A (or said「继续/默认」) in Next Step Gate — treat that as explicit invocation.

[Not For] - Defining visual direction or style preferences -> use /design-brief-builder instead - Writing code from designs -> use /dev-builder instead - Projects without a design tool MCP available -> skip this skill and go straight to /dev-builder

[Dependency Check] Automatically executed as the first step when the Skill starts.

Required:
- Product-Spec.md → If missing, prompt the user to call /product-spec-builder first
- Design-Brief.md → If missing, prompt the user to call /design-brief-builder first
- Design tool MCP → See the design tool detection process below

Optional:
- references/design-self-critique.md → used in verification if available

Design tool detection process:
1. Ask the user whether they want to use Pencil or Figma
2. Check if the corresponding MCP is connected
3. Connected → Continue
4. Not connected → Attempt to connect the MCP, or prompt the user to connect
5. User does not have the corresponding design software installed → Prompt the user to install it and retry
6. User chooses to skip → Exit design-maker; subsequent workflow continues in no-mockup mode

[First Principles] Full Coverage Principle: Every feature with UI in the Product Spec must have a design page. Miss one page and development loses one reference — the consequence is development by guessing. State Completeness Principle: Every page must have more than just a default state. Empty state, loading state, error state, active state — pages with interactivity must cover critical state variants. Components First Principle: Build reusable components first, then compose pages from them. Avoid drawing the same button 10 times across 10 pages, requiring 10 changes for a single update. Document-Driven Principle: All design decisions come from Product-Spec.md and Design-Brief.md. Do not improvise based on personal preference, and do not add features not described in the documents.

[Output Style] Tone: Designer presenting mockups to an engineering team — structured, precise, complete. Every page and variant is explicitly listed. Principles: - V Every feature with UI in the Spec has a design page - V Every interactive page covers empty, loading, error, and active states - V Design tokens are documented (not "looks about right") - X No improvised features — everything comes from Product-Spec.md and Design-Brief.md

[Design Coverage Checklist] Before delivering, verify each dimension:

| Dimension | Must-Have | Recommended |
|-----------|-----------|-------------|
| **Page Coverage** | Every Spec UI feature has a design page | State variants (empty/loading/error) for interactive pages |
| **Component System** | Reusable components extracted before page composition | Design tokens for colors, typography, spacing, radius |
| **Spec Fidelity** | Layout and content match Product-Spec.md item by item | Visual direction matches Design-Brief.md mood and notes |
| **Self-Critique** | references/design-self-critique.md executed (all >=3) | Anti-ai-slop checklist from design-brief-builder reviewed |
| **Consistency** | Same component looks same across pages | Design tokens referenced correctly, no ad-hoc values |