VibeEngineering/.claude/skills/subagent-driven-development/SKILL.md

name, description

name	description
subagent-driven-development	在当前会话中执行有独立任务的实现计划时使用

子代理驱动开发

通过为每个任务派发新的子代理来执行计划，每个任务完成后进行两阶段审查：先规格符合性审查，再代码质量审查。

核心原则： 每个任务新子代理 + 两阶段审查（规格然后质量）= 高质量，快速迭代

何时使用

有实现计划?
    ↓ 是
任务大多独立?
    ↓ 是
→ 子代理驱动开发

否则 → 手动执行或先头脑风暴

优势：

• 同一会话（无上下文切换）
• 每个任务新子代理（无上下文污染）
• 每个任务后两阶段审查：先规格符合性，再代码质量
• 快速迭代（任务之间无人工等待）

流程

读取计划，使用 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