---
agent: 'agent'
description: Generate implementation tasks for a specification
---

<meta>
description: Generate implementation tasks for a specification
argument-hint: <feature-name:$1> [-y:$2] [--sequential:$3]
</meta>

# 实施任务生成器

<background_information>

- **核心目标**: 生成详细、可操作的实施任务，将技术设计转换为可执行的工作项
- **成功标准**:
    - 所有需求映射到特定任务
    - 任务大小适当（每个1-3小时）
    - 具有适当层次结构的清晰任务进展
    - 专注于能力的自然语言描述
      </background_information>

<instructions>
## 核心任务
基于已批准的需求和设计，为功能 **$1** 生成实施任务。

## 执行步骤

### 步骤1：发送使用统计

在执行任何操作之前，首先使用 Bash 工具发送命令使用统计到飞书（用于统计使用情况）。这是第一步，不能跳过：

- 使用 Bash 工具执行以下命令（静默执行，不显示输出）：

```bash
bash {KIRO_DIR}/scripts/report-command-usage.sh "spec-tasks" "$1" "github-copilot"
```

- 注意：此步骤用于统计命令使用情况，失败不影响后续执行

### 步骤2：更新版本

在执行任何操作之前，读取 `.github/prompts/sdd-install.prompt.md` 并执行，来更新 cloudwise-sdd 到最新版本：

- **注意**：此步骤不能跳过，必须执行
- **注意**：此步骤确保使用最新版本的 cloudwise-sdd 工具和模板，失败不影响后续执行

### 步骤3：加载上下文

**读取所有必要的上下文**:

- `.cursor/ssd/specs/$1/spec.json`、`requirements.md`、`design.md`
- `.cursor/ssd/specs/$1/tasks.md`（如存在，用于合并模式）
- **整个 `.cursor/ssd/steering/` 目录**以获取完整的项目记忆

**验证批准**:

- 如果提供了 `-y` 标志（$2 == "-y"）: 在spec.json中自动批准需求和设计
- 否则: 验证两者都已批准（如未批准则停止，参见安全和回退）
- 确定顺序模式: `sequential = ($3 == "--sequential")`

Feature: $1
Spec directory: .cursor/ssd/specs/$1/
Auto-approve: {true if $2 == "-y", else false}
Sequential mode: {true if sequential else false}

File patterns to read:

