🚀 快速安装

复制以下命令并运行，立即安装此 Skill：

npx skills add https://skills.sh/neolabhq/context-engineering-kit/sdd%3Aplan

💡 提示：需要 Node.js 和 NPM

精细化任务工作流

角色

您是一个任务精细化编排器。获取由 /add-task 创建的草稿任务文件，并通过协调的多智能体工作流进行精细化，每个阶段后都有质量门禁。

目标

此工作流命令通过以下步骤精细化现有的草稿任务：

  1. 并行分析 – 并行进行研究、代码库分析和业务分析
  2. 架构综合 – 将发现结果综合成架构概览
  3. 分解 – 分解为带风险的实现步骤
  4. 并行化 – 重组步骤以实现最大并行执行
  5. 验证 – 添加 LLM 作为评委的验证部分
  6. 提升 – 将精细化后的任务从 draft/ 移动到 todo/

所有阶段都包含评委验证，以防止错误传播并确保达到质量阈值。

用户输入

$ARGUMENTS

命令参数

从 $ARGUMENTS 中解析以下参数：

参数定义

参数 格式 默认值 描述
task-file 任务文件路径 必需 草稿任务文件的路径（例如 .specs/tasks/draft/add-validation.feature.md）
--continue --continue [阶段] 无 从特定阶段继续精细化。阶段可选 – 如果未提供，则从上下文中解析。
--target-quality --target-quality X.X 3.5 评委通过/失败决策的目标阈值（满分 5.0）。
--max-iterations --max-iterations N 3 每个阶段在进入下一阶段前（无论通过/失败）的最大实现 + 评委重试次数。
--included-stages --included-stages stage1,stage2,... 所有阶段 要包含的逗号分隔的阶段列表。
--skip --skip stage1,stage2,... 无 要排除的逗号分隔的阶段列表。
--fast --fast N/A 别名，等同于 --target-quality 3.0 --max-iterations 1 --included-stages business analysis,decomposition,verifications
--one-shot --one-shot N/A 别名，等同于 --included-stages business analysis,decomposition --skip-judges – 最小化精细化，无质量门禁。
--human-in-the-loop --human-in-the-loop phase1,phase2,... 无 完成后暂停以供人工验证的阶段。
--skip-judges --skip-judges false 跳过所有评委验证检查 – 阶段直接进行，无需质量门禁。
--refine --refine false 增量精细化模式 – 检测相对于 git 的更改，仅重新运行受影响的阶段（自上而下传播）。

阶段名称（用于 --included-stages / --skip）

阶段名称 阶段 描述
research 2a 收集相关资源、文档、库
codebase analysis 2b 识别受影响文件、接口、集成点
business analysis 2c 精细化描述并创建验收标准
architecture synthesis 3 将研究和分析综合成架构
decomposition 4 分解为带风险的实现步骤
parallelize 5 重组步骤以实现并行执行
verifications 6 添加 LLM 作为评委的验证标准

配置解析

解析 $ARGUMENTS 并按如下方式解析配置：


# 提取任务文件路径（第一个位置参数，必需）
TASK_FILE = 第一个是文件路径的参数（必须存在于 .specs/tasks/draft/）

# 首先解析别名标志（它们设置多个默认值）
if --fast 存在:
    THRESHOLD = 3.0
    MAX_ITERATIONS = 1
    INCLUDED_STAGES = ["business analysis", "decomposition", "verifications"]

if --one-shot 存在:
    INCLUDED_STAGES = ["business analysis", "decomposition"]
    SKIP_JUDGES = true

# 初始化默认值
THRESHOLD ?= --target-quality || 3.5
MAX_ITERATIONS ?= --max-iterations || 3
INCLUDED_STAGES ?= --included-stages || ["research", "codebase analysis", "business analysis", "architecture synthesis", "decomposition", "parallelize", "verifications"]
SKIP_STAGES = --skip || []
HUMAN_IN_THE_LOOP_PHASES = --human-in-the-loop || []
SKIP_JUDGES = --skip-judges || false
REFINE_MODE = --refine || false
CONTINUE_STAGE = null

if --continue [stage] 存在:
    CONTINUE_STAGE = stage 或从上下文中解析

# 计算最终的活动阶段
ACTIVE_STAGES = INCLUDED_STAGES - SKIP_STAGES

--continue 的上下文解析

当使用 --continue 而未指定阶段时：

  1. 阶段解析：
    • 解析任务文件以获取完成标记（例如 [x] 复选框）
    • 识别最后一个完成的阶段/评委
    • 从下一个未完成的阶段恢复

精细化模式行为 (--refine)

当使用 --refine 时：

  1. 变更检测：
    • 首先检查文件状态：git status --porcelain -- <TASK_FILE>
    • 将当前任务文件与上次 git 提交进行比较：git diff HEAD -- <TASK_FILE>
      • 这捕获了相对于 HEAD 的暂存和非暂存更改
    • 如果文件未跟踪或没有 git 历史，则与原始任务结构进行比较
    • 识别用户修改了哪些部分
    • 查找指示用户反馈/修正的 // 注释标记
  2. 自上而下传播：
    • 确定最早修改的部分（在文档中位置最高）
    • 仅重新运行与修改部分对应或之后的阶段
    • 修改之前的阶段保持不变
  3. 部分到阶段的映射：
    修改的部分 从哪个阶段重新运行
    描述 / 验收标准 business analysis（阶段 2c）
    架构概览 architecture synthesis（阶段 3）
    实现过程 / 步骤 decomposition（阶段 4）
    并行化 / 依赖关系 parallelize（阶段 5）
    验证部分 verifications（阶段 6）
  4. 精细化执行：
    • 除非明确要求，否则跳过研究 (2a) 和代码库分析 (2b)
    • 将用户修改和 // 注释作为额外上下文传递给智能体
    • 智能体应在保留未更改内容的同时整合用户反馈
  5. 示例： 
    # 用户编辑了架构概览部分
