[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6H3V5QCFYF3J3JFD33Q8DZP":3,"skill-same:01M6H3V5QCFYF3J3JFD33Q8DZP":89},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":34,"publishedAt":55,"linkOnly":56,"markdownContent":57,"markdownBody":58,"frontMatter":59,"refName":69,"commitSha":70,"skillDirectory":71,"forksCount":72,"repositoryHtmlUrl":73,"repositoryHomepageUrl":73,"ownerHtmlUrl":74,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":75,"install":76,"resources":88},"01M6H3V5QCFYF3J3JFD33Q8DZP","design-to-dev",null,"Orchestrate frontend implementation from design wireframes. Extracts tokens, creates Linear issues with full specs, drives phased parallel development in git worktrees, and validates output against the original design.","sliamh11\u002FDeus","sliamh11","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F68326628?v=4","01M6H3PPFXQ6C98QV1RJA5W72S","Liam Steiner","01M6H3PPM81GJC6KYCNTY9A3AT",51,"MIT","https:\u002F\u002Fgithub.com\u002Fsliamh11\u002FDeus\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fdesign-to-dev\u002Fskill.md",[18,23,26,29],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000009","前端开发","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":27,"categoryName":28,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":30,"categoryName":31,"taxonomyType":32,"taxonomyTypeDesc":33},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",[35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54],"design","design to dev","dev","ship","frontend","mockup","creation","full","back","worktrees","issue","git worktrees","mcp server","server","orchestrate","figma","linear","issues","MCP","git","2026-11-10 10:12:30",false,"---\nname: design-to-dev\ndescription: >\n  Orchestrate frontend implementation from design wireframes. Extracts tokens,\n  creates Linear issues with full specs, drives phased parallel development\n  in git worktrees, and validates output against the original design.\nuser_invocable: true\ntriggers:\n  - design.?to.?dev\n  - implement.+(design|wireframe|mockup|figma)\n  - wireframe.+(implement|build|develop|ship)\nrequires:\n  - mcp-linear (Linear MCP server for issue creation\u002Fmanagement)\n  - mcp-chrome (optional — falls back to manual screenshots if unavailable)\n---\n\n# \u002Fdesign-to-dev\n\nOrchestrate frontend implementation from design wireframes. Takes wireframe\nscreenshots, extracts design tokens, creates Linear issues with full specs,\nand drives phased parallel development in git worktrees.\n\n**Patterns:** Mediator (wave orchestration — agents communicate via Linear\ncomments and git PRs, not with each other), State Machine (design\u002Fstate.json),\nStructural Isolation (visual judge never receives source code).\n\n## Arguments\n\n- `\u002Fdesign-to-dev \u003Cpath1> \u003Cpath2> ...` — wireframe screenshot paths\n- `\u002Fdesign-to-dev resume` — resume from paused state (reads `design\u002Fstate.json`)\n\n---\n\n## Phase 0 — Preflight\n\n### Step 1: Detect project\n\nVerify cwd is a git repository. If not, fail with:\n\"This skill must be run from within a git repository.\"\n\n### Step 2: Detect stack\n\nScan `package.json` for React, Tailwind CSS, and shadcn\u002Fui.\n\nIf any are missing:\n\n```\nAskUserQuestion:\n  question: \"The project is missing required dependencies. How should we proceed?\"\n  options:\n    - label: \"Scaffold missing deps in Wave 0\"\n      description: \"The foundation wave will install and configure the missing dependencies before any component work begins.\"\n    - label: \"Abort\"\n      description: \"Set up the project manually first, then re-run \u002Fdesign-to-dev.\"\n```\n\nOn abort: exit. On scaffold: note missing deps for Wave 0 issue creation.\n\n### Step 3: Accept wireframe files\n\nIf args contain file paths, use those. Otherwise:\n\n```\nAskUserQuestion:\n  question: \"Provide the paths to your wireframe\u002Fdesign screenshots.\"\n  options:\n    - label: \"I'll paste paths now\"\n      description: \"Enter file paths in the chat (space or newline separated).\"\n    - label: \"They're already in design\u002Fwireframes\u002F\"\n      description: \"Skip — files are already in the project.\"\n```\n\nCopy wireframe files to `design\u002Fwireframes\u002F` in the project root. Create the\ndirectory if it doesn't exist. Verify each file exists and is a readable image.\n\nAdd `design\u002F` to `.gitignore` if not already present. Design assets are\ntemporary build artifacts — they must be removed after implementation completes.\n\n### Step 4: Linear project setup\n\nDiscover available teams via `mcp__linear__linear_getTeams`.\n\n```\nAskUserQuestion:\n  question: \"Which Linear project should issues go into?\"\n  options:\n    - label: \"Create new project\"\n      description: \"Create a new Linear project named after this repo.\"\n    - label: \"Use existing project\"\n      description: \"Select from existing projects.\"\n```\n\nOn \"Create new\": use `mcp__linear__linear_createProject` with the repo name.\nOn \"Use existing\": list projects via `mcp__linear__linear_getProjects` and let\nthe user choose.\n\nStore the project ID and team ID for issue creation.\n\n---\n\n## Phase 1 — Design Analysis\n\n### Step 5: Extract design tokens\n\nFor each wireframe screenshot in `design\u002Fwireframes\u002F`:\n\nRead the image via the Read tool (multimodal). Analyze it to extract:\n- Color palette: all hex values with semantic names (primary, secondary, muted,\n  destructive, background, foreground, border, accent, sidebar colors)\n- Typography: font family, weights used, sizes for each text level\n  (h1-h4, body, caption, label, table cell)\n- Spacing scale: padding, margin, and gap values observed\n- Border radius values (cards, buttons, inputs, avatars)\n- Shadow values\n- Component states visible (hover highlights, active states, disabled elements)\n\nWrite the structured output to `design\u002Ftokens.json`:\n```json\n{\n  \"colors\": { \"primary\": \"#2563EB\", \"background\": \"#FFFFFF\" },\n  \"typography\": { \"fontFamily\": \"Inter\", \"sizes\": { \"h1\": \"24px\" } },\n  \"spacing\": [4, 8, 12, 16, 24, 32, 48],\n  \"radius\": { \"sm\": \"4px\", \"md\": \"6px\", \"lg\": \"8px\", \"full\": \"9999px\" },\n  \"shadows\": { \"sm\": \"0 1px 2px rgba(0,0,0,0.05)\" }\n}\n```\n\n### Step 6: Generate Tailwind theme\n\nFrom `design\u002Ftokens.json`, generate a Tailwind v4 `@theme` CSS block and write\nit to `design\u002Ftokens.css`. This file will be imported into the project's\n`src\u002Findex.css` during Wave 0.\n\nAnnotate each token with its wireframe source as a CSS comment.\n\n### Step 7: Component inventory\n\nAnalyze each wireframe to identify distinct UI regions. For each region, note:\n- Candidate component name (e.g., \"Sidebar\", \"UserTable\", \"StatCard\")\n- Which wireframe it appears in\n- Whether it's shared across wireframes (shared = Wave 0) or page-specific\n- Visible states (if data is shown, assume loading\u002Fempty\u002Ferror states exist)\n- Candidate shadcn\u002Fui primitives it maps to (Button, Card, Table, Input, etc.)\n\nThis inventory drives issue creation in Phase 2.\n\n---\n\n## Phase 2 — Issue Breakdown\n\n### Step 8: Create Linear issues\n\nFor each component\u002Fpage identified in step 7, create a Linear issue via\n`mcp__linear__linear_createIssue`. Use the team ID and project ID from step 4.\n\n**Every issue MUST contain all of the following** (hard rule — no exceptions):\n\n**Title format:** `[Wave N] Component\u002FPage Name`\n\n**Description** (markdown) must include these sections:\n\n**## Overview** — What this component\u002Fpage does and where it appears.\n\n**## Wireframe Reference** — `design\u002Fwireframes\u002F\u003Cfilename>.png` with description\nof which region of the wireframe this issue covers.\n\n**## Design Tokens** — Every token this component uses, with both CSS variable\nand Tailwind class name: `var(--color-primary)` \u002F `bg-primary`.\n\n**## Style Specification** — Exact layout, sizing, spacing, colors, typography\nfor every element. Reference design tokens, never raw values. Example:\n`Container: flex flex-col gap-4 p-6 rounded-lg bg-card`.\n\n**## Behavior & Interactions** — Click, hover, focus behavior for each\ninteractive element. Navigation targets. Form validation rules. Loading and\ntransition behaviors.\n\n**## State Matrix** — Table with columns: State, Description, Mock Data Shape.\nRequired states for data components: loading, empty, error, single-item,\nfull-page, overflow. Required states for forms: pristine, validating,\nfield-errors, submit-loading, success, server-error. Static components:\ndefault only.\n\n**## shadcn\u002Fui Components** — List the shadcn primitives to use.\n\n**## Definition of Done**\n- Builds clean (`npm run build` passes)\n- Matches wireframe region (see Wireframe Reference)\n- One Storybook story per state in the State Matrix\n- Uses only design token utility classes (no raw hex\u002Fpx values)\n- Code review passes\n\n### Step 9: Wave assignment\n\nAssign each issue a wave number in the title `[Wave N]`:\n\n- **Wave 0 (Foundation):** Layout shell (sidebar + top bar + content area),\n  routing skeleton with placeholder routes, design token integration\n  (`design\u002Ftokens.css` into `src\u002Findex.css`), shared types\u002Finterfaces, any\n  missing dependency scaffolding from step 2.\n\n- **Wave 1+:** Group issues so no two issues in the same wave touch the same\n  files. Issues depending on components from a prior wave go in a later wave.\n  Shared components before the pages that use them.\n\n### Step 10: User approval gate (MANDATORY — never skip)\n\nPrint a summary table of all created issues:\n\n```\n| Wave | Issue ID | Title | States |\n|------|----------|-------|--------|\n| 0    | LIA-XXX  | Layout Shell | 1 |\n| 1    | LIA-XXX  | Dashboard Stat Cards | 4 |\n```\n\n```\nAskUserQuestion:\n  question: \"Issues created. Review them in Linear and confirm when ready.\"\n  options:\n    - label: \"Proceed to development\"\n      description: \"Issues are correct. Start Wave 0.\"\n    - label: \"I'm editing issues first\"\n      description: \"Skill pauses. Run \u002Fdesign-to-dev resume when ready.\"\n```\n\nOn \"editing first\": write state to `design\u002Fstate.json` with status `paused`,\ncurrent wave `0`, all issue IDs per wave, Linear project ID. Exit.\n\n---\n\n## Phase 3 — Phased Development\n\n*This phase repeats for each wave until all waves are complete.*\n\n### Step 11: Pre-wave checks\n\nIf resuming (`\u002Fdesign-to-dev resume`), read `design\u002Fstate.json` and re-fetch\nall Linear issues for the current wave to pick up any user modifications.\n\nScan all issues in the current wave for `[BLOCKING]` comments via\n`mcp__linear__linear_getComments`. If any found:\n\n```\nAskUserQuestion:\n  question: \"[BLOCKING] flag found on LIA-XXX: \u003Ccomment text>\"\n  options:\n    - label: \"Halt wave\"\n      description: \"Stop and investigate. Run \u002Fdesign-to-dev resume after resolving.\"\n    - label: \"Override and proceed\"\n      description: \"Ignore the blocking flag and continue.\"\n```\n\n### Step 12: Dispatch subagents\n\nFor each issue in the current wave, dispatch a Sonnet subagent in a git\nworktree. Launch ALL agents for the wave in a single message (parallel).\n\nEach agent's prompt:\n\n```\nYou are implementing a frontend component. Work in your git worktree.\n\n## Your Issue\n[full Linear issue description pasted here]\n\n## Design System\n[contents of design\u002FSYSTEM_MANIFEST.md if it exists, otherwise design\u002Ftokens.json]\n\n## Rules\n- Use ONLY design token utility classes. Never raw hex colors or pixel values.\n- Create one Storybook story per state in the State Matrix.\n- Import shadcn\u002Fui components from @\u002Fcomponents\u002Fui\u002F.\n- Follow existing code patterns in the project.\n- Show commit message before committing.\n- When done, create a PR against main.\n- Post your result as a comment on the Linear issue:\n  - Success: \"SHIP: PR #XX created. \u003Cbrief summary>\"\n  - Concern: \"[WARNING]: \u003Cdescription>\"\n  - Blocker: \"[BLOCKING]: \u003Cdescription — halts the wave>\"\n```\n\n### Step 13: Wait and collect\n\nWait for all subagents to complete. Collect PR URLs from Linear comments.\n\n### Step 14: Handle failures\n\nFor agents that failed (error, crash, timeout):\n- Post `[WARNING]: re-queued from wave N due to agent failure` on the issue\n- Move the issue to the next wave in `design\u002Fstate.json`\n- Do NOT block the wave — successful PRs proceed\n\n### Step 15: Code review and merge\n\nFor each successful PR, dispatch a code-review subagent (Sonnet). All reviews\nin parallel.\n\nOn SHIP verdict: merge the PR.\nOn REVISE: the review agent fixes issues and re-requests. Loop until SHIP.\n\n### Step 16: Post-wave — manifest and coherence\n\nAfter all PRs merge:\n\n**Regenerate manifest:** Analyze merged main branch. Write\n`design\u002FSYSTEM_MANIFEST.md` (~800-1200 tokens):\n- Component inventory: name, file path, props, slot interface\n- Design token coverage: tokens used, any raw values detected\n- Route map: routes and their components\n- Storybook story count vs state matrix total\n\nThis manifest is the coherence sweep's data source — it defines what\n\"consistent\" means so the sweep agent doesn't need to scan the full codebase.\n\n**Coherence sweep:** Dispatch a Sonnet agent that:\n1. Reads `design\u002FSYSTEM_MANIFEST.md`\n2. Detects dev server command from `package.json` scripts\n3. Starts the dev server\n4. Screenshots every route at desktop viewport (1440px) via chrome tools\n   (if chrome unavailable, ask user for screenshots via AskUserQuestion)\n5. Evaluates cross-page consistency: spacing rhythm, typography hierarchy,\n   color usage, interactive patterns, navigation continuity\n6. Outputs a coherence report\n\nIf coherence issues found: create fix-up issues for the current wave, merge\nfixes, re-run coherence until clean.\n\n### Step 17: Wave transition\n\nOn clean coherence:\n1. Run `\u002Fhandoff` for the wave — captures what was built, deviations, warnings\n2. Update `design\u002Fstate.json`: advance `current_wave`, status `running`\n3. Return to step 11 for the next wave\n\nIf no more waves remain, proceed to Phase 4.\n\n---\n\n## Phase 4 — Visual Quality Gate\n\n### Step 18: Start dev server\n\nDetect dev server command from `package.json` `scripts.dev` field. Start in\nthe background. Wait for it to be reachable.\n\n### Step 19: Adversarial visual judge\n\nDispatch a Sonnet visual-judge agent. This agent is STRUCTURALLY ISOLATED:\n\n**Receives ONLY:**\n- Wireframe screenshot paths from `design\u002Fwireframes\u002F`\n- Live app screenshots via chrome tools (fallback: ask user for screenshots)\n- `design\u002Ftokens.json` for reference values\n\n**NEVER receives:**\n- Source code paths or file contents\n- Component names or implementation details\n\n**Layer 1 — Deterministic:**\n- Navigate to each route\n- Run `getComputedStyle` on key elements via chrome JavaScript tool\n- Assert CSS values match design tokens (colors, font sizes, spacing)\n- Check heading hierarchy via accessibility tree\n- Count Storybook stories vs state matrix rows\n\n**Layer 2 — Vision:**\n- For each page: view wireframe and screenshot at same viewport\n- Evaluate: layout fidelity, spacing, colors, typography, element positioning\n- Output per-page: SHIP or REVISE with specific region callouts\n\n### Step 20: Fix loop\n\nOn REVISE:\n1. Create fix-up Linear issues per delta, assigned to next wave\n2. Re-enter Phase 3 (step 11) for that wave\n3. After fixes merge, re-run Phase 4 (step 18)\n4. Repeat until judge returns SHIP for all pages\n\nOn SHIP: proceed to Phase 5.\n\n---\n\n## Phase 5 — Cleanup\n\n### Step 21: Remove design assets\n\n```\nAskUserQuestion:\n  question: \"Implementation complete and visually verified. Remove design assets?\"\n  options:\n    - label: \"Remove design\u002F folder\"\n      description: \"Wireframes and tokens served their purpose. Clean up.\"\n    - label: \"Keep design\u002F folder\"\n      description: \"Preserve for future reference.\"\n```\n\nOn remove: delete `design\u002F` directory, remove `.gitignore` entry if added by\nthis skill, run `git worktree prune`. Commit the cleanup.\n\n---\n\n## State Machine\n\n`design\u002Fstate.json` (gitignored, project-scoped):\n\n```json\n{\n  \"status\": \"running\",\n  \"current_wave\": 1,\n  \"total_waves\": 4,\n  \"linear_project_id\": \"...\",\n  \"linear_team_id\": \"...\",\n  \"waves\": {\n    \"0\": { \"issues\": [\"LIA-101\", \"LIA-102\"], \"status\": \"complete\" },\n    \"1\": { \"issues\": [\"LIA-103\", \"LIA-104\"], \"status\": \"running\" },\n    \"2\": { \"issues\": [\"LIA-106\", \"LIA-107\"], \"status\": \"pending\" }\n  }\n}\n```\n\n**Valid transitions:**\n`preflight → analyzing → issues_created → paused | wave_N → visual_gate → complete`\n\n**Invalid** (skill rejects):\n- Skipping waves (`paused → wave_2` when wave_1 incomplete)\n- Resuming from `complete` (terminal state)\n","# \u002Fdesign-to-dev\n\nOrchestrate frontend implementation from design wireframes. Takes wireframe\nscreenshots, extracts design tokens, creates Linear issues with full specs,\nand drives phased parallel development in git worktrees.\n\n**Patterns:** Mediator (wave orchestration — agents communicate via Linear\ncomments and git PRs, not with each other), State Machine (design\u002Fstate.json),\nStructural Isolation (visual judge never receives source code).\n\n## Arguments\n\n- `\u002Fdesign-to-dev \u003Cpath1> \u003Cpath2> ...` — wireframe screenshot paths\n- `\u002Fdesign-to-dev resume` — resume from paused state (reads `design\u002Fstate.json`)\n\n---\n\n## Phase 0 — Preflight\n\n### Step 1: Detect project\n\nVerify cwd is a git repository. If not, fail with:\n\"This skill must be run from within a git repository.\"\n\n### Step 2: Detect stack\n\nScan `package.json` for React, Tailwind CSS, and shadcn\u002Fui.\n\nIf any are missing:\n\n```\nAskUserQuestion:\n  question: \"The project is missing required dependencies. How should we proceed?\"\n  options:\n    - label: \"Scaffold missing deps in Wave 0\"\n      description: \"The foundation wave will install and configure the missing dependencies before any component work begins.\"\n    - label: \"Abort\"\n      description: \"Set up the project manually first, then re-run \u002Fdesign-to-dev.\"\n```\n\nOn abort: exit. On scaffold: note missing deps for Wave 0 issue creation.\n\n### Step 3: Accept wireframe files\n\nIf args contain file paths, use those. Otherwise:\n\n```\nAskUserQuestion:\n  question: \"Provide the paths to your wireframe\u002Fdesign screenshots.\"\n  options:\n    - label: \"I'll paste paths now\"\n      description: \"Enter file paths in the chat (space or newline separated).\"\n    - label: \"They're already in design\u002Fwireframes\u002F\"\n      description: \"Skip — files are already in the project.\"\n```\n\nCopy wireframe files to `design\u002Fwireframes\u002F` in the project root. Create the\ndirectory if it doesn't exist. Verify each file exists and is a readable image.\n\nAdd `design\u002F` to `.gitignore` if not already present. Design assets are\ntemporary build artifacts — they must be removed after implementation completes.\n\n### Step 4: Linear project setup\n\nDiscover available teams via `mcp__linear__linear_getTeams`.\n\n```\nAskUserQuestion:\n  question: \"Which Linear project should issues go into?\"\n  options:\n    - label: \"Create new project\"\n      description: \"Create a new Linear project named after this repo.\"\n    - label: \"Use existing project\"\n      description: \"Select from existing projects.\"\n```\n\nOn \"Create new\": use `mcp__linear__linear_createProject` with the repo name.\nOn \"Use existing\": list projects via `mcp__linear__linear_getProjects` and let\nthe user choose.\n\nStore the project ID and team ID for issue creation.\n\n---\n\n## Phase 1 — Design Analysis\n\n### Step 5: Extract design tokens\n\nFor each wireframe screenshot in `design\u002Fwireframes\u002F`:\n\nRead the image via the Read tool (multimodal). Analyze it to extract:\n- Color palette: all hex values with semantic names (primary, secondary, muted,\n  destructive, background, foreground, border, accent, sidebar colors)\n- Typography: font family, weights used, sizes for each text level\n  (h1-h4, body, caption, label, table cell)\n- Spacing scale: padding, margin, and gap values observed\n- Border radius values (cards, buttons, inputs, avatars)\n- Shadow values\n- Component states visible (hover highlights, active states, disabled elements)\n\nWrite the structured output to `design\u002Ftokens.json`:\n```json\n{\n  \"colors\": { \"primary\": \"#2563EB\", \"background\": \"#FFFFFF\" },\n  \"typography\": { \"fontFamily\": \"Inter\", \"sizes\": { \"h1\": \"24px\" } },\n  \"spacing\": [4, 8, 12, 16, 24, 32, 48],\n  \"radius\": { \"sm\": \"4px\", \"md\": \"6px\", \"lg\": \"8px\", \"full\": \"9999px\" },\n  \"shadows\": { \"sm\": \"0 1px 2px rgba(0,0,0,0.05)\" }\n}\n```\n\n### Step 6: Generate Tailwind theme\n\nFrom `design\u002Ftokens.json`, generate a Tailwind v4 `@theme` CSS block and write\nit to `design\u002Ftokens.css`. This file will be imported into the project's\n`src\u002Findex.css` during Wave 0.\n\nAnnotate each token with its wireframe source as a CSS comment.\n\n### Step 7: Component inventory\n\nAnalyze each wireframe to identify distinct UI regions. For each region, note:\n- Candidate component name (e.g., \"Sidebar\", \"UserTable\", \"StatCard\")\n- Which wireframe it appears in\n- Whether it's shared across wireframes (shared = Wave 0) or page-specific\n- Visible states (if data is shown, assume loading\u002Fempty\u002Ferror states exist)\n- Candidate shadcn\u002Fui primitives it maps to (Button, Card, Table, Input, etc.)\n\nThis inventory drives issue creation in Phase 2.\n\n---\n\n## Phase 2 — Issue Breakdown\n\n### Step 8: Create Linear issues\n\nFor each component\u002Fpage identified in step 7, create a Linear issue via\n`mcp__linear__linear_createIssue`. Use the team ID and project ID from step 4.\n\n**Every issue MUST contain all of the following** (hard rule — no exceptions):\n\n**Title format:** `[Wave N] Component\u002FPage Name`\n\n**Description** (markdown) must include these sections:\n\n**## Overview** — What this component\u002Fpage does and where it appears.\n\n**## Wireframe Reference** — `design\u002Fwireframes\u002F\u003Cfilename>.png` with description\nof which region of the wireframe this issue covers.\n\n**## Design Tokens** — Every token this component uses, with both CSS variable\nand Tailwind class name: `var(--color-primary)` \u002F `bg-primary`.\n\n**## Style Specification** — Exact layout, sizing, spacing, colors, typography\nfor every element. Reference design tokens, never raw values. Example:\n`Container: flex flex-col gap-4 p-6 rounded-lg bg-card`.\n\n**## Behavior & Interactions** — Click, hover, focus behavior for each\ninteractive element. Navigation targets. Form validation rules. Loading and\ntransition behaviors.\n\n**## State Matrix** — Table with columns: State, Description, Mock Data Shape.\nRequired states for data components: loading, empty, error, single-item,\nfull-page, overflow. Required states for forms: pristine, validating,\nfield-errors, submit-loading, success, server-error. Static components:\ndefault only.\n\n**## shadcn\u002Fui Components** — List the shadcn primitives to use.\n\n**## Definition of Done**\n- Builds clean (`npm run build` passes)\n- Matches wireframe region (see Wireframe Reference)\n- One Storybook story per state in the State Matrix\n- Uses only design token utility classes (no raw hex\u002Fpx values)\n- Code review passes\n\n### Step 9: Wave assignment\n\nAssign each issue a wave number in the title `[Wave N]`:\n\n- **Wave 0 (Foundation):** Layout shell (sidebar + top bar + content area),\n  routing skeleton with placeholder routes, design token integration\n  (`design\u002Ftokens.css` into `src\u002Findex.css`), shared types\u002Finterfaces, any\n  missing dependency scaffolding from step 2.\n\n- **Wave 1+:** Group issues so no two issues in the same wave touch the same\n  files. Issues depending on components from a prior wave go in a later wave.\n  Shared components before the pages that use them.\n\n### Step 10: User approval gate (MANDATORY — never skip)\n\nPrint a summary table of all created issues:\n\n```\n| Wave | Issue ID | Title | States |\n|------|----------|-------|--------|\n| 0    | LIA-XXX  | Layout Shell | 1 |\n| 1    | LIA-XXX  | Dashboard Stat Cards | 4 |\n```\n\n```\nAskUserQuestion:\n  question: \"Issues created. Review them in Linear and confirm when ready.\"\n  options:\n    - label: \"Proceed to development\"\n      description: \"Issues are correct. Start Wave 0.\"\n    - label: \"I'm editing issues first\"\n      description: \"Skill pauses. Run \u002Fdesign-to-dev resume when ready.\"\n```\n\nOn \"editing first\": write state to `design\u002Fstate.json` with status `paused`,\ncurrent wave `0`, all issue IDs per wave, Linear project ID. Exit.\n\n---\n\n## Phase 3 — Phased Development\n\n*This phase repeats for each wave until all waves are complete.*\n\n### Step 11: Pre-wave checks\n\nIf resuming (`\u002Fdesign-to-dev resume`), read `design\u002Fstate.json` and re-fetch\nall Linear issues for the current wave to pick up any user modifications.\n\nScan all issues in the current wave for `[BLOCKING]` comments via\n`mcp__linear__linear_getComments`. If any found:\n\n```\nAskUserQuestion:\n  question: \"[BLOCKING] flag found on LIA-XXX: \u003Ccomment text>\"\n  options:\n    - label: \"Halt wave\"\n      description: \"Stop and investigate. Run \u002Fdesign-to-dev resume after resolving.\"\n    - label: \"Override and proceed\"\n      description: \"Ignore the blocking flag and continue.\"\n```\n\n### Step 12: Dispatch subagents\n\nFor each issue in the current wave, dispatch a Sonnet subagent in a git\nworktree. Launch ALL agents for the wave in a single message (parallel).\n\nEach agent's prompt:\n\n```\nYou are implementing a frontend component. Work in your git worktree.\n\n## Your Issue\n[full Linear issue description pasted here]\n\n## Design System\n[contents of design\u002FSYSTEM_MANIFEST.md if it exists, otherwise design\u002Ftokens.json]\n\n## Rules\n- Use ONLY design token utility classes. Never raw hex colors or pixel values.\n- Create one Storybook story per state in the State Matrix.\n- Import shadcn\u002Fui components from @\u002Fcomponents\u002Fui\u002F.\n- Follow existing code patterns in the project.\n- Show commit message before committing.\n- When done, create a PR against main.\n- Post your result as a comment on the Linear issue:\n  - Success: \"SHIP: PR #XX created. \u003Cbrief summary>\"\n  - Concern: \"[WARNING]: \u003Cdescription>\"\n  - Blocker: \"[BLOCKING]: \u003Cdescription — halts the wave>\"\n```\n\n### Step 13: Wait and collect\n\nWait for all subagents to complete. Collect PR URLs from Linear comments.\n\n### Step 14: Handle failures\n\nFor agents that failed (error, crash, timeout):\n- Post `[WARNING]: re-queued from wave N due to agent failure` on the issue\n- Move the issue to the next wave in `design\u002Fstate.json`\n- Do NOT block the wave — successful PRs proceed\n\n### Step 15: Code review and merge\n\nFor each successful PR, dispatch a code-review subagent (Sonnet). All reviews\nin parallel.\n\nOn SHIP verdict: merge the PR.\nOn REVISE: the review agent fixes issues and re-requests. Loop until SHIP.\n\n### Step 16: Post-wave — manifest and coherence\n\nAfter all PRs merge:\n\n**Regenerate manifest:** Analyze merged main branch. Write\n`design\u002FSYSTEM_MANIFEST.md` (~800-1200 tokens):\n- Component inventory: name, file path, props, slot interface\n- Design token coverage: tokens used, any raw values detected\n- Route map: routes and their components\n- Storybook story count vs state matrix total\n\nThis manifest is the coherence sweep's data source — it defines what\n\"consistent\" means so the sweep agent doesn't need to scan the full codebase.\n\n**Coherence sweep:** Dispatch a Sonnet agent that:\n1. Reads `design\u002FSYSTEM_MANIFEST.md`\n2. Detects dev server command from `package.json` scripts\n3. Starts the dev server\n4. Screenshots every route at desktop viewport (1440px) via chrome tools\n   (if chrome unavailable, ask user for screenshots via AskUserQuestion)\n5. Evaluates cross-page consistency: spacing rhythm, typography hierarchy,\n   color usage, interactive patterns, navigation continuity\n6. Outputs a coherence report\n\nIf coherence issues found: create fix-up issues for the current wave, merge\nfixes, re-run coherence until clean.\n\n### Step 17: Wave transition\n\nOn clean coherence:\n1. Run `\u002Fhandoff` for the wave — captures what was built, deviations, warnings\n2. Update `design\u002Fstate.json`: advance `current_wave`, status `running`\n3. Return to step 11 for the next wave\n\nIf no more waves remain, proceed to Phase 4.\n\n---\n\n## Phase 4 — Visual Quality Gate\n\n### Step 18: Start dev server\n\nDetect dev server command from `package.json` `scripts.dev` field. Start in\nthe background. Wait for it to be reachable.\n\n### Step 19: Adversarial visual judge\n\nDispatch a Sonnet visual-judge agent. This agent is STRUCTURALLY ISOLATED:\n\n**Receives ONLY:**\n- Wireframe screenshot paths from `design\u002Fwireframes\u002F`\n- Live app screenshots via chrome tools (fallback: ask user for screenshots)\n- `design\u002Ftokens.json` for reference values\n\n**NEVER receives:**\n- Source code paths or file contents\n- Component names or implementation details\n\n**Layer 1 — Deterministic:**\n- Navigate to each route\n- Run `getComputedStyle` on key elements via chrome JavaScript tool\n- Assert CSS values match design tokens (colors, font sizes, spacing)\n- Check heading hierarchy via accessibility tree\n- Count Storybook stories vs state matrix rows\n\n**Layer 2 — Vision:**\n- For each page: view wireframe and screenshot at same viewport\n- Evaluate: layout fidelity, spacing, colors, typography, element positioning\n- Output per-page: SHIP or REVISE with specific region callouts\n\n### Step 20: Fix loop\n\nOn REVISE:\n1. Create fix-up Linear issues per delta, assigned to next wave\n2. Re-enter Phase 3 (step 11) for that wave\n3. After fixes merge, re-run Phase 4 (step 18)\n4. Repeat until judge returns SHIP for all pages\n\nOn SHIP: proceed to Phase 5.\n\n---\n\n## Phase 5 — Cleanup\n\n### Step 21: Remove design assets\n\n```\nAskUserQuestion:\n  question: \"Implementation complete and visually verified. Remove design assets?\"\n  options:\n    - label: \"Remove design\u002F folder\"\n      description: \"Wireframes and tokens served their purpose. Clean up.\"\n    - label: \"Keep design\u002F folder\"\n      description: \"Preserve for future reference.\"\n```\n\nOn remove: delete `design\u002F` directory, remove `.gitignore` entry if added by\nthis skill, run `git worktree prune`. Commit the cleanup.\n\n---\n\n## State Machine\n\n`design\u002Fstate.json` (gitignored, project-scoped):\n\n```json\n{\n  \"status\": \"running\",\n  \"current_wave\": 1,\n  \"total_waves\": 4,\n  \"linear_project_id\": \"...\",\n  \"linear_team_id\": \"...\",\n  \"waves\": {\n    \"0\": { \"issues\": [\"LIA-101\", \"LIA-102\"], \"status\": \"complete\" },\n    \"1\": { \"issues\": [\"LIA-103\", \"LIA-104\"], \"status\": \"running\" },\n    \"2\": { \"issues\": [\"LIA-106\", \"LIA-107\"], \"status\": \"pending\" }\n  }\n}\n```\n\n**Valid transitions:**\n`preflight → analyzing → issues_created → paused | wave_N → visual_gate → complete`\n\n**Invalid** (skill rejects):\n- Skipping waves (`paused → wave_2` when wave_1 incomplete)\n- Resuming from `complete` (terminal state)\n",{"name":5,"requires":60,"triggers":63,"description":67,"user_invocable":68},[61,62],"mcp-linear (Linear MCP server for issue creation\u002Fmanagement)","mcp-chrome (optional — falls back to manual screenshots if unavailable)",[64,65,66],"design.?to.?dev","implement.+(design|wireframe|mockup|figma)","wireframe.+(implement|build|develop|ship)","Orchestrate frontend implementation from design wireframes. Extracts tokens, creates Linear issues with full specs, drives phased parallel development in git worktrees, and validates output against the original design.\n",true,"main","2f24c38a2ae42d3161492f0729975b286452f4b4",".claude\u002Fskills\u002Fdesign-to-dev",7,"https:\u002F\u002Fgithub.com\u002Fsliamh11\u002FDeus","https:\u002F\u002Fgithub.com\u002Fsliamh11","2026-11-10 03:41:56",{"source":8,"skillName":5,"commands":77,"prompt":87,"zipAvailable":68},[78,81,84],{"tool":79,"command":80},"npx","npx skills add sliamh11\u002FDeus --skill design-to-dev",{"tool":82,"command":83},"bunx","bunx skills add sliamh11\u002FDeus --skill design-to-dev",{"tool":85,"command":86},"pnpm","pnpm dlx skills add sliamh11\u002FDeus --skill design-to-dev","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fsliamh11\u002FDeus\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fdesign-to-dev\u002Fskill.md",[],[90,116,133,147,157,172],{"skillNo":91,"name":92,"nameZh":6,"description":93,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":94,"categories":95,"keywords":96,"publishedAt":55},"01M6H3ZC87AJDM8566RP3CQ6BF","status","Quick read-only health check — session context, workspace mounts, tool availability, and task snapshot. Use when the user asks for system status or runs \u002Fstatus.","https:\u002F\u002Fgithub.com\u002Fsliamh11\u002FDeus\u002Fblob\u002Fmain\u002Fcontainer\u002Fskills\u002Fstatus\u002FSKILL.md",[],[92,97,98,99,100,101,102,103,104,105,106,107,108,109,110,111,112,113,114,115],"health","snapshot","for","read-only","quick","availability","session context","task","health check","only","use","session","user","context","read","check","workspace","tool","system",{"skillNo":117,"name":118,"nameZh":6,"description":119,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":120,"categories":121,"keywords":125,"publishedAt":55},"01M6H3Z8SK38PVH2B0W7NBP6ZP","resume","Load context from permanent memory and recent session logs. Tiered loading — CLAUDE.md full, session logs frontmatter-only by default.","https:\u002F\u002Fgithub.com\u002Fsliamh11\u002FDeus\u002Fblob\u002Fmain\u002Fcontainer\u002Fskills\u002Fresume\u002FSKILL.md",[122],{"categoryNo":123,"categoryName":124,"taxonomyType":32,"taxonomyTypeDesc":33},"01JBSEEDCAT000000000000038","人力资源",[118,126,127,128,42,129,130,106,108,110,131,132],"memory","load","loading","session logs","default","logs","frontmatter",{"skillNo":134,"name":135,"nameZh":6,"description":136,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":137,"categories":138,"keywords":139,"publishedAt":55},"01M6H3Z56ZBPKX77THMWSSHZCW","preserve","Scan the current conversation and silently save anything worth permanent memory to CLAUDE.md. Keeps the file compact — structured key:value, no prose.","https:\u002F\u002Fgithub.com\u002Fsliamh11\u002FDeus\u002Fblob\u002Fmain\u002Fcontainer\u002Fskills\u002Fpreserve\u002FSKILL.md",[],[135,140,141,142,143,144,145,146,126],"structured","compact","scan","conversation","prose","save","file",{"skillNo":148,"name":149,"nameZh":6,"description":150,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":151,"categories":152,"keywords":153,"publishedAt":55},"01M6H3Z1AKK58CWWY762YD3X9A","compress","Save the current session to the vault. Writes a compact session log with a TL;DR frontmatter (always) and full details below (when useful).","https:\u002F\u002Fgithub.com\u002Fsliamh11\u002FDeus\u002Fblob\u002Fmain\u002Fcontainer\u002Fskills\u002Fcompress\u002FSKILL.md",[],[149,154,132,42,141,155,108,145,156],"with","log","vault",{"skillNo":158,"name":159,"nameZh":6,"description":160,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":161,"categories":162,"keywords":163,"publishedAt":55},"01M6H3YX6STE1ZJC06EKWMY0M6","capabilities","Show what this Deus instance can do — installed skills, available tools, and system info. Read-only. Use when the user asks what the bot can do, what's installed, or runs \u002Fcapabilities.","https:\u002F\u002Fgithub.com\u002Fsliamh11\u002FDeus\u002Fblob\u002Fmain\u002Fcontainer\u002Fskills\u002Fcapabilities\u002FSKILL.md",[],[159,164,165,115,100,166,167,168,169,170,171,106,107,109,111],"Tools","bot","can","system info","info","what the","do","show",{"skillNo":173,"name":174,"nameZh":6,"description":175,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":176,"categories":177,"keywords":179,"publishedAt":55},"01M6H3YSNXYAR7NC1TZPFCANZN","agent-browser","Browse the web for any task — research topics, read articles, interact with web apps, fill forms, take screenshots, extract data, and test web pages. Use whenever a browser would be useful, not just when the user explicitly asks.","https:\u002F\u002Fgithub.com\u002Fsliamh11\u002FDeus\u002Fblob\u002Fmain\u002Fcontainer\u002Fskills\u002Fagent-browser\u002FSKILL.md",[178],{"categoryNo":27,"categoryName":28,"taxonomyType":21,"taxonomyTypeDesc":22},[180,181,182,99,154,183,184,185,104,186,107,111,187,188,189,190,191,192,193,194],"agent browser","browser","take","apps","pages","forms","test web","just","Bash","browse","data","web","test","research","screenshots"]