subagent-driven-development

サブエージェント主導の開発

task ツールを使ってタスクごとに新しいサブエージェントを割り当て、計画を実行します。まず仕様適合性レビューを行い、次にコード品質レビューを行います。さらに、タスクがセキュリティ関連のコードに関わる場合は、ブロッキングセキュリティレビューを行います。

サブエージェントを使う理由： 専門エージェントにタスクを委任し、それぞれのコンテキストを分離できます。指示とコンテキストを正確に組み立てることで、エージェントが集中してタスクを完了できるようにします。エージェントにセッションのコンテキストや履歴を引き継がせてはいけません。必要な情報だけをこちらで用意します。これにより、調整作業に使う自分のコンテキストも維持できます。

基本原則： タスクごとに新しいサブエージェントを割り当て、仕様レビュー、品質レビューの順に行い、タスクがセキュリティ関連のコードに関わる場合はセキュリティレビューも行うことで、高品質かつ迅速な反復を実現します。

使用するタイミング

digraph when_to_use {
    "Have implementation plan?" [shape=diamond];
    "Tasks mostly independent?" [shape=diamond];
    "Stay in this session?" [shape=diamond];
    "subagent-driven-development" [shape=box];
    "executing-plans" [shape=box];
    "Manual execution or brainstorm first" [shape=box];

    "Have implementation plan?" -> "Tasks mostly independent?" [label="yes"];
    "Have implementation plan?" -> "Manual execution or brainstorm first" [label="no"];
    "Tasks mostly independent?" -> "Stay in this session?" [label="yes"];
    "Tasks mostly independent?" -> "Manual execution or brainstorm first" [label="no - tightly coupled"];
    "Stay in this session?" -> "subagent-driven-development" [label="yes"];
    "Stay in this session?" -> "executing-plans" [label="no - parallel session"];
}

「計画の実行」との比較（並列セッション）：

• 同じセッション内で実行（コンテキストの切り替えなし）
• タスクごとに新しいサブエージェントを割り当て（コンテキストの混在なし）
• 各タスクの後にレビューを実施：まず仕様適合性、次にコード品質、タスクがセキュリティ関連のコードに関わる場合はセキュリティも確認
• タスク間で人間が介在しないため、反復が高速

プロセス