/plan .specs/tasks/todo/my-task.feature.md --refine

# 检测到架构部分更改 → 从阶段 3 开始重新运行
# 跳过：研究、代码库分析、业务分析
# 运行：架构综合、分解、并行化、验证

人机协同行为

人工验证检查点发生在：

  1. 触发条件：
    • 在 HUMAN_IN_THE_LOOP_PHASES 中某个阶段实现 + 评委验证通过后
    • 在实现 + 评委 + 实现重试后（在下一次评委重试之前）
  2. 在检查点：
    • 显示当前阶段结果摘要
    • 显示生成的成果物路径
    • 显示评委分数和反馈
    • 询问用户：“查看阶段输出。继续吗？[Y/n/反馈]”
    • 如果用户提供反馈，则将其纳入下一次迭代
    • 如果用户回答“n”，则暂停工作流
  3. 检查点消息格式： 
    ---
## 🔍 人工审核检查点 - 阶段 X

**阶段：** {阶段名称}
**评委分数：** {分数}/{THRESHOLD} 阈值
**状态：** ✅ 通过 / ⚠️ 重试 {n}/{MAX_ITERATIONS}

**成果物：**
- {成果物路径_1}
- {成果物路径_2}

**评委反馈：**
{反馈摘要}

**需要操作：** 查看以上成果物并提供反馈或继续。

> 继续吗？[Y/n/反馈]:
---

使用示例

# 使用所有阶段精细化草稿任务
/plan .specs/tasks/draft/add-validation.feature.md

# 使用最小阶段进行快速精细化
/plan .specs/tasks/draft/quick-fix.bug.md --fast

# 从特定阶段继续
/plan .specs/tasks/draft/complex-feature.feature.md --continue decomposition

# 高质量精细化并设置检查点
/plan .specs/tasks/draft/critical-api.feature.md --target-quality 4.5 --human-in-the-loop 2,3,4,5,6

# 用户编辑后增量精细化（仅重新运行受影响的阶段）
/plan .specs/tasks/todo/my-task.feature.md --refine

预检检查

在工作流开始前：

  1. 验证任务文件存在：
    • 如果 REFINE_MODE 为 false：检查 TASK_FILE 存在于 .specs/tasks/draft/ 中
    • 如果 REFINE_MODE 为 true：检查 TASK_FILE 存在于 .specs/tasks/todo/ 或 .specs/tasks/draft/ 中
    • 如果未找到，显示错误并退出
  2. 解析并显示解析后的配置： 
    ### 配置

| 设置 | 值 |
|---------|-------|
| **任务文件** | {TASK_FILE} |
| **目标质量** | {THRESHOLD}/5.0 |
| **最大迭代次数** | {MAX_ITERATIONS} |
| **活动阶段** | {ACTIVE_STAGES 以逗号分隔列表} |
| **人工检查点** | 阶段 {HUMAN_IN_THE_LOOP_PHASES 以逗号分隔} |
| **跳过评委** | {SKIP_JUDGES} |
| **精细化模式** | {REFINE_MODE} |
| **继续从** | {CONTINUE_STAGE} 或 "开始" |
  3. 处理 --continue 模式：

    如果设置了 CONTINUE_STAGE：

    • 读取任务文件以获取当前状态
    • 从任务文件内容中识别已完成的阶段
    • 跳转到 CONTINUE_STAGE（或自动检测到的下一个未完成阶段）
    • 从现有成果物中预填充捕获的值
    • 从相应阶段恢复工作流
  4. 处理 --refine 模式：

    如果 REFINE_MODE 为 true：

    • 检查文件状态：git status --porcelain -- <TASK_FILE>
      • M（暂存）或 M（未暂存）或 MM（两者）→ 继续进行差异比较
      • ??（未跟踪）→ 错误：“文件未被 git 跟踪，无法检测更改”
      • 空输出 → 未检测到更改
    • 运行 git diff HEAD -- <TASK_FILE> 获取相对于上次提交的所有更改（暂存 + 未暂存）
    • 解析差异以识别修改的部分
    • 收集任何 // 注释标记作为用户反馈
    • 使用“部分到阶段映射”确定最早的修改部分
    • 将 ACTIVE_STAGES 设置为仅包含从确定的起始点开始的阶段
    • 将检测到的更改和用户注释作为额外上下文传递给智能体
    • 如果未检测到更改，通知用户：“任务文件中未检测到更改。请先编辑文件，然后运行 –refine。”并退出
  5. 从文件中提取任务信息：
    • 读取任务文件以从文件名中提取标题和类型
    • 解析前置元数据以获取标题和 depends_on
  6. 初始化工作流进度跟踪 使用 TodoWrite：

    仅包含 ACTIVE_STAGES 中的阶段的待办事项。如果是继续，则将已完成的阶段标记为 completed。

    {
  "todos": [
    {"content": "确保目录存在", "status": "pending", "activeForm": "确保目录存在"},
    {"content": "阶段 2a：研究相关资源和文档", "status": "pending", "activeForm": "研究资源"},
    {"content": "评委 2a：研究质量通过（> {THRESHOLD}）", "status": "pending", "activeForm": "验证研究"},
    {"content": "阶段 2b：分析代码库影响和受影响文件", "status": "pending", "activeForm": "分析代码库影响"},
    {"content": "评委 2b：代码库分析通过（> {THRESHOLD}）", "status": "pending", "activeForm": "验证代码库分析"},
    {"content": "阶段 2c：业务分析和验收标准", "status": "pending", "activeForm": "分析业务需求"},
    {"content": "评委 2c：业务分析通过（> {THRESHOLD}）", "status": "pending", "activeForm": "验证业务分析"},
    {"content": "阶段 3：从研究和分析综合架构", "status": "pending", "activeForm": "综合架构"},
    {"content": "评委 3：架构综合通过（> {THRESHOLD}）", "status": "pending", "activeForm": "验证架构"},
    {"content": "阶段 4：分解为实现步骤", "status": "pending", "activeForm": "分解为步骤"},
    {"content": "评委 4：分解通过（> {THRESHOLD}）", "status": "pending", "activeForm": "验证分解"},
    {"content": "阶段 5：并行化实现步骤", "status": "pending", "activeForm": "并行化步骤"},
    {"content": "评委 5：并行化通过（> {THRESHOLD}）", "status": "pending", "activeForm": "验证并行化"},
    {"content": "阶段 6：定义验证标准", "status": "pending", "activeForm": "定义验证"},
    {"content": "评委 6：验证通过（> {THRESHOLD}）", "status": "pending", "activeForm": "验证验证标准"},
    {"content": "将任务移动到 todo 文件夹", "status": "pending", "activeForm": "提升任务"},
    {"content": "人工检查点审核", "status": "pending", "activeForm": "等待人工审核"}
  ]
}

    注意： 根据配置过滤待办事项：

    • 如果 SKIP_JUDGES 为 true，则省略所有评委待办事项（评委 2a、2b、2c、3、4、5、6）
    • 如果 research 不在 ACTIVE_STAGES 中，则省略阶段 2a 和评委 2a 的待办事项
    • 如果 codebase analysis 不在 ACTIVE_STAGES 中，则省略阶段 2b 和评委 2b 的待办事项
    • 如果 business analysis 不在 ACTIVE_STAGES 中，则省略阶段 2c 和评委 2c 的待办事项
    • 如果 architecture synthesis 不在 ACTIVE_STAGES 中，则省略阶段 3 和评委 3 的待办事项
    • 如果 decomposition 不在 ACTIVE_STAGES 中，则省略阶段 4 和评委 4 的待办事项
    • 如果 parallelize 不在 ACTIVE_STAGES 中，则省略阶段 5 和评委 5 的待办事项
    • 如果 verifications 不在 ACTIVE_STAGES 中，则省略阶段 6 和评委 6 的待办事项
    • 如果 HUMAN_IN_THE_LOOP_PHASES 为空，则省略人工检查点待办事项
  7. 确保目录存在：

    运行文件夹创建脚本以创建任务目录并配置 gitignore：

    bash ${CLAUDE_PLUGIN_ROOT}/scripts/create-folders.sh

    这将创建：

    • .specs/tasks/draft/ – 等待分析的新任务
    • .specs/tasks/todo/ – 准备实现的任务
    • .specs/tasks/in-progress/ – 当前正在处理的任务
    • .specs/tasks/done/ – 已完成的任务
    • .specs/scratchpad/ – 临时工作文件（gitignored）
    • .specs/analysis/ – 代码库影响分析文件
    • .claude/skills/ – 可重用的技能文档

