--- name: subagent-driven-development description: 在当前会话中执行有独立任务的实现计划时使用 --- # 子代理驱动开发 通过为每个任务派发新的子代理来执行计划,每个任务完成后进行两阶段审查:先规格符合性审查,再代码质量审查。 **核心原则:** 每个任务新子代理 + 两阶段审查(规格然后质量)= 高质量,快速迭代 ## 何时使用 ``` 有实现计划? ↓ 是 任务大多独立? ↓ 是 → 子代理驱动开发 否则 → 手动执行或先头脑风暴 ``` **优势:** - 同一会话(无上下文切换) - 每个任务新子代理(无上下文污染) - 每个任务后两阶段审查:先规格符合性,再代码质量 - 快速迭代(任务之间无人工等待) ## 流程 ``` 读取计划,使用 Task 系统创建任务 ↓ 每个业务 Task: ├── 派发 Implementer 子代理 │ ├── 阅读任务需求 │ ├── 遵循 TDD │ ├── 实现功能 │ ├── Git commit │ └── 更新 Task metadata │ ├── 派发 Spec Reviewer 子代理 │ ├── 独立阅读代码 │ ├── 逐条验证需求 │ └── 检查遗漏或多余功能 │ ↓ 问题? → Implementer 修复 → 重新审查 │ ├── 派发 Code Quality Reviewer 子代理 │ ├── 审查代码质量 │ └── 分类问题:关键/重要/次要 │ ↓ 问题? → Implementer 修复 → 重新审查 │ └── 主窗口:TaskUpdate status=completed ↓ 还有更多任务? ↓ 是 → 下一个 Task ↓ 否 → 校验 Task 执行 ``` ## 子代理派发模板 ### Implementer 子代理 ``` Task tool (general-purpose): description: "实现 Task N: {Task标题}" prompt: | 你正在实现一个具体的开发任务。 ## 任务信息 {Task JSON 的完整 description 内容} ## Task metadata 更新规范(必须遵守) 在执行过程中,你必须持续通过 TaskUpdate 更新 metadata: 1. 开始任务时: TaskUpdate taskId={id} metadata={"started_at": "{当前时间}"} 2. 每次修改文件后: TaskUpdate taskId={id} metadata={"files_modified": ["file1.py", "file2.py"]} 3. 遇到错误时(必须记录,包含解决方案): TaskUpdate taskId={id} metadata={"errors_encountered": ["错误描述 - 解决方案"]} ⚠️ 如果你无法解决某个问题而选择跳过或简化,必须如实记录 4. 运行测试后: TaskUpdate taskId={id} metadata={"test_results": "5/5 passed"} 5. 提交代码后: TaskUpdate taskId={id} metadata={"git_commit": "{hash}", "commit_message": "{msg}"} ## 执行要求 - 遵循 TDD:先写测试,再实现 - 每个有意义的变更都要提交 - 自审:完成后检查实现是否完整 - 如实记录:不要隐瞒错误或跳过的内容 ``` ### Spec Reviewer 子代理 ``` Task tool (general-purpose): description: "审查 Task N 的规格符合性" prompt: | 你正在审查一个实现是否符合其规格。 ## 被请求的内容 {Task JSON 的完整 description 内容} ## 实现者声称构建的内容 {Implementer 子代理的返回报告} ## 关键:不要信任报告 实现者的报告可能不完整、不准确或过于乐观。你必须独立验证。 **要:** 阅读实际代码,逐行比较,检查声称但未实现的部分 **不要:** 相信报告,信任完整性声明 ## 输出格式 - ✅ 符合规格 - ❌ 发现问题:[具体列出,带 file:line 引用] ``` ### Code Quality Reviewer 子代理 ``` Task tool (general-purpose): description: "审查 Task N 的代码质量" prompt: | 你正在审查代码更改的生产就绪性。 ## 实现内容 {Implementer 报告} ## 需求/计划 {Task description} ## 审查清单 - 代码质量:关注点分离、错误处理、类型安全、DRY - 架构:设计决策、可扩展性、性能、安全 - 测试:测试真实逻辑、边界覆盖、集成测试 - 生产就绪:向后兼容、文档、无明显bug ## 输出格式 ### 优点 [具体说明做得好的地方] ### 问题 - 关键(必须修复):[Bug、安全问题] - 重要(应该修复):[架构问题、测试缺口] - 次要(可以改进):[代码风格] ### 评估 可以合并?[是/否/修复后可以] ``` ## 示例工作流 ``` 你: 我正在使用子代理驱动开发执行此计划。 [调用 TaskList 获取所有任务] [找到第一个 pending Task] Task 1: Hook 安装脚本 [派发 Implementer 子代理,包含完整任务 description] Implementer: "开始之前 - hook 应该安装在用户级还是系统级?" 你: "用户级 (~/.config/vibe/hooks/)" Implementer: "好的。现在开始实现..." [稍后] Implementer: - 实现了 install-hook 命令 - 添加了测试,5/5 通过 - 自审:发现遗漏了 --force 标志,已添加 - 已提交 - metadata 已更新 [派发 Spec Reviewer] Spec Reviewer: ✅ 符合规格 - 所有需求满足 [派发 Code Quality Reviewer] Code Reviewer: 优点:测试覆盖好。问题:无。通过。 [TaskUpdate taskId=1 status=completed] Task 2: 恢复模式 [派发 Implementer 子代理] Implementer: - 添加了 verify/repair 模式 - 8/8 测试通过 - 已提交 [派发 Spec Reviewer] Spec Reviewer: ❌ 问题: - 遗漏:进度报告(规格说"每 100 项报告一次") - 多余:添加了 --json 标志(未请求) [Implementer 修复问题] Implementer: 移除了 --json 标志,添加了进度报告 [Spec Reviewer 再次审查] Spec Reviewer: ✅ 现在符合规格 [派发 Code Quality Reviewer] Code Reviewer: 问题(重要):魔法数字(100) [Implementer 修复] Implementer: 提取了 PROGRESS_INTERVAL 常量 [Code Reviewer 再次审查] Code Reviewer: ✅ 通过 [TaskUpdate taskId=2 status=completed] ... [所有业务 Task 完成后] [校验 Task 自动执行] [验证 design.md + metadata → 生成快照 → 标记完成] ``` ## 危险信号 **永远不要:** - 跳过审查(规格符合性或代码质量) - 带着未修复的问题继续 - 并行派发多个实现子代理(冲突) - 让子代理读取计划文件(提供完整 description 代替) - 跳过 metadata 更新(校验 Task 需要这些信息) - 忽略子代理问题(在让他们继续之前回答) - 接受规格符合性的"差不多"(审查者发现问题 = 未完成) - **在规格符合性 ✅ 之前开始代码质量审查**(顺序错误) - 在任一审查有未解决问题时进入下一个任务 **如果子代理提问:** - 清晰完整地回答 - 如需要提供额外上下文 - 不要催他们进入实现 **如果审查者发现问题:** - Implementer(同一子代理)修复 - 审查者再次审查 - 重复直到通过 - 不要跳过重新审查 **如果子代理任务失败:** - 派发修复子代理,带具体指示 - 不要手动修复(上下文污染) ## 集成 **必需的工作流 skills:** - **brainstorming** - 创建设计文档(design.md) - **writing-plans** - 创建此 skill 执行的计划(plan.md) **子代理应使用:** - **test-driven-development** - 子代理为每个任务遵循 TDD