brief-to-tasks

本技能将设计简报转化为有序、可构建的任务列表。每个任务都是一个垂直切片：一个可以独立构建、审查和验证的 UI 片段。

示例提示

• "将简报分解为任务"
• "我应该先构建什么？"
• "从设计简报创建任务列表"
• "规划此功能的构建顺序"

流程

1. 读取设计简报。查找 .design/*/DESIGN_BRIEF.md。如果存在多个子文件夹，使用最近修改的那个，或询问用户正在处理哪个功能。同时检查同一子文件夹中的 INFORMATION_ARCHITECTURE.md 和 tokens 文件。如果不存在，请用户描述他们正在构建的内容。

2. 探索现有代码库以了解已构建的内容。特别扫描：

   • 组件目录：components/、ui/、shared/，并列出每个组件的名称
   • 现有页面/视图：此功能必须与之共存的内容
   • Token/主题文件：tokens.css、globals.css、Tailwind 配置、主题提供者
   • 文件命名约定：kebab-case、PascalCase，文件组织方式（按功能、按类型）
   • 测试文件：如果测试与组件共存，新任务应包含测试期望
   • Package.json 依赖：已安装的 UI 库、动画库和图标集
   • 将每个相关组件分类为：将按原样重用、需要修改或尚不存在。只有需要修改或创建的组件才拥有自己的任务。

3. 将工作分解为垂直切片。每个任务应：

   • 可独立构建（除非注明，否则不应阻塞其他任务）。
   • 在单个任务中包含结构、样式和交互（不要将“构建 HTML”、“添加 CSS”、“添加 JS”作为单独的任务）。
   • 可验证：你可以查看结果并确认其符合简报。
   • 足够小，可在单个会话中完成。

4. 按以下顺序排列任务：

   • 依赖优先：基础元素（tokens、布局外壳、共享组件）先于页面特定工作。
   • 视觉优先级：最突出的 UI 元素尽早出现，以便用户在投入细节之前验证美学方向。
   • 风险优先：最难或最不确定的部分尽早处理，以便在围绕它们构建其他内容之前暴露问题。

5. 将任务列表保存为 TASKS.md，放在与设计简报相同的 .design/<feature-slug>/ 子文件夹中。

任务列表模板

# 构建任务：[功能/页面名称]

生成自：.design/<feature-slug>/DESIGN_BRIEF.md
日期：[日期]

## 基础
- [ ] **[任务名称]**：[一句话描述要构建的内容以及“完成”的样子]。_重用：[现有组件/tokens（如有）]。_
- [ ] **[任务名称]**：[描述]。_新组件。_

## 核心 UI
- [ ] **[任务名称]**：[描述]。_依赖：[任务名称（如有）]。_
- [ ] **[任务名称]**：[描述]。

## 交互与状态
- [ ] **[任务名称]**：[描述]。涵盖：[状态列表，例如悬停、加载、错误、空]。
- [ ] **[任务名称]**：[描述]。

## 响应式与打磨
- [ ] **[任务名称]**：[描述]。断点：[哪些断点]。
- [ ] **[任务名称]**：无障碍检查。[简报中的具体检查项]。

## 审查
- [ ] **设计审查**：针对简报运行 /design-review。

规则

• 每个任务必须引用其是重用、修改还是创建组件。
• 永远不要创建仅“设置项目”或“创建文件结构”的任务。这些不是垂直切片。
• 如果简报指定了美学理念，请在第一个构建任务中注明，以便立即确立视觉方向。
• 将相关任务分组，但不要嵌套超过一层。扁平列表更易于处理。