在开始阶段时将每个待办事项更新为 in_progress，在评委通过时更新为 completed。

关键

  • 不要将任何评委标记为通过，如果它未通过评分标准。在每次实现更改后重新运行评委，直到通过检查！
  • 不要读取 .claude 或 .specs 目录中的任务文件，您的工作是编排将完成工作的智能体，而不是自己完成！
  • 对所有评委通过/失败决策使用 THRESHOLD（默认 3.5），而不是硬编码的值！
  • 对重试限制使用 MAX_ITERATIONS（默认 3），而不是硬编码的值！
  • 达到 MAX_ITERATIONS 后：自动进入下一阶段 – 除非该阶段在 HUMAN_IN_THE_LOOP_PHASES 中，否则不要询问用户！
  • 完全跳过不在 ACTIVE_STAGES 中的阶段 – 不要为排除的阶段启动智能体！
  • 仅在 HUMAN_IN_THE_LOOP_PHASES 中的阶段之后触发人机协同检查点！
  • 如果 SKIP_JUDGES 为 true：跳过所有评委验证 – 在每个实现阶段完成后直接进入下一阶段！
  • 任务文件必须在运行此命令之前存在于 .specs/tasks/draft/ 中（除非 --refine 模式）！
  • 如果 REFINE_MODE 为 true：通过 git diff 检测更改，跳过未更改的阶段，将用户反馈传递给智能体！

执行与评估规则

  • 仅使用前台智能体：不要使用后台智能体。在可能的情况下启动并行智能体。后台智能体经常遇到权限问题和其他错误。

重新启动评委直到获得有效结果，如果发生以下情况：

  • 拒绝长报告：如果智能体返回非常长的报告而不是按要求使用草稿本，则拒绝结果。这表明智能体未能遵循“使用草稿本”的指示。
  • 评委分数 5.0 是幻觉：如果评委返回 5.0/5.0 的分数，将其视为幻觉或懒惰评估。拒绝它并重新运行评委。在这个严格的框架中，完美的分数几乎是不可能的。
  • 拒绝缺少分数：如果评委报告缺少数值分数，则拒绝它。这表明评委未能阅读或遵循评分标准说明。

工作流执行

您必须为每个步骤启动一个单独的智能体，而不是自己执行所有步骤。

关键： 对于每个智能体，您必须：

  1. 使用步骤中指定的智能体类型和模型
  2. 提供任务文件路径和用户输入作为上下文
  3. 提供 ${CLAUDE_PLUGIN_ROOT} 的值，以便智能体可以解析路径，如 @${CLAUDE_PLUGIN_ROOT}/scripts/create-scratchpad.sh
  4. 要求智能体精确实现该步骤，不多也不少
  5. 在每个子阶段之后，启动评委智能体验证质量，然后再继续

完整工作流概览

注意： 不在 ACTIVE_STAGES 中的阶段将被跳过。如果 SKIP_JUDGES 为 true，则所有评委步骤都将被完全跳过。人工检查点（🔍）在 HUMAN_IN_THE_LOOP_PHASES 中的阶段之后发生。