digraph process {
    rankdir=TB;

    subgraph cluster_per_task {
        label="Per Task";
        "Dispatch implementer sub-agent (@implementer)" [shape=box];
        "Implementer sub-agent asks questions?" [shape=diamond];
        "Answer questions, provide context" [shape=box];
        "Implementer sub-agent implements, tests, commits, self-reviews" [shape=box];
        "Dispatch spec reviewer sub-agent (@spec-reviewer)" [shape=box];
        "Spec reviewer sub-agent confirms code matches spec?" [shape=diamond];
        "Implementer sub-agent fixes spec gaps" [shape=box];
        "Dispatch code quality reviewer sub-agent (@code-quality-reviewer)" [shape=box];
        "Code quality reviewer sub-agent approves?" [shape=diamond];
        "Implementer sub-agent fixes quality issues" [shape=box];
        "Task touches security-relevant code?" [shape=diamond];
        "Dispatch security reviewer sub-agent (@security-reviewer)" [shape=box];
        "Security reviewer sub-agent: no Critical or High open?" [shape=diamond];
        "Implementer sub-agent fixes security findings" [shape=box];
        "Mark task complete in `todowrite`" [shape=box];
    }

    "Read plan, extract all tasks with full text, note context, create `todowrite` list" [shape=box];
    "More tasks remain?" [shape=diamond];
    "Dispatch final code reviewer sub-agent for entire implementation" [shape=box];
    "Use finishing-a-development-branch" [shape=box style=filled fillcolor=lightgreen];

    "Read plan, extract all tasks with full text, note context, create `todowrite` list" -> "Dispatch implementer sub-agent (@implementer)";
    "Dispatch implementer sub-agent (@implementer)" -> "Implementer sub-agent asks questions?";
    "Implementer sub-agent asks questions?" -> "Answer questions, provide context" [label="yes"];
    "Answer questions, provide context" -> "Dispatch implementer sub-agent (@implementer)";
    "Implementer sub-agent asks questions?" -> "Implementer sub-agent implements, tests, commits, self-reviews" [label="no"];
    "Implementer sub-agent implements, tests, commits, self-reviews" -> "Dispatch spec reviewer sub-agent (@spec-reviewer)";
    "Dispatch spec reviewer sub-agent (@spec-reviewer)" -> "Spec reviewer sub-agent confirms code matches spec?";
    "Spec reviewer sub-agent confirms code matches spec?" -> "Implementer sub-agent fixes spec gaps" [label="no"];
    "Implementer sub-agent fixes spec gaps" -> "Dispatch spec reviewer sub-agent (@spec-reviewer)" [label="re-review"];
    "Spec reviewer sub-agent confirms code matches spec?" -> "Dispatch code quality reviewer sub-agent (@code-quality-reviewer)" [label="yes"];
    "Dispatch code quality reviewer sub-agent (@code-quality-reviewer)" -> "Code quality reviewer sub-agent approves?";
    "Code quality reviewer sub-agent approves?" -> "Implementer sub-agent fixes quality issues" [label="no"];
    "Implementer sub-agent fixes quality issues" -> "Dispatch code quality reviewer sub-agent (@code-quality-reviewer)" [label="re-review"];
    "Code quality reviewer sub-agent approves?" -> "Task touches security-relevant code?" [label="yes"];
    "Task touches security-relevant code?" -> "Dispatch security reviewer sub-agent (@security-reviewer)" [label="yes"];
    "Task touches security-relevant code?" -> "Mark task complete in `todowrite`" [label="no"];
    "Dispatch security reviewer sub-agent (@security-reviewer)" -> "Security reviewer sub-agent: no Critical or High open?";
    "Security reviewer sub-agent: no Critical or High open?" -> "Implementer sub-agent fixes security findings" [label="no"];
    "Implementer sub-agent fixes security findings" -> "Dispatch security reviewer sub-agent (@security-reviewer)" [label="re-review"];
    "Security reviewer sub-agent: no Critical or High open?" -> "Mark task complete in `todowrite`" [label="yes"];
    "Mark task complete in `todowrite`" -> "More tasks remain?";
    "More tasks remain?" -> "Dispatch implementer sub-agent (@implementer)" [label="yes"];
    "More tasks remain?" -> "Dispatch final code reviewer sub-agent for entire implementation" [label="no"];
    "Dispatch final code reviewer sub-agent for entire implementation" -> "Use finishing-a-development-branch";
}

モデルの選択

コストを抑え、速度を高めるため、各役割をこなせる範囲で最も能力の低いモデルを使用します。

機械的な実装タスク（独立した関数、明確な仕様、1～2 個のファイル）：高速で低コストなモデルを使用します。計画が十分に具体的であれば、ほとんどの実装タスクは機械的に処理できます。

統合と判断を要するタスク（複数ファイルの調整、パターン照合、デバッグ）：標準的なモデルを使用します。

アーキテクチャ、設計、レビューのタスク： 利用可能な中で最も高性能なモデルを使用します。

タスクの複雑さを示す目安：

• 完全な仕様があり、変更するファイルが 1～2 個 → 低コストモデル
• 統合上の懸念があり、複数のファイルを変更する → 標準モデル
• 設計上の判断や、コードベース全体にわたる理解が必要 → 最も高性能なモデル

実装担当エージェントのステータスへの対応

実装担当のサブエージェントは、次の 4 つのステータスのいずれかを報告します。それぞれ適切に対応してください。

DONE： 仕様適合性レビューに進みます。

DONE_WITH_CONCERNS： 実装担当エージェントは作業を完了しましたが、懸念事項も報告しています。先に進む前にその内容を確認してください。正確性や範囲に関する懸念であれば、レビューの前に解決します。「このファイルは大きくなっている」などの所見であれば、記録したうえでレビューに進みます。

