{/* This page is auto-generated from the skill's SKILL.md by website/scripts/generate-skill-docs.py. Edit the source SKILL.md, not this page. */}

Subagent Driven Development

通过 delegate_task 子 agent 执行计划（两阶段评审）。

Skill 元数据

参考：完整 SKILL.md

Subagent-Driven Development

概览

通过为每个任务派发全新子 agent、并配合系统化两阶段评审，来执行实现计划。

核心原则： 每个任务全新子 agent + 两阶段评审（先规格后质量）= 高质量、快迭代。

使用时机

当以下情况时用本 skill：

• 你有一份实现计划（来自 plan skill 或用户需求）
• 任务大体独立
• 质量和规格符合很重要
• 你想在任务之间自动评审

对比手动执行：

• 每个任务全新上下文（不被累积状态搞混）
• 自动评审流程尽早捕获问题
• 所有任务一致的质量检查
• 子 agent 开工前能提问

流程

1. 读并解析计划

读计划文件。一次性提取所有任务及其完整正文和上下文。创建 todo 列表：

# 读计划
read_file("docs/plans/feature-plan.md")

# 用所有任务创建 todo 列表
todo([
    {"id": "task-1", "content": "Create User model with email field", "status": "pending"},
    {"id": "task-2", "content": "Add password hashing utility", "status": "pending"},
    {"id": "task-3", "content": "Create login endpoint", "status": "pending"},
])

关键： 只读一次计划。提取一切。不要让子 agent 读计划文件——直接在上下文里给完整任务正文。

2. 逐任务工作流

对计划里的每个任务：

第 1 步：派发实现子 agent

用完整上下文调 delegate_task：

delegate_task(
    goal="Implement Task 1: Create User model with email and password_hash fields",
    context="""
    TASK FROM PLAN:
    - Create: src/models/user.py
    - Add User class with email (str) and password_hash (str) fields
    - Use bcrypt for password hashing
    - Include __repr__ for debugging

    FOLLOW TDD:
    1. Write failing test in tests/models/test_user.py
    2. Run: pytest tests/models/test_user.py -v (verify FAIL)
    3. Write minimal implementation
    4. Run: pytest tests/models/test_user.py -v (verify PASS)
    5. Run: pytest tests/ -q (verify no regressions)
    6. Commit: git add -A && git commit -m "feat: add User model with password hashing"

    PROJECT CONTEXT:
    - Python 3.11, Flask app in src/app.py
    - Existing models in src/models/
    - Tests use pytest, run from project root
    - bcrypt already in requirements.txt
    """,
    toolsets=['terminal', 'file']
)

第 2 步：派发规格符合评审者

实现者完成后，对照原始规格验证：

delegate_task(
    goal="Review if implementation matches the spec from the plan",
    context="""
    ORIGINAL TASK SPEC:
    - Create src/models/user.py with User class
    - Fields: email (str), password_hash (str)
    - Use bcrypt for password hashing
    - Include __repr__

    CHECK:
    - [ ] All requirements from spec implemented?
    - [ ] File paths match spec?
    - [ ] Function signatures match spec?
    - [ ] Behavior matches expected?
    - [ ] Nothing extra added (no scope creep)?

    OUTPUT: PASS or list of specific spec gaps to fix.
    """,
    toolsets=['file']
)

如果发现规格问题： 修缺口，然后重跑规格评审。仅在规格符合时继续。

第 3 步：派发代码质量评审者

规格符合通过后：

delegate_task(
    goal="Review code quality for Task 1 implementation",
    context="""
    FILES TO REVIEW:
    - src/models/user.py
    - tests/models/test_user.py

    CHECK:
    - [ ] Follows project conventions and style?
    - [ ] Proper error handling?
    - [ ] Clear variable/function names?
    - [ ] Adequate test coverage?
    - [ ] No obvious bugs or missed edge cases?
    - [ ] No security issues?

    OUTPUT FORMAT:
    - Critical Issues: [must fix before proceeding]
    - Important Issues: [should fix]
    - Minor Issues: [optional]
    - Verdict: APPROVED or REQUEST_CHANGES
    """,
    toolsets=['file']
)

如果发现质量问题： 修问题，重审。仅在批准时继续。

第 4 步：标记完成

todo([{"id": "task-1", "content": "Create User model with email field", "status": "completed"}], merge=True)

3. 最终评审

所有任务完成后，派一个最终集成评审者：

delegate_task(
    goal="Review the entire implementation for consistency and integration issues",
    context="""
    All tasks from the plan are complete. Review the full implementation:
    - Do all components work together?
    - Any inconsistencies between tasks?
    - All tests passing?
    - Ready for merge?
    """,
    toolsets=['terminal', 'file']
)

4. 验证并提交

# 跑完整测试套件
pytest tests/ -q

# 审查所有变更
git diff --stat

# 必要时最终提交
git add -A && git commit -m "feat: complete [feature name] implementation"