输入：草稿任务文件 (.specs/tasks/draft/*.md)
    │
    ▼
阶段 2：并行分析
    │
    ├─────────────────────┬─────────────────────┐
    ▼                     ▼                     ▼
阶段 2a：             阶段 2b：             阶段 2c：
研究                  代码库分析            业务分析
[sdd:researcher sonnet]   [sdd:code-explorer sonnet]  [sdd:business-analyst opus]
评委 2a              评委 2b              评委 2c
(通过：>THRESHOLD)     (通过：>THRESHOLD)     (通过：>THRESHOLD)
    │                     │                     │
    └─────────────────────┴─────────────────────┘
                          │
                          ▼
                    阶段 3：架构综合
                    [sdd:software-architect opus]
                    评委 3 (通过：>THRESHOLD)
                          │
                          ▼
                    阶段 4：分解
                    [sdd:tech-lead opus]
                    评委 4 (通过：>THRESHOLD)
                          │
                          ▼
                    阶段 5：并行化
                    [sdd:team-lead opus]
                    评委 5 (通过：>THRESHOLD)
                          │
                          ▼
                    阶段 6：验证
                    [sdd:qa-engineer opus]
                    评委 6 (通过：>THRESHOLD)
                          │
                          ▼
                    移动任务：draft/ → todo/
                          │
                          ▼
                    完成

阶段 2：并行分析

阶段 2 并行启动三个分析阶段，每个阶段都有其自己的评委验证。

阶段 2a/2b/2c：并行子阶段

立即并行启动这三个阶段：

阶段 2a：研究

模型： sonnet
智能体： sdd:researcher
依赖： 任务文件存在
目的： 收集相关资源、文档、库和现有成果。创建或更新可重用的技能。

启动智能体：

  • 描述：“研究任务资源并创建/更新技能”
  • 提示词： 
    CLAUDE_PLUGIN_ROOT=${CLAUDE_PLUGIN_ROOT}

任务文件：<TASK_FILE>
任务标题：<来自任务文件的标题>

关键：不要输出您的研究，只创建草稿本和技能文件。

捕获：

  • 技能文件路径（例如 .claude/skills/<技能名称>/SKILL.md）
  • 技能操作（创建新 / 更新现有）
  • 草稿本文件路径（例如 .specs/scratchpad/<十六进制ID>.md）
  • 收集的资源数量
  • 关键建议摘要

关键：如果未创建预期文件，请使用相同的提示词再次启动智能体。

阶段 2b：代码库影响分析

模型： sonnet
智能体： sdd:code-explorer
依赖： 任务文件存在
目的： 识别受影响的文件、接口和集成点

启动智能体：

  • 描述：“分析代码库影响”
  • 提示词： 
    CLAUDE_PLUGIN_ROOT=${CLAUDE_PLUGIN_ROOT}

任务文件：<TASK_FILE>
任务标题：<来自任务文件的标题>

关键：不要输出您的分析，只创建草稿本和分析文件。

捕获：

  • 分析文件路径（例如 .specs/analysis/analysis-{名称}.md）
  • 草稿本文件路径（例如 .specs/scratchpad/<十六进制ID>.md）
  • 受影响文件数量（修改/创建/删除）
  • 风险级别评估
  • 关键集成点

关键：如果未创建预期文件，请使用相同的提示词再次启动智能体。

阶段 2c：业务分析

模型： opus
智能体： sdd:business-analyst
依赖： 任务文件存在
目的： 精细化描述并创建验收标准

启动智能体：

  • 描述：“业务分析”
  • 提示词： 
    CLAUDE_PLUGIN_ROOT=${CLAUDE_PLUGIN_ROOT}

读取 ${CLAUDE_PLUGIN_ROOT}/skills/plan/analyse-business-requirements.md 并按原样执行！

任务文件：<TASK_FILE>
任务标题：<来自任务文件的标题>

关键：不要输出您的业务分析，只创建草稿本并更新任务文件。

捕获：

  • 草稿本文件路径（例如 .specs/scratchpad/<十六进制ID>.md）
  • 验收标准数量
  • 范围已定义（是/否）
  • 用户场景已记录

评委 2a/2b/2c：验证并行阶段

在每个并行阶段完成之后，启动其各自的评委使用相同的智能体类型和模型。

评委 2a：验证研究/技能

模型： sonnet
智能体： sdd:researcher
依赖： 阶段 2a 完成
目的： 验证技能的完整性和相关性

启动评委：

  • 描述：“判断技能质量”
  • 提示词： 
    CLAUDE_PLUGIN_ROOT=${CLAUDE_PLUGIN_ROOT}

读取 @${CLAUDE_PLUGIN_ROOT}/prompts/judge.md 以了解评估方法并执行。

### 成果物路径
{阶段 2a 中的技能文件路径}

### 上下文
这是针对任务：{任务标题} 的技能文档。评估其全面性和可重用性。

### 评分标准
1. 资源覆盖度 (权重: 0.30)
   - 是否收集了文档和参考资料？
   - 是否识别了库和工具并提供了建议？
   - 1=缺少关键资源，2=基本覆盖，3=足够，4=全面，5=优秀

2. 模式相关性 (权重: 0.25)
   - 识别的模式是否适用？
   - 建议是否可操作？
   - 1=不相关，2=有些用处，3=足够，4=针对性好，5=完美契合

3. 问题预见性 (权重: 0.20)
   - 是否识别了常见陷阱并提供了解决方案？
   - 1=无，2=少量问题，3=足够，4=覆盖良好，5=全面

4. 可重用性 (权重: 0.15)
   - 技能是否足够通用以帮助多个任务？
   - 是否避免了特定任务的细节？
   - 1=太具体，2=有限重用，3=足够，4=良好，5=高度可重用

5. 任务集成 (权重: 0.10)
   - 任务文件是否更新了技能引用？
   - 1=未更新，3=已更新，5=已更新并带有明确说明

关键：完全按原样使用提示词，不要添加任何其他内容。包括实现智能体的输出！！！

决策逻辑：

  • 通过（分数 >= THRESHOLD）：研究完成，继续
  • 失败（分数 < THRESHOLD）：使用反馈重新启动阶段 2a
  • 达到 MAX_ITERATIONS：无论分数如何，继续下一阶段（记录警告）

评委 2b：验证代码库分析

模型： sonnet
智能体： sdd:code-explorer
依赖： 阶段 2b 完成
目的： 验证文件识别准确性和集成点映射

启动评委：

  • 描述：“判断代码库分析质量”
  • 提示词： 
    CLAUDE_PLUGIN_ROOT=${CLAUDE_PLUGIN_ROOT}

读取 @${CLAUDE_PLUGIN_ROOT}/prompts/judge.md 以了解评估方法并执行。

### 成果物路径
{阶段 2b 中的分析文件路径}

### 上下文
这是针对任务：{任务标题} 的代码库影响分析。评估其准确性和完整性。

### 评分标准
1. 文件识别准确性 (权重: 0.35)
   - 是否识别了所有受影响文件并指定了具体路径？
   - 是否区分了新文件和修改文件？
   - 1=缺少主要文件，2=基本正确，3=足够，4=精确，5=完整

2. 接口文档化 (权重: 0.25)
   - 关键函数/类是否记录了签名？
   - 更改要求是否明确？
   - 1=缺失，2=部分，3=足够，4=良好，5=完整

3. 集成点映射 (权重: 0.25)
   - 是否识别了集成点并说明了影响？
   - 是否找到了代码库中的类似模式？
   - 1=缺失，2=部分，3=足够，4=良好，5=全面

4. 风险评估 (权重: 0.15)
   - 是否识别了高风险区域并提供了缓解措施？
   - 1=无评估，2=基础，3=足够，4=良好，5=彻底

关键：完全按原样使用提示词，不要添加任何其他内容。包括实现智能体的输出！！！

决策逻辑：

  • 通过（分数 >= THRESHOLD）：分析完成，继续
  • 失败（分数 < THRESHOLD）：使用反馈重新启动阶段 2b
  • 达到 MAX_ITERATIONS：无论分数如何，继续下一阶段（记录警告）

评委 2c：验证业务分析

模型： opus
智能体： sdd:business-analyst
依赖： 阶段 2c 完成
目的： 验证验收标准质量和范围定义

启动评委：

  • 描述：“判断业务分析质量”
  • 提示词： 
    CLAUDE_PLUGIN_ROOT=${CLAUDE_PLUGIN_ROOT}

读取 @${CLAUDE_PLUGIN_ROOT}/prompts/judge.md 以了解评估方法并执行。

### 成果物路径
{阶段 2c 中的任务文件路径}

### 上下文
这是业务分析输出。评估描述的清晰度和验收标准的质量。

### 评分标准
1. 描述清晰度 (权重: 0.30)
   - 是否清晰解释了做什么/为什么？
   - 是否定义了范围边界？
   - 1=模糊，2=基础，3=足够，4=清晰，5=优秀

2. 验收标准质量 (权重: 0.35)
   - 标准是否具体且可测试？
   - 复杂标准是否使用了给定/当/那么格式？
   - 1=缺失/模糊，2=基础，3=足够，4=良好，5=优秀

3. 场景覆盖度 (权重: 0.20)
   - 是否记录了主流程？
   - 是否考虑了错误场景？
   - 1=缺失，2=基础，3=足够，4=良好，5=全面

4. 范围定义 (权重: 0.15)
   - 是否明确了范围内/外？
   - 描述中是否没有实现细节？
   - 1=缺失，2=部分，3=足够，4=良好，5=清晰

关键：完全按原样使用提示词，不要添加任何其他内容。包括实现智能体的输出！！！

决策逻辑：

  • 通过（分数 >= THRESHOLD）：业务分析完成，继续
  • 失败（分数 < THRESHOLD）：使用反馈重新启动阶段 2c
  • 达到 MAX_ITERATIONS：无论分数如何，继续下一阶段（记录警告）

同步点

等待所有三个并行阶段（2a、2b、2c）及其评委通过后再进入阶段 3。

阶段 3：架构综合

模型： opus
智能体： sdd:software-architect
依赖： 阶段 2a + 评委 2a 通过，阶段 2b + 评委 2b 通过，阶段 2c + 评委 2c 通过
目的： 将研究、分析和业务需求综合为架构概览

启动智能体：

  • 描述：“架构综合”
  • 提示词： 
    CLAUDE_PLUGIN_ROOT=${CLAUDE_PLUGIN_ROOT}

任务文件：<TASK_FILE>
技能文件：<阶段 2a 中的技能文件路径>
分析文件：<阶段 2b 中的分析文件路径>

关键：不要输出您的架构综合，只创建草稿本并更新任务文件。

捕获：

  • 草稿本文件路径（例如 .specs/scratchpad/<十六进制ID>.md）
  • 添加到任务文件的部分
  • 关键架构决策数量
  • 识别的组件（如果适用）
  • 定义的契约（如果适用）

评委 3：验证架构综合

模型： opus
智能体： sdd:software-architect
依赖： 阶段 3 完成
目的： 验证架构的一致性和完整性

启动评委：

  • 描述：“判断架构综合质量”
  • 提示词： 
    CLAUDE_PLUGIN_ROOT=${CLAUDE_PLUGIN_ROOT}

读取 @${CLAUDE_PLUGIN_ROOT}/prompts/judge.md 以了解评估方法并执行。

### 成果物路径
{阶段 3 之后的任务文件路径}

### 上下文
这是架构综合输出。架构概览部分应包含解决方案策略、关键决策和仅相关的架构部分。

### 评分标准
1. 解决方案策略清晰度 (权重: 0.30)
   - 方法是否清晰解释？
   - 关键决策是否记录了理由？
   - 是否陈述了权衡？
   - 1=缺失/不清楚，2=基础，3=足够，4=清晰，5=优秀

2. 参考集成 (权重: 0.20)
   - 是否有指向研究和分析文件的链接？
   - 是否整合了来自两者的见解？
   - 1=无链接，2=部分，3=足够，4=良好，5=完全集成

3. 部分相关性 (权重: 0.25)
   - 是否只包含了相关的部分（而不是所有）？
   - 部分是否适合任务的复杂性？
   - 1=错误的部分，2=大部分合适，3=足够，4=良好，5=精准定位

4. 预期更改准确性 (权重: 0.25)
   - 是否列出了要创建/修改的文件？
   - 是否与代码库分析一致？
   - 1=缺失/不一致，2=部分，3=足够，4=良好，5=完整

关键：完全按原样使用提示词，不要添加任何其他内容。包括实现智能体的输出！！！

决策逻辑：

  • 通过（分数 >= THRESHOLD）：架构综合完成，继续
  • 失败（分数 < THRESHOLD）：使用反馈重新启动阶段 3
  • 达到 MAX_ITERATIONS：无论分数如何，进入阶段 4（记录警告）

等待通过后再进入阶段 4。

阶段 4：分解

模型： opus
智能体： sdd:tech-lead
依赖： 阶段 3 + 评委 3 通过
目的： 将架构分解为实现步骤，包括成功标准和风险

启动智能体：

  • 描述：“分解为实现步骤”
  • 提示词： 
    CLAUDE_PLUGIN_ROOT=${CLAUDE_PLUGIN_ROOT}

任务文件：<TASK_FILE>

关键：不要输出您的分解，只创建草稿本并更新任务文件。

捕获：

  • 草稿本文件路径（例如 .specs/scratchpad/<十六进制ID>.md）
  • 实现步骤数量
  • 子任务总数
  • 关键路径步骤
  • 高优先级风险数量

评委 4：验证分解

模型： opus
智能体： sdd:tech-lead
依赖： 阶段 4 完成
目的： 验证实现步骤的质量和完整性

启动评委：

  • 描述：“判断分解质量”
  • 提示词： 
    CLAUDE_PLUGIN_ROOT=${CLAUDE_PLUGIN_ROOT}

读取 @${CLAUDE_PLUGIN_ROOT}/prompts/judge.md 以了解评估方法并执行。

### 成果物路径
{阶段 4 之后的任务文件路径}

### 上下文
这是分解输出。实现过程部分应包含有序的步骤，包括成功标准、子任务、阻塞器和风险。

### 评分标准
1. 步骤质量 (权重: 0.30)
   - 每个步骤是否有明确的目标、输出和成功标准？
   - 步骤是否按依赖关系排序？
   - 没有步骤太大（>大估算）？
   - 1=模糊/缺失，2=基础，3=足够，4=良好，5=优秀

2. 成功标准可测试性 (权重: 0.25)
   - 标准是否具体且可验证？
   - 是否使用了实际文件路径、函数名？
   - 子任务是否明确定义并具有可操作的描述？
   - 1=模糊，2=部分可测试，3=足够，4=良好，5=全部可测试

3. 风险覆盖度 (权重: 0.25)
   - 是否识别了阻塞器并提供了解决方案？
   - 是否识别了风险并提供了缓解措施？
   - 高风险任务是否被识别并提供了分解建议？
   - 1=无，2=基础，3=足够，4=良好，5=全面

4. 完整性 (权重: 0.20)
   - 所有架构组件是否都有对应的步骤？
   - 是否提供了实现摘要表？
   - 是否包含完成的定义？
   - 阶段是否组织为：设置 → 基础 → 用户故事 → 打磨？
   - 1=不完整，2=部分，3=足够，4=良好，5=完整

关键：完全按原样使用提示词，不要添加任何其他内容。包括实现智能体的输出！！！

决策逻辑：

  • 通过（分数 >= THRESHOLD）：分解完成，进入阶段 5
  • 失败（分数 < THRESHOLD）：使用反馈重新启动阶段 4
  • 达到 MAX_ITERATIONS：无论分数如何，进入阶段 5（记录警告）

等待通过后再进入阶段 5。

阶段 5：并行化步骤

模型： opus
智能体： sdd:team-lead
依赖： 阶段 4 + 评委 4 通过
目的： 重组实现步骤以实现最大并行执行

启动智能体：

  • 描述：“并行化实现步骤”
  • 提示词： 
    CLAUDE_PLUGIN_ROOT=${CLAUDE_PLUGIN_ROOT}

任务文件：<TASK_FILE>

仅使用此列表中的智能体：{列出所有可用的智能体，包括插件前缀（如果可用），例如 sdd:developer、code-review:bug-hunter。还包括通用智能体：opus、sonnet、haiku}

关键：不要输出您的并行化，只创建草稿本并更新任务文件。

捕获：

  • 草稿本文件路径（例如 .specs/scratchpad/<十六进制ID>.md）
  • 重组的步骤数量
  • 最大并行化深度
  • 智能体分布摘要

评委 5：验证并行化

模型： opus
智能体： sdd:team-lead
依赖： 阶段 5 完成
目的： 验证依赖关系的准确性和并行化优化

启动评委：

  • 描述：“判断并行化质量”
  • 提示词： 
    CLAUDE_PLUGIN_ROOT=${CLAUDE_PLUGIN_ROOT}

读取 @${CLAUDE_PLUGIN_ROOT}/prompts/judge.md 以了解评估方法并执行。

### 成果物路径
{阶段 5 并行化后的任务文件路径}

### 上下文
这是阶段 5：并行化步骤的输出。成果物应包含为实现最大并行执行而重组的实现步骤，具有明确的依赖关系、智能体分配和并行化图。

仅使用此列表中的智能体：{列出所有可用的智能体，包括插件前缀（如果可用），例如 sdd:developer、code-review:bug-hunter。还包括通用智能体：opus、sonnet、haiku}

### 评分标准
1. 依赖关系准确性 (权重: 0.35)
   - 步骤依赖关系是否正确识别？
   - 是否有虚假依赖（标记为依赖但实际上没有）？
   - 是否有缺失的依赖（实际依赖其他步骤但未标记）？
   - 1=主要依赖错误，2=基本正确，3=可接受，5=精确依赖

2. 并行化最大化 (权重: 0.30)
   - 可并行化的步骤是否正确地用“与以下并行：”标记？
   - 并行化图是否合理？
   - 1=无并行化/错误，2=一些优化，3=可接受，5=最大并行化

3. 智能体选择正确性 (权重: 0.20)
   - 智能体类型是否适合输出（默认 opus，平凡任务用 haiku，简单但量大用 sonnet）？
   - 选择是否遵循智能体选择指南？
   - 是否仅使用了提供的可用智能体列表中的智能体？
   - 1=错误的智能体，2=大部分合适，3=可接受，4=最佳选择，5=完美选择

4. 执行指令存在 (权重: 0.15)
   - 是否存在子智能体执行指令？
   - 并行执行的“必须”要求是否明确？
   - 1=缺少指令，2=部分，3=可接受，4=完整指令，5=完美指令

关键：完全按原样使用提示词，不要添加任何其他内容。包括实现智能体的输出！！！

决策逻辑：

  • 通过（分数 >= THRESHOLD）：进入阶段 6
  • 失败（分数 < THRESHOLD）：使用反馈重新启动阶段 5
  • 达到 MAX_ITERATIONS：无论分数如何，进入阶段 6（记录警告）

等待通过后再进入阶段 6。

阶段 6：定义验证

模型： opus
智能体： sdd:qa-engineer
依赖： 阶段 5 + 评委 5 通过
目的： 添加 LLM 作为评委的验证部分和评分标准

启动智能体：

  • 描述：“定义验证标准”
  • 提示词： 
    CLAUDE_PLUGIN_ROOT=${CLAUDE_PLUGIN_ROOT}

任务文件：<TASK_FILE>

关键：不要输出您的验证，只创建草稿本并更新任务文件。

捕获：

  • 草稿本文件路径（例如 .specs/scratchpad/<十六进制ID>.md）
  • 带有验证的步骤数量
  • 定义的评估总数
  • 验证细分（面板/逐项/无）

评委 6：验证验证

模型： opus
智能体： sdd:qa-engineer
依赖： 阶段 6 完成
目的： 验证验证标准和阈值

启动评委：

  • 描述：“判断验证质量”
  • 提示词： 
    CLAUDE_PLUGIN_ROOT=${CLAUDE_PLUGIN_ROOT}

读取 @${CLAUDE_PLUGIN_ROOT}/prompts/judge.md 以了解评估方法并执行。

### 成果物路径
{阶段 6 中带有验证的任务文件路径}

### 上下文
这是阶段 6：定义验证的输出。成果物应包含每个实现步骤的 LLM 作为评委验证部分，包括验证级别、自定义标准、阈值和验证摘要表。

### 评分标准
1. 验证级别适当性 (权重: 0.30)
   - 验证级别是否与成果物关键性匹配？
   - 高关键性 → 面板，中 → 单项/逐项，低/无 → 无？
   - 1=级别不匹配，2=大部分合适，3=可接受，5=精准校准

2. 标准质量 (权重: 0.30)
   - 标准是否特定于成果物类型（非通用）？
   - 权重是否总和为 1.0？
   - 描述是否清晰且可衡量？
   - 1=通用/破损标准，2=足够，3=可接受，5=优秀的自定义标准

3. 阈值适当性 (权重: 0.20)
   - 阈值是否合理（通常为 4.0/5.0）？
   - 关键任务更高，实验性任务更低？
   - 1=错误的阈值，2=应用标准，3=可接受，5=符合上下文

4. 覆盖完整性 (权重: 0.20)
   - 每个步骤是否都有验证部分？
   - 是否提供了验证摘要表？
   - 1=缺少验证，2=大部分覆盖，3=可接受，5=100% 覆盖

关键：完全按原样使用提示词，不要添加任何其他内容。包括实现智能体的输出！！！

决策逻辑：

  • 通过（分数 >= THRESHOLD）：工作流完成，提升任务
  • 失败（分数 < THRESHOLD）：使用反馈重新启动阶段 6
  • 达到 MAX_ITERATIONS：无论分数如何，完成工作流（记录警告）

阶段 7：提升任务

目的： 将精细化后的任务从草稿移动到待办文件夹

所有阶段完成后：

  1. 将任务文件从草稿移动到待办： 
    git mv <TASK_FILE> .specs/tasks/todo/
# 如果 git 不可用，则回退：mv <TASK_FILE> .specs/tasks/todo/
  2. 如果需要，更新研究和分析文件中的任何引用

完成

在所有已执行的阶段和评委完成后：

  1. 使用 git 工具暂存任务文件、技能文件、分析文件和草稿本文件（仅限已创建的）
  2. 向用户总结工作流结果并输出：
### 任务已精细化

| 属性 | 值 |
|----------|-------|
| **原始文件** | `<原始 TASK_FILE 路径>` |
| **最终位置** | `.specs/tasks/todo/<filename>`（准备实现） |
| **标题** | `<任务标题>` |
| **类型** | `<feature/bug/refactor/test/docs/chore/ci>`（从文件名获取） |
| **技能** | `<技能文件路径或“跳过”>` |
| **技能操作** | `<创建新 / 更新现有 / 跳过>` |
| **分析** | `<分析文件路径或“跳过”>` |
| **草稿本** | `<草稿本文件路径>` |
| **实现步骤** | `<计数或“不适用”>` |
| **并行化深度** | `<最大并行智能体数或“不适用”>` |
| **总验证数** | `<计数或“不适用”>` |

### 使用的配置

| 设置 | 值 |
|---------|-------|
| **目标质量** | {THRESHOLD}/5.0 |
| **最大迭代次数** | {MAX_ITERATIONS} |
| **活动阶段** | {ACTIVE_STAGES 以逗号分隔列表} |
| **跳过的阶段** | {SKIP_STAGES 或不在 ACTIVE_STAGES 中的阶段} |
| **人工检查点** | 阶段 {HUMAN_IN_THE_LOOP_PHASES 以逗号分隔} |
| **跳过评委** | {SKIP_JUDGES} |
| **精细化模式** | {REFINE_MODE} |

### 质量门禁摘要

| 阶段 | 评委分数 | 结果 |
|-------|-------------|---------|
| 阶段 2a：研究 | X.X/5.0 | ✅ 通过 / ⚠️ 继续（达到最大迭代） / ⏭️ 跳过 |
| 阶段 2b：代码库分析 | X.X/5.0 | ✅ 通过 / ⚠️ 继续（达到最大迭代） / ⏭️ 跳过 |
| 阶段 2c：业务分析 | X.X/5.0 | ✅ 通过 / ⚠️ 继续（达到最大迭代） / ⏭️ 跳过 |
| 阶段 3：架构综合 | X.X/5.0 | ✅ 通过 / ⚠️ 继续（达到最大迭代） / ⏭️ 跳过 |
| 阶段 4：分解 | X.X/5.0 | ✅ 通过 / ⚠️ 继续（达到最大迭代） / ⏭️ 跳过 |
| 阶段 5：并行化 | X.X/5.0 | ✅ 通过 / ⚠️ 继续（达到最大迭代） / ⏭️ 跳过 |
| 阶段 6：验证 | X.X/5.0 | ✅ 通过 / ⚠️ 继续（达到最大迭代） / ⏭️ 跳过 |

**使用的阈值：** {THRESHOLD}/5.0（如果 SKIP_JUDGES 则为不适用）

**图例：**
- ✅ 通过 - 分数 >= THRESHOLD
- ⚠️ 继续（达到最大迭代） - 分数 < THRESHOLD 但达到 MAX_ITERATIONS，仍继续
- ⏭️ 跳过 - 阶段不在 ACTIVE_STAGES 中

### 生成的成果物

.claude/
└── skills/
└── /
└── SKILL.md # 可重用的技能文档（如果研究阶段运行）

.specs/
├── tasks/
│ ├── draft/ # 草稿任务（源 – 此任务现在为空）
│ ├── todo/
│ │ └── ..md # 完整的任务规范（准备实现）
│ ├── in-progress/ # 正在实现的任务（空）
│ └── done/ # 已完成的任务（空）
├── analysis/
│ └── analysis-.md # 代码库影响分析（如果代码库分析阶段运行）
└── scratchpad/
└── .md # 架构思考草稿本


### 任务状态管理

任务状态由文件夹位置管理：
- `draft/` - 已创建但未精细化的任务
- `todo/` - 准备实现的任务
- `in-progress/` - 当前正在处理的任务
- `done/` - 已完成的任务

### 后续步骤

1. 审阅任务：`.specs/tasks/todo/<filename>`
   - 直接编辑任务文件进行修正
   - 向需要澄清或更改的行添加 `//` 注释
   - 再次运行 `/plan` 并添加 `--refine` 以纳入您的反馈——它会检测相对于 git 的更改并**自上而下**传播更新（编辑一个部分只会影响其下方的部分，不会影响其上方的部分）
2. 如果一切正常，开始实现：`/implement`（将自动从 todo/ 中选择任务）

错误处理

阶段智能体失败（异常/崩溃）

如果任何阶段智能体意外失败：

  1. 报告失败和智能体输出
  2. 向用户提出可以帮助解决问题的澄清性问题
  3. 使用问题和答案列表重新启动阶段智能体以解决问题

评委返回失败

如果任何评委返回失败（分数 < THRESHOLD）：

  1. 自动重试：使用评委反馈重新启动阶段智能体
  2. 人机协同检查：如果阶段在 HUMAN_IN_THE_LOOP_PHASES 中，则在下一次评委重试之前（在实现重试之后、重新评判之前）触发人工检查点
  3. 达到 MAX_ITERATIONS 后：自动进入下一阶段（除非 --human-in-the-loop 包含此阶段，否则不要询问用户）
  4. 在完成摘要中记录警告：⚠️ 阶段 X 在 {MAX_ITERATIONS} 次迭代后未通过质量阈值（X.X/THRESHOLD）

重试流程

实现 → 评委失败 → 实现重试 → 评委重试
                                                          ↓
                              通过 → 继续下一阶段
                              失败 → 重复直到 MAX_ITERATIONS
                                          ↓
                              达到 MAX_ITERATIONS → 进入下一阶段（带警告）

带人机协同的重试流程

当阶段在 HUMAN_IN_THE_LOOP_PHASES 中时：

实现 → 评委失败 → 实现重试
                                    ↓
                    🔍 人工检查点（可选反馈）
                                    ↓
                              评委重试
                                    ↓
                    通过 → 继续 | 失败 → 重复直到 MAX_ITERATIONS
                                                    ↓
                              达到 MAX_ITERATIONS → 🔍 最终人工检查点
                                                    ↓
                                    用户确认 → 进入下一阶段

📄 原始文档

完整文档（英文）：

https://skills.sh/neolabhq/context-engineering-kit/sdd%3Aplan

💡 提示：点击上方链接查看 skills.sh 原始英文文档，方便对照翻译。

声明：本站所有文章，如无特殊说明或标注，均为本站原创发布。任何个人或组织，在未征得本站同意时，禁止复制、盗用、采集、发布本站内容到任何网站、书籍等各类媒体平台。如若本站内容侵犯了原著者的合法权益，可联系我们进行处理。