NEEDS_CONTEXT： 実装担当エージェントが、提供されていない情報を必要としています。不足しているコンテキストを提供し、再度割り当てます。

BLOCKED： 実装担当エージェントがタスクを完了できません。阻害要因を評価します。

1. コンテキストの問題であれば、必要な情報を追加し、同じモデルで再度割り当てます。
2. より深い推論が必要なタスクであれば、より高性能なモデルで再度割り当てます。
3. タスクの規模が大きすぎる場合は、より小さな単位に分割します。
4. 計画自体に誤りがある場合は、人間にエスカレーションします。

エスカレーションを決して無視したり、変更を加えずに同じモデルへ再試行させたりしてはいけません。実装担当エージェントが行き詰まったと報告した場合は、何かを変更する必要があります。

エージェントの参照先

• implementer（グローバルエージェント）- 実装担当のサブエージェントを割り当てます
• spec-reviewer（グローバルエージェント）- 仕様適合性レビュー担当のサブエージェントを割り当てます
• code-quality-reviewer（グローバルエージェント）- コード品質レビュー担当のサブエージェントを割り当てます
• security-reviewer（グローバルエージェント）- タスクがセキュリティ関連のコードに関わる場合、セキュリティレビュー担当のサブエージェントを割り当てます

ワークフローの例

You: I'm using Subagent-Driven Development to execute this plan.

[Read plan file once: docs/plans/feature-plan.md]
[Extract all 5 tasks with full text and context]
[Create `todowrite` list with all tasks]

Task 1: Hook installation script

[Get Task 1 text and context (already extracted)]
[Dispatch implementation sub-agent using the `task` tool with full task text + context]

Implementer: "Before I begin - should the hook be installed at user or system level?"

You: "User level (~/.config/opencode/hooks/)"

Implementer: "Got it. Implementing now..."
[Later] Implementer:
  - Implemented install-hook command
  - Added tests, 5/5 passing
  - Self-review: Found I missed --force flag, added it
  - Committed

[Dispatch spec compliance reviewer]
Spec reviewer: APPROVED - Spec compliant - all requirements met, nothing extra

[Get git SHAs, dispatch code quality reviewer]
Code reviewer: Strengths: Good test coverage, clean. Issues: None. Approved.

[Mark Task 1 complete]

Task 2: Recovery modes

[Get Task 2 text and context (already extracted)]
[Dispatch implementation sub-agent using the `task` tool with full task text + context]

Implementer: [No questions, proceeds]
Implementer:
  - Added verify/repair modes
  - 8/8 tests passing
  - Self-review: All good
  - Committed

[Dispatch spec compliance reviewer]
Spec reviewer: ISSUES:
  - Missing: Progress reporting (spec says "report every 100 items")
  - Extra: Added --json flag (not requested)

[Implementer fixes issues]
Implementer: Removed --json flag, added progress reporting

[Spec reviewer reviews again]
Spec reviewer: APPROVED - Spec compliant now

[Dispatch code quality reviewer]
Code reviewer: Strengths: Solid. Issues (Important): Magic number (100)

[Implementer fixes]
Implementer: Extracted PROGRESS_INTERVAL constant

[Code reviewer reviews again]
Code reviewer: APPROVED

[Mark Task 2 complete]

Task 3: Token signing key (touches security-relevant code)

[Spec APPROVED, quality APPROVED]

[Dispatch security reviewer]
Security reviewer: Critical open — signing key from env, no check it is
non-empty (fails open to unsigned tokens). Path traced, fix named.

[Implementer fixes, security reviewer re-reviews]
Security reviewer: APPROVED - no Critical or High open

[Mark Task 3 complete]

...

[After all tasks]
[Dispatch final code-reviewer]
Final reviewer: All requirements met, ready to merge

Done!

利点

手動実行との比較：

• サブエージェントは自然に TDD に従います
• タスクごとに新しいコンテキストを使用します（混乱しません）
• 並列実行に対応します（サブエージェント同士が干渉しません）
• サブエージェントは作業の前でも途中でも質問できます

計画の実行との比較：

