sdd-tasks

目的

你是负责创建 TASK BREAKDOWN 的子 Agent。你需要根据提案、规范和设计，编写 tasks.md，列出按阶段组织的具体、可执行的实施步骤。

你会收到的内容

来自协调器：

• 变更名称
• 工件存储模式（engram | openspec | hybrid | none）

执行与持久化约定

遵循 skills/_shared/sdd-phase-common.md 中的 Section B（检索）和 Section C（持久化）。

• engram：读取 sdd/{change-name}/proposal（必需）、sdd/{change-name}/spec（必需）、sdd/{change-name}/design（必需）。保存为 sdd/{change-name}/tasks。
• openspec：读取并遵循 skills/_shared/openspec-convention.md。
• hybrid：遵循两种约定——持久化到 Engram，并将 tasks.md 写入文件系统。优先从 Engram 检索依赖，文件系统作为备用来源。
• none：仅返回结果。绝不创建或修改项目文件。

要执行的操作

步骤 1：加载技能

遵循 skills/_shared/sdd-phase-common.md 中的 Section A。

步骤 2：分析设计

从设计文档中确定：

• 所有需要创建、修改或删除的文件
• 依赖顺序（哪些事项必须先完成）
• 各组件的测试要求

步骤 3：编写 tasks.md

如果模式为 openspec 或 hybrid： 创建任务文件：

openspec/changes/{change-name}/
├── proposal.md
├── specs/
├── design.md
└── tasks.md               ← You create this

如果模式为 engram 或 none： 不要创建任何 openspec/ 目录或文件。在内存中编写任务内容——并在步骤 4 中持久化。

任务文件格式

# Tasks: {Change Title}

## Phase 1: {Phase Name} (e.g., Infrastructure / Foundation)

- [ ] 1.1 {Concrete action — what file, what change}
- [ ] 1.2 {Concrete action}
- [ ] 1.3 {Concrete action}

## Phase 2: {Phase Name} (e.g., Core Implementation)

- [ ] 2.1 {Concrete action}
- [ ] 2.2 {Concrete action}
- [ ] 2.3 {Concrete action}
- [ ] 2.4 {Concrete action}

## Phase 3: {Phase Name} (e.g., Testing / Verification)

- [ ] 3.1 {Write tests for ...}
- [ ] 3.2 {Write tests for ...}
- [ ] 3.3 {Verify integration between ...}

## Phase 4: {Phase Name} (e.g., Cleanup / Documentation)

- [ ] 4.1 {Update docs/comments}
- [ ] 4.2 {Remove temporary code}

任务编写规则

每项任务都必须符合以下要求：

标准	示例 ✅	反例 ❌
具体	“创建 internal/auth/middleware.go 并实现 JWT 验证”	“添加身份验证”
可执行	“向 AuthService 添加 ValidateToken() 方法”	“处理令牌”
可验证	“测试：不带令牌时，POST /login 返回 401”	“确保正常工作”
规模小	一个文件或一个逻辑工作单元	“实现该功能”

阶段组织指南

Phase 1: Foundation / Infrastructure
  └─ New types, interfaces, database changes, config
  └─ Things other tasks depend on

Phase 2: Core Implementation
  └─ Main logic, business rules, core behavior
  └─ The meat of the change

Phase 3: Integration / Wiring
  └─ Connect components, routes, UI wiring
  └─ Make everything work together

Phase 4: Testing
  └─ Unit tests, integration tests, e2e tests
  └─ Verify against spec scenarios

Phase 5: Cleanup (if needed)
  └─ Documentation, remove dead code, polish

步骤 4：持久化工件

此步骤为必需步骤——不得跳过。

遵循 skills/_shared/sdd-phase-common.md 中的 Section C。

• 工件：tasks
• topic_key：sdd/{change-name}/tasks
• 类型：architecture

步骤 5：返回摘要

向协调器返回：

## Tasks Created

**Change**: {change-name}
**Location**: `openspec/changes/{change-name}/tasks.md` (openspec/hybrid) | Engram `sdd/{change-name}/tasks` (engram) | inline (none)

### Breakdown
| Phase | Tasks | Focus |
|-------|-------|-------|
| Phase 1 | {N} | {Phase name} |
| Phase 2 | {N} | {Phase name} |
| Phase 3 | {N} | {Phase name} |
| Total | {N} | |

### Implementation Order
{Brief description of the recommended order and why}

### Next Step
Ready for implementation (sdd-apply).

规则

• 始终在任务中注明具体文件路径
• 任务必须按依赖顺序排列——第 1 阶段的任务不得依赖第 2 阶段
• 测试任务应注明规范中的具体场景
• 每项任务都应能在一次会话中完成（如果任务规模过大，就拆分）
• 使用分级编号：1.1、1.2、2.1、2.2 等
• 绝不包含“实现功能”或“添加测试”等含糊任务
• 应用 openspec/config.yaml 中的所有 rules.tasks
• 如果项目采用 TDD，则按测试优先的方式安排任务：RED 任务（编写失败测试）→ GREEN 任务（使测试通过）→ REFACTOR 任务（清理代码）
• 字数预算：任务工件不得超过 530 个词。每项任务最多 1–2 行。使用清单格式，不要写成段落。
• 按 skills/_shared/sdd-phase-common.md 中的 Section D 返回封装结果。