| name | subagent-driven-development |
| description | 由 smart-exec-plan 调用——为每个 Task 分派独立实现者并执行规格、质量、Stage 和最终审查 |
子代理驱动开发
每个 Task 使用全新实现者子代理，并依次经过规格审查和代码质量审查。所有 Task 完成后执行 Stage 审查；最后一个 Stage 合并前执行全需求审查。
开始时声明： “我正在使用 subagent-driven-development 技能实现并审查计划中的 Task。”
职责边界
本技能负责：
- 分派 Task 实现者
- 处理实现者问题和状态
- 规格审查
- 代码质量审查
- Stage 审查
- 全需求最终审查
本技能不负责：
- 创建或切换 Git 分支
- 提交、amend 或合并
- 更新计划和 brainstorming 进度
- 决定 Stage 顺序
这些 Git 和进度操作由 smart-exec-plan 统一控制。
核心规则
- 每个 Task 使用全新实现者上下文。
- 实现者不得自行读取整个计划，控制器提供完整 Task 文本。
- 实现者遵循 test-driven-development。
- 实现者不执行 Git 提交和分支操作。
- 先规格审查，后代码质量审查。
- 任一审查发现问题，都由原实现者修复并重新审查。
- Task 之间不暂停询问用户。
- 不并行分派会修改同一工作区的实现者。
- 不为中间服务可用性添加兼容代码。
单 Task 流程
digraph task_flow {
"记录 Task BASE_SHA" [shape=box];
"分派实现者" [shape=box];
"实现者需要上下文？" [shape=diamond];
"补充上下文并继续" [shape=box];
"实现者按 TDD 修改并自审" [shape=box];
"规格审查" [shape=box];
"规格通过？" [shape=diamond];
"原实现者修复规格问题" [shape=box];
"代码质量审查" [shape=box];
"质量通过？" [shape=diamond];
"原实现者修复质量问题" [shape=box];
"返回 Task 已批准" [shape=doublecircle];
"记录 Task BASE_SHA" -> "分派实现者";
"分派实现者" -> "实现者需要上下文？";
"实现者需要上下文？" -> "补充上下文并继续" [label="是"];
"补充上下文并继续" -> "实现者按 TDD 修改并自审";
"实现者需要上下文？" -> "实现者按 TDD 修改并自审" [label="否"];
"实现者按 TDD 修改并自审" -> "规格审查";
"规格审查" -> "规格通过？";
"规格通过？" -> "原实现者修复规格问题" [label="否"];
"原实现者修复规格问题" -> "规格审查";
"规格通过？" -> "代码质量审查" [label="是"];
"代码质量审查" -> "质量通过？";
"质量通过？" -> "原实现者修复质量问题" [label="否"];
"原实现者修复质量问题" -> "代码质量审查";
"质量通过？" -> "返回 Task 已批准" [label="是"];
}
分派实现者
使用 implementer-prompt.md，提供：
- Task 完整正文
- 当前 Stage 在完整需求中的位置
- 相关设计章节
- CONTEXT 内容
- 依赖 Task 已产生的公共接口
- 工作目录
- 当前 Task 的允许文件范围
不让实现者自行查找计划范围。实现者可以读取完成 Task 所需的代码和调用方。
实现者状态
DONE
实现和自审完成，进入规格审查。
DONE_WITH_CONCERNS
先检查顾虑：
- 正确性、范围或数据安全顾虑必须先处理。
- 明确属于后续 Task 的集成状态不阻止当前 Task 审查。
- 单纯缺少中间兼容层不是顾虑。
NEEDS_CONTEXT
提供缺失的设计、代码或依赖信息后恢复同一实现者。
BLOCKED
判断原因：
- 上下文不足：补充上下文。
- 推理能力不足：使用更强模型。
- Task 过大：依据既有设计拆成修复 Task，不新增设计。
- 计划缺口：停止并交回 writing-plans。
- 设计缺口：停止并交回 grill-with-docs。
不得在没有变化的情况下重复分派。
规格审查
使用 spec-reviewer-prompt.md。审查当前工作区相对 Task BASE_SHA 的实际变更。
规格审查验证：
- 当前 Task 要求是否全部实现
- 是否有计划外功能
- 是否误解最终设计
- 是否添加纯开发过渡兼容代码
- 当前 Task 遗留内容是否确实属于后续已定义 Task
当前 Task 无法独立部署或服务无法启动不是规格问题。
代码质量审查
规格审查通过后使用 code-quality-reviewer-prompt.md。
审查者读取：
git status --short- 相对 Task BASE_SHA 的完整差异
- 新增未跟踪文件
- 当前 Task 测试结果
审查通过前不得返回 Task 已批准。
Stage 审查
当前 Stage 所有 Task 已提交后，使用 stage-reviewer-prompt.md。
Stage 审查只验证：
- Stage 设计覆盖
- Task 间接口和数据结构一致性
- 是否遗漏本 Stage 职责
- 是否引入计划外兼容机制
- 是否为后续 Stage 提供约定产物
不要求 Stage 可部署、服务可启动或完整测试通过。
Stage 审查返回 NEEDS_CHANGES 时：
- 在当前 Stage 计划中追加有明确范围的修复 Task。
- 修复 Task 进入完整的实现者、规格审查和质量审查循环。
- smart-exec-plan 将计划更新和修复代码提交为同一个 commit。
- 重新执行 Stage 审查。
最终审查
最后一个 Stage 的 Task 和 Stage 审查完成后，使用 final-reviewer-prompt.md。
最终审查要求：
- 全部成功标准满足
- 跨 Stage 集成正确
- 最终架构与设计一致
- 旧实现和临时代码已清除
- 完整验证通过
- 服务达到最终可用状态
最终审查发现问题时追加修复 Task，执行完整单 Task 审查后重新进行 Stage 和最终审查。
SHA 规则
- 每个 Task 开始前记录当前 HEAD，作为 Task BASE_SHA。
- 规格和质量审查针对 BASE_SHA 与当前工作区的差异。
- 每个 Stage 开始前记录 HEAD，作为 STAGE_BASE_SHA。
- 初始文档提交后记录 IMPLEMENTATION_BASE_SHA。
- 最终审查范围为 IMPLEMENTATION_BASE_SHA 到开发分支最终 HEAD。
模型选择
- 清晰且仅涉及少量文件的 Task：快速模型。
- 多文件集成和调试 Task：标准模型。
- 设计判断、Stage 审查和最终审查：可用的最强模型。
运行环境不支持模型切换时使用默认模型。
红线
不得：
- 让实现者提交或切换分支
- 跳过规格或质量审查
- 在规格审查前进行质量审查
- 用实现者自审替代独立审查
- 带着未修复问题进入下一 Task
- 并行修改共享工作区
- 信任实现者报告而不读实际文件
- 因缺少中间兼容层而要求额外实现
- 在最终完整验证失败时批准合并
