spec-kit-tasks

根据功能规范和计划生成一份可执行、按依赖关系排序的任务列表。

输入：可选指定变更名称。若省略，请根据上下文推断或询问。

步骤

1. 加载资料

   必需：specs/changes/<name>/plan.md 和 specs/changes/<name>/spec.md。

   可选（如果存在，也加载）：specs/changes/<name>/checklists/。

   同时加载 FRAMEWORK.md（以及存在时的 FRAMEWORK.local.md），了解任务必须遵循的规范和义务。

   如果缺少 plan.md，请提示先使用 spec-kit-plan 技能。

2. 生成 specs/changes/<name>/tasks.md

   按阶段组织任务：

   # Tasks: <Feature Name>
   
   ## Phase 1: Setup & Foundations
   - [ ] [T01] [FR-01] Description with exact file path
   
   ## Phase 2: Domain & Application Layer
   - [ ] [T02] [FR-01] Add a failing test for <behaviour> in <test file>
   - [ ] [T03] [FR-01, FR-02] Make it pass: implement <behaviour> in <file>
   - [ ] [T04] [P] [FR-03] Description (parallel — touches other files, depends on nothing unfinished)
   
   ## Phase 3: Infrastructure & Adapters
   - [ ] [T05] [P] [US-1] Description with exact file path
   
   ## Phase 4: Integration & Validation
   - [ ] [T06] [FR-02] Description with exact file path
   
   ## Phase 5: Documentation
   - [ ] [T07] [FR-01] Update `specs/features/<area>/spec.md` where <what the change makes untrue>
   
   ## Dependency Graph
   T01 → T02 → T03 → T05 → T06 → T07
              ↘ T04 ↗
   
   ## MVP Scope
   <Minimum set of tasks for a working, deployable slice, usually the P1 stories, with how each story is tested on its own.>
   

   任务格式：- [ ] [TaskID] [P?] [FR-nn, US-n] Description with exact file path

   • 并行标记之后的引用组，至少列出 spec.md 中的一项需求（FR-nn）、成功标准（SC-nn）或用户故事（US-n）：说明该任务交付什么。
   • [P] 表示该任务涉及的文件与相邻任务不同，且不依赖任何未完成任务。
   • 每项任务都必须具体且可立即执行：没有其他上下文的读者也能完成。
   • 顺序：设置 → 领域 → 应用 → 基础设施 → 集成 → 文档。
   • 先测试，再实现。 如果 FRAMEWORK.md 规定默认采用 TDD，则将每项测试任务紧挨着放在其驱动的实现任务之前，并在依赖关系图中体现（先测试，再实现）。 将任务对表述为“为 X 添加一个失败测试”／“使其通过：实现 X”。 对于静态类型语言，因符号尚不存在而导致测试无法编译，是正常的失败步骤，不应因此将实现任务排在测试之前。
   • 逐字引用约束。 对于计划中数据模型给出的每项字段约束（必填或可选、限制、允许值、验证规则），在实现该约束的任务中逐字引用，不能留给实现者自行决定。
   • 列出过时测试。 对于计划中查阅变更范围之外的测试时发现、且会读取变更所影响内容的每项测试，都要安排一个任务运行该测试，并在必要时更新。
   • 最后一个阶段必须是 ## Phase N: Documentation： 计划的 ## Record Search 指出本次变更会使之失效的每份现行规范、决策记录或文档各安排一项任务；否则仅列一条说明 (no observable behaviour change)。 spec-kit-converge 后续追加的收敛阶段必须排在该阶段之后。
   • 将每项任务对应到 spec.md 中的需求和用户故事。

3. 验证

   完成前：

   • 每项需求、边缘情况需求和用户故事至少对应一项任务，且每项任务都标明其交付内容。
   • 每项需要可构建工作的成功标准（如负载测试、审计、测量）都必须有对应任务；发布后测量的结果指标无需安排任务。
   • 最后一个阶段必须是 Documentation 阶段，并包含一项任务或上述说明。
   • 所有任务都必须包含精确的文件路径。
   • 任务不得含糊不清或范围过大。
   • 对大型文件中的特定位置，使用可搜索的内容定位，例如函数名、独特字符串或搜索模式，绝不使用行号，因为行号在任务开始前就可能过时。 在模式旁注明数量（例如“十六处引用”），让实现者知道搜索结果何时完整。
   • 项目规则对所触及路径规定的每项义务都必须有对应任务。 阅读 FRAMEWORK.md 和 FRAMEWORK.local.md，了解这些路径除测试之外还需履行的事项，例如递增版本、添加变更日志条目、重新生成生成文件或重建资料，并为每项义务单独安排任务。
   • 每个新测试路径都必须遵循该目录下同类测试的现有组织方式；确定路径前先检查现有布局。

输出 编写 tasks.md 后：

• 每个阶段及每个用户故事的任务数。
• 已识别的并行机会。
• MVP 范围摘要。
• 下一步：“使用 spec-kit-analyse 技能，在实施前验证一致性和需求覆盖情况。”

护栏

• 切勿生成违反依赖规则的任务。
• 排序时，领域和应用任务必须先于基础设施任务。
• 在项目规定的 TDD 纪律下，切勿将实现任务排在驱动它的测试任务之前。
• 切勿添加任何没有需求、用户故事或计划决策依据的工作。