任务粒度

每个任务 = 2-5 分钟专注工作。

太大：

• "实现用户认证系统"

合适大小：

• "创建带 email 和 password 字段的 User 模型"
• "加密码哈希函数"
• "创建登录端点"
• "加 JWT token 生成"
• "创建注册端点"

危险信号——绝不要做

• 没有计划就开始实现
• 跳过评审（规格符合或代码质量）
• 带着未修的关键/重要问题继续
• 为触及同一文件的任务派多个实现子 agent
• 让子 agent 读计划文件（改为在上下文里给全文）
• 跳过场景铺垫上下文（子 agent 需要理解任务所处位置）
• 无视子 agent 的问题（让它们继续前先回答）
• 在规格符合上接受"差不多就行"
• 跳过评审循环（评审者发现问题 → 实现者修 → 再评审）
• 让实现者自审替代真正的评审（两者都需要）
• 在规格符合 PASS 之前开始代码质量评审（顺序错了）
• 任一评审还有未决问题就进入下一任务

处理问题

如果子 agent 提问

• 清晰完整地回答
• 必要时提供额外上下文
• 不要催它们开工

如果评审者发现问题

• 实现子 agent（或一个新的）修
• 评审者再评
• 重复直到批准
• 不要跳过重审

如果子 agent 任务失败

• 派一个新的修复子 agent，带具体说明哪里错了
• 不要在控制器会话里手工修（上下文污染）

效率说明

为什么每个任务全新子 agent：

• 防止累积状态造成的上下文污染
• 每个子 agent 拿到干净、聚焦的上下文
• 不被先前任务的代码或推理搞混

为什么两阶段评审：

• 规格评审尽早捕获建少/建多
• 质量评审确保实现造得好
• 在问题跨任务复合之前捕获

成本权衡：

• 更多子 agent 调用（每任务实现者 + 2 个评审者）
• 但尽早捕获问题（比之后调试复合问题便宜）

与其他 skill 集成

与 plan

本 skill 执行由 plan skill 创建的计划：

1. 用户需求 → plan → 实现计划
2. 实现计划 → subagent-driven-development → 可工作代码

与 test-driven-development

实现子 agent 应遵循 TDD：

1. 先写失败测试
2. 实现最小代码
3. 验证测试通过
4. 提交

在每个实现者上下文里包含 TDD 指令。

与 requesting-code-review

两阶段评审流程就是代码评审。最终集成评审用 requesting-code-review skill 的评审维度。

与 systematic-debugging

如果子 agent 在实现中遇到 bug：

1. 遵循 systematic-debugging 流程
2. 修复前找根因
3. 写回归测试
4. 恢复实现

示例工作流

[读计划：docs/plans/auth-feature.md]
[用 5 个任务创建 todo 列表]

--- 任务 1：创建 User 模型 ---
[派实现子 agent]
  实现者："email 要唯一吗？"
  你："要，email 必须唯一"
  实现者：已实现，3/3 测试通过，已提交。

[派规格评审者]
  规格评审者：✅ PASS——所有需求满足

[派质量评审者]
  质量评审者：✅ APPROVED——代码干净，测试好

[标记任务 1 完成]

--- 任务 2：密码哈希 ---
[派实现子 agent]
  实现者：无问题，已实现，5/5 测试通过。

[派规格评审者]
  规格评审者：❌ 缺：密码强度校验（规格说"最少 8 字符"）

[实现者修复]
  实现者：加了校验，7/7 测试通过。

[再派规格评审者]
  规格评审者：✅ PASS

[派质量评审者]
  质量评审者：重要：魔术数字 8，抽成常量
  实现者：抽出 MIN_PASSWORD_LENGTH 常量
  质量评审者：✅ APPROVED

[标记任务 2 完成]

...（继续所有任务）

[所有任务后：派最终集成评审者]
[跑完整测试套件：全通过]
[完成！]

记住

每个任务全新子 agent
每次都两阶段评审
先规格符合
后代码质量
绝不跳过评审
尽早捕获问题

质量不是偶然。它是系统化流程的结果。

延伸阅读（相关时加载）

当编排涉及大量上下文、长评审循环或复杂验证检查点时，为具体纪律加载这些参考：

• references/context-budget-discipline.md——四层上下文退化模型（PEAK / GOOD / DEGRADING / POOR）、随上下文窗口缩放的读深规则、以及静默退化的早期预警信号。当一次运行明显会消耗大量上下文（多阶段计划、多个子 agent、大产物）时加载。
• references/gates-taxonomy.md——四种规范 gate 类型（Pre-flight、Revision、Escalation、Abort）及其行为、恢复和例子。设计或评审任何带验证检查点的工作流时加载——显式使用这套词汇，让每个 gate 有定义好的进入、失败行为和恢复规则。

两份参考均改编自 gsd-build/get-shit-done（MIT © 2025 Lex Christopherson）。