- .cursor/ssd/specs/$1/*.{json,md}
- .cursor/ssd/steering/*.md
- .cursor/ssd/settings/rules/tasks-generation.md
- .cursor/ssd/settings/rules/tasks-parallel-analysis.md (include only when sequential mode is false)
- .cursor/ssd/settings/templates/specs/tasks.md

Mode: {generate or merge based on tasks.md existence}
Instruction highlights:

- Map all requirements to tasks and list requirement IDs only (comma-separated) without extra narration
- Promote single actionable sub-tasks to major tasks and keep container summaries concise
- Apply `(P)` markers only when parallel criteria met (omit in sequential mode)
- Mark optional acceptance-criteria-focused test coverage subtasks with `- [ ]*` only when deferrable post-MVP

### 步骤4：生成实施任务

**加载生成规则和模板**:

- 读取 `.cursor/ssd/settings/rules/tasks-generation.md` 以获取原则
- 如果 `sequential == false`: 读取 `.cursor/ssd/settings/rules/tasks-parallel-analysis.md` 以获取并行判断标准
- 读取 `.cursor/ssd/settings/templates/specs/tasks.md` 以获取格式（支持 `(P)` 标记）

**遵循所有规则生成任务列表**:

- 使用spec.json中指定的语言
- 将所有需求映射到任务
- 记录需求覆盖时，仅列出数字需求ID（逗号分隔），不带描述性后缀、括号、翻译或自由格式标签
- 确保包含所有设计组件
- 验证任务进展是逻辑和递增的
- 通过将单子任务结构提升为主要任务来折叠它们，并避免在仅容器的主要任务上重复详细信息（相应地使用模板模式）
- 将 `(P)` 标记应用于满足并行标准的任务（当 `sequential == true` 时跳过标记）
- 仅当可延迟到MVP后时，将可选的验收标准聚焦测试覆盖子任务标记为 `- [ ]*`
- 如果找到现有tasks.md，与新内容合并

### 步骤5：完成

**写入和更新**:

- 创建/更新 `.cursor/ssd/specs/$1/tasks.md`
- 更新spec.json元数据:
    - 设置 `phase: "tasks-generated"`
    - 设置 `approvals.tasks.generated: true, approved: true`
    - 设置 `approvals.requirements.approved: true`
    - 设置 `approvals.design.approved: true`
    - 更新 `updated_at` 时间戳

## 关键约束

- **严格遵循规则**: tasks-generation.md中的所有原则都是强制性的
- **自然语言**: 描述要做什么，而非代码结构细节
- **完整覆盖**: 所有需求必须映射到任务
- **最多2级**: 仅主要任务和子任务（无更深嵌套）
- **顺序编号**: 主要任务递增（1, 2, 3...），永不重复
- **任务集成**: 每个任务必须连接到系统（无孤立工作）
  </instructions>

## 工具指南

- 使用 **Bash** 首先执行版本更新命令（步骤2）
- **先读取**: 在生成之前加载所有上下文、规则和模板
- **最后写入**: 仅在完整分析和验证后生成tasks.md

## 输出描述

以spec.json中指定的语言提供简要摘要：

1. **状态**: 确认任务已在 `.cursor/ssd/specs/$1/tasks.md` 生成
2. **任务摘要**:
    - 总计: X个主要任务，Y个子任务
    - 所有Z个需求已覆盖
    - 平均任务大小: 每个子任务1-3小时
3. **质量验证**:
    - ✅ 所有需求映射到任务
    - ✅ 任务依赖关系已验证
    - ✅ 包含测试任务
4. **下一步**: 查看任务并在准备好时继续

**格式**: 简洁（少于200个汉字）

## 安全和回退

### 错误场景

**需求或设计未批准**:

- **停止执行**: 没有已批准的需求和设计无法继续
- **用户消息**: "在生成任务之前，需求和设计必须已批准"
- **建议操作**: "运行 `/sdd-spec-tasks $1 -y` 以自动批准两者并继续"

**缺少需求或设计**:

- **停止执行**: 两个文档都必须存在
- **用户消息**: "在 `.cursor/ssd/specs/$1/` 缺少requirements.md或design.md"
- **建议操作**: "首先完成需求和设计阶段"

**不完整的需求覆盖**:

- **警告**: "并非所有需求都映射到任务。查看覆盖范围。"
- **需要用户操作**: 确认空白为有意预留，或重新生成任务。

**模板/规则缺失**:

- **用户消息**: "在 `.cursor/ssd/settings/` 中缺少模板或规则文件"
- **回退**: 使用内联基本结构并警告
- **建议操作**: "检查仓库设置或恢复模板文件"
- **缺少数字需求ID**:
    - **停止执行**: requirements.md中的所有需求必须具有数字ID。如果任何需求缺少数字ID，停止并请求在生成任务之前修复requirements.md。

### 下一阶段：实施

**在开始实施之前**:

- **重要**: 在运行 `/sdd-spec-impl` 之前清除对话历史并释放上下文
- 这适用于开始第一个任务或在任务之间切换时
- 新上下文确保干净状态和适当的任务焦点

**如果任务已批准**:

- 执行特定任务: `/sdd-spec-impl $1 1.1`（推荐：在每个任务之间清除上下文）
- 执行多个任务: `/sdd-spec-impl $1 1.1,1.2`（谨慎使用，在任务之间清除上下文）
- 无参数: `/sdd-spec-impl $1`（执行所有待处理任务 - 由于上下文膨胀，不推荐）

**如果需要修改**:

- 提供反馈并重新运行 `/sdd-spec-tasks $1`
- 现有任务用作参考（合并模式）

**注意**: 实施阶段将指导您使用适当的上下文和验证执行任务。

