子代理驱动开发 (Subagent Driven Development)

在执行包含独立任务的实施计划时使用。为每个任务分派全新的 delegate_task，并进行两阶段审查（先审查规范符合性，再审查代码质量）。

技能元数据

来源	捆绑包（默认安装）
路径	skills/software-development/subagent-driven-development
版本	1.1.0
作者	Hermes Agent（改编自 obra/superpowers）
许可证	MIT
标签	delegation, subagent, implementation, workflow, parallel
相关技能	writing-plans, requesting-code-review, test-driven-development

参考：完整 SKILL.md

信息

以下是 Hermes 在触发此技能时加载的完整技能定义。这是技能激活时代理看到的指令。

子代理驱动开发

概述

通过为每个任务分派全新的子代理并进行系统的两阶段审查来执行实施计划。

核心原则： 每个任务使用全新的子代理 + 两阶段审查（先规范后质量）= 高质量、快速迭代。

何时使用

在以下情况使用此技能：

• 你有一个实施计划（来自 writing-plans 技能或用户需求）
• 任务大部分是独立的
• 质量和规范符合性很重要
• 你希望在任务之间进行自动化审查

与手动执行相比：

• 每个任务拥有全新的上下文（避免因状态累积造成的混淆）
• 自动化审查流程能尽早发现问题
• 所有任务具有一致的质量检查
• 子代理可以在开始工作前提问

流程

1. 阅读并解析计划

阅读计划文件。预先提取所有任务及其完整文本和上下文。创建一个待办事项列表：

# Read the plan
read_file("docs/plans/feature-plan.md")

# Create todo list with all tasks
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"},
])

关键： 仅阅读计划一次。提取所有内容。不要让子代理去读取计划文件——直接在上下文中提供完整的任务文本。

2. 单任务工作流

对于计划中的每一个任务：

步骤 1：分派实现者子代理

使用 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. 验证并提交

# Run full test suite
pytest tests/ -q

# Review all changes
git diff --stat

# Final commit if needed
git add -A && git commit -m "feat: complete [feature name] implementation"

任务粒度

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

过大：

• “实现用户认证系统”

合适的大小：

• “创建包含电子邮件和密码字段的 User 模型”
• “添加密码哈希函数”
• “创建登录端点”
• “添加 JWT 令牌生成”
• “创建注册端点”

危险信号 — 切勿执行以下操作

• 在没有计划的情况下开始实施
• 跳过审查（规范符合性或代码质量）
• 带着未修复的关键/重要问题继续推进
• 为涉及相同文件的任务分派多个实现子代理
• 让子代理读取计划文件（改为在上下文中提供完整文本）
• 跳过场景设置上下文（子代理需要理解任务所处的位置）
• 忽略子代理的问题（在让他们继续之前先回答）
• 接受规范符合性上的“差不多”
• 跳过审查循环（审查者发现问题 → 实现者修复 → 再次审查）
• 让实现者自我审查取代实际审查（两者都需要）
• 在规范符合性通过之前开始代码质量审查（顺序错误）
• 在任何一方审查存在未决问题时进入下一个任务

处理问题

如果子代理提问

• 清晰且完整地回答
• 如有必要，提供额外的上下文
• 不要催促他们立即进入实施阶段

如果审查者发现问题

• 由实现者子代理（或新的子代理）修复这些问题
• 审查者再次审查
• 重复直到获得批准
• 不要跳过重新审查

如果子代理未能完成任务

• 分派一个新的修复子代理，并提供关于出错具体内容的明确指令
• 不要在控制器会话中尝试手动修复（会造成上下文污染）

效率说明

为什么每个任务使用全新的子代理：

• 防止因状态累积造成的上下文污染
• 每个子代理获得干净、专注的上下文
• 避免因先前任务的代码或推理产生混淆

为什么采用两阶段审查：

• 规范审查能尽早发现构建不足或过度构建的问题
• 质量审查确保实施构建良好
• 在问题跨任务累积之前将其捕获

成本权衡：

• 更多的子代理调用（每个任务包含 1 个实现者 + 2 个审查者）
• 但能尽早发现问题（比后期调试累积的问题更便宜）

与其他技能的集成

与 writing-plans 集成

此技能执行由 writing-plans 技能创建的计划：

1. 用户需求 → writing-plans → 实施计划
2. 实施计划 → subagent-driven-development → 可工作的代码

与 test-driven-development 集成

实现者子代理应遵循 TDD（测试驱动开发）：

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

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

与 requesting-code-review 集成

两阶段审查过程就是代码审查。对于最终集成审查，请使用 requesting-code-review 技能的审查维度。

与 systematic-debugging 集成

如果子代理在实施过程中遇到错误：

1. 遵循 systematic-debugging 流程
2. 在修复之前找到根本原因
3. 编写回归测试
4. 恢复实施

示例工作流

[Read plan: docs/plans/auth-feature.md]
[Create todo list with 5 tasks]

--- Task 1: Create User model ---
[Dispatch implementer subagent]
  Implementer: "Should email be unique?"
  You: "Yes, email must be unique"
  Implementer: Implemented, 3/3 tests passing, committed.

[Dispatch spec reviewer]
  Spec reviewer: ✅ PASS — all requirements met

[Dispatch quality reviewer]
  Quality reviewer: ✅ APPROVED — clean code, good tests

[Mark Task 1 complete]

--- Task 2: Password hashing ---
[Dispatch implementer subagent]
  Implementer: No questions, implemented, 5/5 tests passing.

[Dispatch spec reviewer]
  Spec reviewer: ❌ Missing: password strength validation (spec says "min 8 chars")

[Implementer fixes]
  Implementer: Added validation, 7/7 tests passing.

[Dispatch spec reviewer again]
  Spec reviewer: ✅ PASS

[Dispatch quality reviewer]
  Quality reviewer: Important: Magic number 8, extract to constant
  Implementer: Extracted MIN_PASSWORD_LENGTH constant
  Quality reviewer: ✅ APPROVED

[Mark Task 2 complete]

... (continue for all tasks)

[After all tasks: dispatch final integration reviewer]
[Run full test suite: all passing]
[Done!]

记住

Fresh subagent per task
Two-stage review every time
Spec compliance FIRST
Code quality SECOND
Never skip reviews
Catch issues early

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