把设计 brief 拆成按顺序排列…

当用户要求拆解工作、从设计 brief 创建任务、规划实现顺序，或提到 tasks/breakdown 时使用。

适用场景

解决思路

1. 查找 `.design/*/DESIGN_BRIEF.md` 作为设计 brief。
2. 如果存在多个子文件夹，使用最近修改的那个，或询问用户正在处理哪个功能。
3. 同时检查同一子文件夹中的 `INFORMATION_ARCHITECTURE.md` 和 tokens 文件。
4. 如果这些文件都不存在，让用户描述要构建的内容。
5. 探索现有代码库，理解已经构建了什么。
6. 扫描组件目录 `components/`、`ui/`、`shared/`，并按名称列出每个组件。
7. 扫描现有页面/视图：识别该功能必须与之共存的已构建内容。
8. 扫描 token/主题文件：`tokens.css`、`globals.css`、Tailwind config、theme providers。
9. 检查文件命名约定：kebab-case、PascalCase，以及按功能或按类型组织文件的方式。
10. 检查测试文件：如果测试与组件并存，新任务应包含测试期望。
11. 检查 `package.json` 依赖：已安装的 UI 库、动画库和图标集。
12. 将每个相关组件分类为：可原样复用、需要修改、尚不存在。
13. 只有需要修改或创建的组件才获得自己的任务。
14. 将工作拆成垂直切片。
15. 每个任务应可独立构建（除非已注明，否则任一任务不应阻塞另一任务）。
16. 每个任务应在单个任务中同时包含结构、样式和交互（不要把“构建 HTML”“添加 CSS”“添加 JS”拆成不同任务）。
17. 每个任务应可验证：查看结果即可确认它符合 brief。
18. 每个任务应足够小，能在单次会话中完成。
19. 按依赖优先排序：基础元素（tokens、布局壳、共享组件）先于页面特定工作。
20. 按视觉优先级排序：最突出的 UI 元素排前面，以便在投入细节前让用户验证美学方向。
21. 按风险优先排序：最难或最不确定的部分排前面，以便在围绕它们构建其他内容前暴露问题。
22. 将任务清单保存为 `TASKS.md`，放在与设计 brief 相同的 `.design/<feature-slug>/` 子文件夹中。
23. 使用以下任务清单模板： ```markdown # 构建任务：[功能/页面名称] 来源：.design/<feature-slug>/DESIGN_BRIEF.md 日期：[date] ## 基础 - [ ] **[任务名称]**：[一句话描述要构建什么以及“完成”的标准]。_复用：[现有组件/tokens（如有）]。_ - [ ] **[任务名称]**：[描述]。_新组件。_ ## 核心 UI - [ ] **[任务名称]**：[描述]。_依赖：[任务名称（如有）]。_ - [ ] **[任务名称]**：[描述]。 ## 交互与状态 - [ ] **[任务名称]**：[描述]。覆盖：[状态列表，例如 hover、loading、error、empty]。 - [ ] **[任务名称]**：[描述]。 ## 响应式与打磨 - [ ] **[任务名称]**：[描述]。断点：[哪些断点]。 - [ ] **[任务名称]**：无障碍检查。[来自 brief 的具体检查项]。 ## 评审 - [ ] **设计评审**：针对 brief 运行 /design-review。 ```
24. 每个任务都必须标明它复用、修改还是创建组件。
25. 绝不要创建仅“搭建项目”或“创建文件结构”的任务；这些不是垂直切片。
26. 如果 brief 指定了美学理念，在第一个构建任务中注明，以便立即确立视觉方向。
27. 对相关任务分组，但嵌套不要超过一层；扁平列表更容易推进。

适用边界 · 注意事项

• 没有设计 brief 且用户也无法描述要构建什么时，无法生成可靠任务。
• 任务不是 UI/页面/设计实现，或不适合垂直切片（例如纯后端迁移、纯研究、一次性脚本）。
• 已有明确任务管理流程且不需要生成 Markdown `TASKS.md` 时。