子代理驅動開發 (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

質量不是偶然，而是系統化流程的結果。