Hooke / mlaj

description: 基于现有设计产物，为该功能生成可执行、按依赖排序的 tasks.md。
handoffs:
  - label: 一致性分析
    agent: speckit.analyze
    prompt: 执行项目一致性分析
    send: true
  - label: 分阶段实现
    agent: speckit.implement
    prompt: 按阶段开始实现
    send: true

用户输入

$ARGUMENTS

在继续之前，你必须先考虑用户输入（如果不为空）。

概述

1. 准备：在仓库根目录运行 .specify/scripts/bash/check-prerequisites.sh --json 并解析 FEATURE_DIR 与 AVAILABLE_DOCS 列表。所有路径必须是绝对路径。当参数里包含单引号（例如 "I'm Groot"）时，使用转义写法：如 'I'\''m Groot'（或尽量用双引号："I'm Groot"）。

2. 加载设计文档：从 FEATURE_DIR 读取：

   • 必需：plan.md（技术栈、依赖库、结构）、spec.md（带优先级的用户故事）
   • 可选：data-model.md（实体）、contracts/（API 端点）、research.md（决策）、quickstart.md（测试场景）
   • 注意：并非所有项目都有全部文档。应基于当前可用文档生成任务。

3. 执行任务生成流程：

   • 加载 plan.md，提取技术栈、依赖库与项目结构
   • 加载 spec.md，提取带优先级的用户故事（P1、P2、P3 等）
   • 如果存在 data-model.md：提取实体并映射到用户故事
   • 如果存在 contracts/：将端点映射到用户故事
   • 如果存在 research.md：提取决策用于初始化相关任务
   • 按用户故事组织生成任务（见下方“任务生成规则”）
   • 生成依赖图，展示用户故事的完成顺序
   • 为每个用户故事提供并行执行示例
   • 校验任务完整性（每个用户故事包含所需任务，且可独立测试）

4. 生成 tasks.md：以 .specify/templates/tasks-template.md 为结构，填充：

   • 从 plan.md 读取正确的功能名称
   • Phase 1：初始化任务（项目初始化）
   • Phase 2：基础任务（所有用户故事的阻塞前置）
   • Phase 3+：按 spec.md 的优先级为每个用户故事建一个阶段
   • 每个阶段包含：故事目标、独立测试标准、测试（如有要求）、实现任务
   • 最终阶段：打磨与横切关注点
   • 所有任务必须遵循严格的清单格式（见下方“任务生成规则”）
   • 每个任务都要写清楚文件路径
   • Dependencies 章节展示故事完成顺序
   • 每个故事提供并行执行示例
   • Implementation strategy 章节说明实现策略（先 MVP，逐步交付）

5. 报告（Report）：输出生成的 tasks.md 路径与摘要：

   • 任务总数
   • 每个用户故事的任务数
   • 识别到的并行机会
   • 每个故事的独立测试标准
   • 建议的 MVP 范围（通常只包含用户故事 1）
   • 格式校验：确认所有任务都遵循清单格式（checkbox、ID、标签、文件路径）

用于任务生成的上下文：$ARGUMENTS

tasks.md 应当可以直接执行——每个任务都必须足够具体，使得 LLM 在不依赖额外上下文的情况下也能完成。

任务生成规则

关键（CRITICAL）：任务必须按用户故事组织，以支持独立实现与独立测试。

测试是可选项：只有在 spec 明确要求，或用户要求 TDD 时才生成测试任务。

清单格式（必须）

每个任务都必须严格遵循以下格式：

- [ ] [TaskID] [P?] [Story?] 包含文件路径的任务描述

格式组成：

1. 勾选框（Checkbox）：必须以 - [ ] 开头（Markdown checkbox）
2. 任务 ID（Task ID）：按执行顺序递增编号（T001、T002、T003...）
3. [P] 标记：仅当任务可并行时才包含（不同文件，且不依赖未完成任务）
4. [Story] 标签：仅用于“用户故事阶段”的任务，且必须包含
   • 格式：[US1]、[US2]、[US3] 等（映射 spec.md 的用户故事）
   • 初始化阶段：不加 story 标签
   • 基础阶段：不加 story 标签
   • 用户故事阶段：必须有 story 标签
   • 打磨阶段：不加 story 标签
5. 描述（Description）：清晰描述动作，并包含准确文件路径

示例：

• ✅ 正确：- [ ] T001 按实现计划创建项目结构
• ✅ 正确：- [ ] T005 [P] 在 src/middleware/auth.py 实现认证中间件
• ✅ 正确：- [ ] T012 [P] [US1] 在 src/models/user.py 创建 User 模型
• ✅ 正确：- [ ] T014 [US1] 在 src/services/user_service.py 实现 UserService
• ❌ 错误：- [ ] 创建用户模型（缺少 ID 与 Story 标签）
• ❌ 错误：T001 [US1] 创建模型（缺少 checkbox）
• ❌ 错误：- [ ] [US1] 创建用户模型（缺少 Task ID）
• ❌ 错误：- [ ] T001 [US1] 创建模型（缺少文件路径）

任务组织方式

1. 来自用户故事（spec.md）——主要组织方式：

   • 每个用户故事（P1、P2、P3...）对应一个阶段
   • 将所有相关组件映射到对应的故事：
     • 该故事需要的模型
     • 该故事需要的服务
     • 该故事需要的端点/UI
     • 若需要测试：该故事专属的测试任务
   • 标记故事依赖（大多数故事应尽量独立）

2. 来自 contracts：

   • 将每个 contract/endpoint 映射到它服务的用户故事
   • 若需要测试：每个 contract 在该故事阶段中，先生成 contract 测试任务 [P]，再实现

3. 来自数据模型：

   • 将每个实体映射到需要它的用户故事
   • 若实体服务多个故事：放入最早的故事阶段或初始化阶段
   • 关系处理 → 放到对应故事阶段的服务层任务中

4. 来自初始化/基础设施：

   • 共享基础设施 → 初始化阶段（Phase 1）
   • 基础/阻塞任务 → 基础阶段（Phase 2）
   • 故事特定的初始化 → 放到该故事阶段内

阶段结构

• Phase 1：初始化（项目初始化）
• Phase 2：基础（阻塞前置；必须在用户故事之前完成）
• Phase 3+：按优先级顺序的用户故事（P1、P2、P3...）
  • 每个故事内：测试（如需）→ 模型 → 服务 → 端点 → 集成
  • 每个阶段都应是一个完整且可独立测试的增量
• 最终阶段：打磨与横切关注点