design-flow

此技能通过依次运行各项技能来编排完整的设计工作流。你将引导设计师完成每个阶段。不要操之过急。完成并确认每个阶段后，才能进入下一阶段。

示例提示

• “运行完整的设计流程”
• “带我走完新项目的完整流程”
• “从头开始，带我完成所有步骤”
• “为仪表盘应用设计”

流程顺序

1. Grill Me          → Clarify thinking
2. Design Brief      → Document intent
3. Info Architecture  → Define structure
4. Design Tokens     → Establish visual system
5. Brief to Tasks    → Plan the build
6. Frontend Design   → Build it
—
7. Design Review     → Run separately when ready

规则

1. 开始时，告知设计师完整流程的顺序（阶段 1-6，评审可单独进行），并询问他们是否想跳过任何阶段。常见的跳过情况：

   • 已经有明确想法 → 跳过 grill-me
   • 只有一个组件，而非完整页面 → 跳过 information-architecture
   • 现有项目已有设计令牌 → 跳过 design-tokens

2. 每个阶段开始前，说明即将进入哪个阶段，以及该阶段会产出什么。例如：“阶段 2：设计简报。我会采访你，了解项目情况，并生成 DESIGN_BRIEF.md 文件。准备好了吗？”

3. 每个阶段进行中，读取对应的 SKILL.md 文件，并遵循其中的完整说明。不要概述或缩写技能内容。按要求执行。

4. 每个阶段结束后，总结产出内容（文件名、关键决策、待解决的问题），并询问：“准备好进入下一阶段了吗？”等待确认。

5. 阶段之间，检查上一阶段的产出是否会影响下一阶段。例如，如果设计简报中提到了某种设计理念，就说明令牌阶段会据此制定。

6. 设计师可以随时停止。 如果他们说“暂时这样就够了”，请总结目前进行到哪个阶段，以及他们回来后要进入的下一阶段。

阶段详情

阶段 1：深入了解需求

读取 grill-me 技能（grill-me/SKILL.md），并遵循其中的说明。 产出：对项目达成共识。不生成文件。 过渡语：“我们已经确定了关键决策。准备好将这些内容整理成设计简报了吗？”

阶段 2：设计简报

读取 design-brief 技能（design-brief/SKILL.md），并遵循其中的说明。 产出：.design/<feature-slug>/DESIGN_BRIEF.md。 过渡语：“设计简报已保存。接下来是信息架构阶段，我们将在此定义页面结构和导航。如果你要构建的是单个组件，可以跳过此阶段。继续吗？”

阶段 3：信息架构

读取 information-architecture 技能（information-architecture/SKILL.md），并遵循其中的说明。 产出：.design/<feature-slug>/INFORMATION_ARCHITECTURE.md。 过渡语：“信息架构已确定。接下来，我们将根据设计简报中的理念生成设计令牌（颜色、间距、字体排版）。继续吗？”

阶段 4：设计令牌

读取 design-tokens 技能（design-tokens/SKILL.md），并遵循其中的说明。 产出：令牌文件（根据技术栈生成 CSS 变量、Tailwind 配置或主题文件）。 过渡语：“令牌已设置。接下来，我会把设计简报拆分成任务列表，以便我们按顺序构建。继续吗？”

阶段 5：将简报拆分为任务

读取 brief-to-tasks 技能（brief-to-tasks/SKILL.md），并遵循其中的说明。 产出：.design/<feature-slug>/TASKS.md。 过渡语：“任务已准备就绪。现在开始构建。我会从列表中的第一个任务开始。继续吗？”

阶段 6：前端设计

读取 frontend-design 技能（frontend-design/SKILL.md），并遵循其中的说明。 按顺序完成 TASKS.md 中的任务。每完成一个任务，就将其标记为已完成，并在继续下一个任务前与设计师确认。 产出：已构建的组件和页面。 过渡语：“整个流程已完成。设计简报、信息架构、令牌和任务列表都已保存在项目中。准备好进行设计评审时，运行 /design-review，我会根据设计简报评审构建结果。”

流程到此结束。 阶段 7 不会自动开始。

第 7 阶段：设计评审（仅按需进行）

此阶段不会自动运行。仅在以下情况下运行：

• 设计师在流程中明确要求进行评审
• 设计师在完成构建后单独运行 /design-review

评审需要检查已构建的代码。如果尚未构建任何组件或页面，请勿运行此阶段。请改为提醒设计师：“构建好内容后，运行 /design-review。它会根据设计简报检查输出。”

触发后，阅读 design-review 技能（design-review/SKILL.md）并遵循其中的说明。评审会使用 Playwright MCP（首选）、Cursor IDE Browser（备用）截取运行中应用的屏幕截图；如果没有可用的浏览器工具，则会请用户手动提供截图。

产出：.design/<feature-slug>/DESIGN_REVIEW.md + 保存在 .design/<feature-slug>/screenshots/ 中的屏幕截图。 过渡语：“评审已完成。屏幕截图已保存在 .design/<feature-slug>/screenshots/ 中。如果有必须修复的问题，我现在可以处理。”

项目文件结构

所有设计流程产物都保存在 .design/<feature-slug>/ 下，其中 <feature-slug> 是根据所设计功能生成的简短、小写、以连字符分隔的名称。这可确保多个功能可以独立设计，互不覆盖。

.design/
└── <feature-slug>/
    ├── DESIGN_BRIEF.md              ← Phase 2: Project intent, goals, aesthetic direction
    ├── INFORMATION_ARCHITECTURE.md  ← Phase 3: Navigation, page structure, user flows
    ├── DESIGN_TOKENS.*              ← Phase 4: Colors, spacing, typography, shadows (CSS/Tailwind/theme)
    ├── TASKS.md                     ← Phase 5: Ordered build checklist from the brief
    ├── DESIGN_REVIEW.md             ← Phase 7: Prioritized critique against the brief
    └── screenshots/                 ← Phase 7: Visual evidence from the running app
        ├── review-[page]-desktop-1280.png
        ├── review-[page]-tablet-768.png
        ├── review-[page]-mobile-375.png
        ├── review-[page]-dark-mode-*.png
        └── review-[component]-[state].png

screenshots/ 子文件夹会在设计评审阶段创建。评审的所有视觉证据（响应式断点、交互状态、深色模式）都会使用描述性文件名保存在此处，以便追溯 DESIGN_REVIEW.md 中的发现。

如果设计师在流程中途返回

检查 .design/ 文件夹中是否已有功能子文件夹。如果某个功能文件夹中存在早期阶段的文件（DESIGN_BRIEF.md、INFORMATION_ARCHITECTURE.md、TASKS.md），请阅读这些文件，了解设计师上次进行到哪一步。如果存在多个文件夹，请询问要继续哪个功能。从下一个未完成的阶段继续。