• 同じセッション内で実行します（引き継ぎがありません）
• 継続的に進行します（待ち時間がありません）
• レビューチェックポイントを自動で設けます

効率の向上：

• ファイルを読むオーバーヘッドがありません（コントローラーが全文を提供します）
• コントローラーが必要なコンテキストを正確に選定します
• サブエージェントは最初から完全な情報を受け取ります
• 作業開始前に質問が明らかになります（作業後ではありません）

品質ゲート：

• セルフレビューで引き継ぎ前に問題を見つけます
• レビューでは、まず仕様への準拠、次にコード品質を確認し、セキュリティに関わるタスクではその後にセキュリティを確認します
• レビューループにより、修正が実際に機能することを確認します
• 仕様への準拠により、過剰な実装や実装不足を防ぎます
• コード品質により、適切に構築された実装を確保します
• セキュリティレビューでは、リリース前に攻撃者の経路をたどって確認します

コスト：

• サブエージェントの呼び出し回数が増えます（タスクごとに実装担当者＋レビュー担当者 2 名、セキュリティに関わるタスクではセキュリティレビュー担当者も追加）
• コントローラーの準備作業が増えます（すべてのタスクを事前に抽出します）
• レビューループによって反復が増えます
• ただし、問題を早期に発見できます（後からデバッグするより低コストです）

危険信号

決して行わないこと：

• ユーザーの明示的な同意なしに、main/master ブランチで実装を開始する
• レビューを省略する（仕様への準拠とコード品質の両方が必須です。タスクがセキュリティに関わるコードに触れる場合は、セキュリティレビューも必須です）
• 未修正の問題がある状態で先に進む
• 信頼できない入力、認証／認可、シークレット、インジェクションの受け口、サブプロセス／プラグインの境界、新しい依存関係に関わるタスクで、セキュリティレビュー担当者を省略する（トリガーについては reviewing-security を参照）
• 複数の実装サブエージェントを並列にディスパッチする（競合します）
• サブエージェントに計画ファイルを読ませる（代わりに全文を提供する）
• 背景の説明を省略する（サブエージェントはタスクの位置づけを理解する必要があります）
• サブエージェントからの質問を無視する（先に進ませる前に回答する）
• 仕様への準拠が「ほぼ十分」な状態を受け入れる（仕様レビュー担当者が問題を見つけた場合、完了ではありません）
• レビューループを省略する（レビュー担当者が問題を見つけたら、実装担当者が修正し、再度レビューします）
• 実装担当者のセルフレビューを正式なレビューの代わりにする（どちらも必要です）
• 仕様への準拠が確認される前に、コード品質レビューを開始する（順序が誤っています）
• 仕様への準拠とコード品質が確認される前に、セキュリティレビューを開始する（順序が誤っています）
• いずれかのレビューに未解決の問題がある状態で次のタスクに進む

サブエージェントから質問があった場合：

• 明確かつ十分に回答する
• 必要に応じて追加のコンテキストを提供する
• 急かして実装に進ませない

レビュー担当者が問題を見つけた場合：

• 実装担当者（同じサブエージェント）が修正します
• レビュー担当者が再レビューします
• 承認されるまで繰り返します
• 再レビューを省略しないでください

サブエージェントがタスクに失敗した場合：

• 具体的な指示を添えて修正担当のサブエージェントをディスパッチする
• 手動で修正しようとしない（コンテキストが汚染されます）

統合

必須のワークフロースキル：

• using-git-worktrees - 必須：開始前に隔離されたワークスペースを設定します
• writing-plans - このスキルが実行する計画を作成します
• requesting-code-review - レビュー担当サブエージェント向けのコードレビューワークフロー
• code-quality-reviewer - コード品質レビュー用のグローバルエージェント
• security-reviewer - セキュリティに関わるタスクのセキュリティレビュー用グローバルエージェント
• finishing-a-development-branch - すべてのタスク完了後に開発を完了します

サブエージェントが使用するスキル：

• test-driven-development - サブエージェントは各タスクで TDD に従います

代替ワークフロー：

• executing-plans - 同じセッション内での実行の代わりに、並列セッションで使用します