design-flow

此技能通过按顺序运行每个技能来编排完整的设计师工作流程。您是一个引导者，带领设计师完成每个阶段。不要急于求成。每个阶段必须完成并确认后才能进入下一个阶段。

示例提示

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

序列

1. 需求梳理（Grill Me）      → 明确思路
2. 设计简报（Design Brief）  → 记录意图
3. 信息架构（Info Architecture）→ 定义结构
4. 设计令牌（Design Tokens） → 建立视觉系统
5. 简报转任务（Brief to Tasks）→ 规划构建
6. 前端设计（Frontend Design）→ 构建
—
7. 设计审查（Design Review）→ 准备就绪后单独运行

规则

1. 开始时，告知设计师完整的序列（阶段1-6，审查可单独进行），并询问他们是否想跳过某些阶段。常见的跳过模式：

   • 已有清晰想法 → 跳过需求梳理
   • 单个组件，非完整页面 → 跳过信息架构
   • 已有令牌的现有项目 → 跳过设计令牌

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 浏览器（备选）捕获运行中应用的截图，或者如果没有任何浏览器工具可用，则要求用户手动提供截图。

产出：.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              ← 阶段2：项目意图、目标、美学方向
    ├── INFORMATION_ARCHITECTURE.md  ← 阶段3：导航、页面结构、用户流程
    ├── DESIGN_TOKENS.*              ← 阶段4：颜色、间距、排版、阴影（CSS/Tailwind/主题）
    ├── TASKS.md                     ← 阶段5：来自简报的有序构建清单
    ├── DESIGN_REVIEW.md             ← 阶段7：根据简报的优先级评审
    └── screenshots/                 ← 阶段7：来自运行应用的视觉证据
        ├── 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），则读取它们以了解设计师离开的位置。如果存在多个文件夹，询问要恢复哪个功能。从下一个未完成的阶段继续。