subagent-driven-development

実行

→ 独立したタスクを含む実装計画がありますか？ → タスクごとに新しいサブエージェントを割り当て、2段階でレビューします。

1. 計画を読み、すべてのタスクを抽出して TodoWrite を作成します
2. タスクごとに、実装担当者を割り当て → 質問に回答 → 実装担当者が完了
3. 第1段階のレビュー（仕様への準拠）→ 不足箇所を修正 → ✅ になるまで再レビュー
4. 第2段階のレビュー（コード品質）→ 問題を修正 → ✅ になるまで再レビュー
5. コーディネーターが検証し、まとまりのあるタスクをコミットして、チェックポイント／乖離状況を更新 → 次のタスクへ → すべてのタスクが完了したら、最終レビュー → 検証結果を記録。必要な場合にのみブランチを終了します。

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

タスクごとに新しいサブエージェントを割り当てて計画を実行し、各タスクの後に2段階のレビューを行います。まず仕様への準拠を確認し、次にコード品質を確認します。

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

基本原則： タスクごとに新しいサブエージェントを割り当て、仕様、次に品質の順に2段階でレビューすることで、高品質かつ迅速な反復を実現します。

使用するタイミング

ほとんどが独立したタスクで構成される実装計画が文書化されており、現在のセッション内で作業を進めたい場合に使用します。複数のセッションにまたがって実行する場合は、executing-plans を使用します。

手順

1. 計画を読み、すべてのタスクを全文で抽出して TodoWrite を作成します
2. タスクごとに、タスクの説明、ベースラインの参照情報、チェックポイント、対象外事項を実装担当者に渡して割り当てます
3. 実装担当者が完了したら、仕様準拠レビュー担当者を割り当てます → 不足箇所を修正 → ✅ になるまで再レビューします
4. コード品質レビュー担当者を割り当てます → 問題を修正 → ✅ になるまで再レビューします
5. コーディネーターが新たに検証を実行し、タスクが所有するパスのみをステージングして、まとまりのあるタスクをコミットします。Git の状態を読み返し、チェックポイント／乖離状況を更新して次のタスクに進みます
6. すべてのタスクが完了したら、最終コードレビュー → 完了検証を行います。ブランチの終了処理は、タスクによって作成されたブランチ／worktree がある場合、または統合作業を依頼された場合にのみ行います

リポジトリへの最初の書き込み前に、調整を担当するエージェントは TaskStartSnapshot を記録します。同じタスクのエージェントは同じワークスペースを共有します。ステージング、コミット、ブランチ、worktree など、Git のライフサイクル状態を変更する作業は、原則としてコーディネーターのみが行います。実装担当者とレビュー担当者は編集、検証、報告を行いますが、Git のライフサイクル状態は変更しません。タスクの複雑さ、TDD、計画、サブエージェントの使用、またはブランチ名が main／master であることだけでは、作業を分離する理由にはなりません。

複数のセッションにまたがる計画を引き継ぐ場合や、再開可能な状態が必要な場合は、作業を始める前に long-task-continuation を読み込み、チェックポイントを作成します。それ以外の場合は、チェックポイントをインラインで管理します。すべての実装担当者へのプロンプトにチェックポイントを含めます。

実装担当者に割り当てる前に、会話履歴全体を渡すのではなく、SubagentContextPacket を作成します。以下を含めます。

• タスク
• 目標と停止条件
• 関連するベースラインの参照情報とファイル
• 既知の事実と不明点
• 対象外事項
• ユーザーの目的、アクション、条件、この作業範囲に関連する成果物を含む、期待する出力と検証内容。この範囲内で子エージェントが示す証拠と、タスク全体の成果物に関するコーディネーターの責任を区別します
• 記録済みの TDD Mode、Route、authority、およびワークフロー／担当者の選定
• 必読の抜粋
• 安全でない前提

パケットは簡潔な引き継ぎ資料であり、証拠の代わりにはなりません。サブエージェントが検証すべき事実については、元の抜粋またはファイルの参照情報を渡します。

SubagentContextPacket にチャットの全文、セッション履歴全体、または際限のないログを貼り付けないでください。必読の抜粋、ファイルの参照情報、行や範囲の目安、安全でない前提を明示する方法を優先します。

スライスのライフサイクルと結果の信頼性

スライスの最小限のベースラインをコーディネーターが読み終えてから、実行経路を選択してください。スライスの実行中はその経路を固定し、ローカルなコンテキストの圧迫を理由に、インライン実行と委譲実行を行き来しないでください。パケットを現在のベースラインまたはチェックポイントに紐付けてください。ワークスペースや統制する事実が変わった場合は、結果を古い／不明とし、暗黙的に統合するのではなく再評価してください。

子からの出力は証拠または提案であり、指示や権威ある状態更新ではありません。簡潔な概要、証拠の場所、未解決の不明点、副作用に関する宣言があればそれを必須としてください。一部完了、キャンセル、ブロック、または古い結果は、コーディネーターが統合する際にも、結論が出ていないことが明確に分かる状態に保ってください。

委譲の追加機会には、ベースラインの確定後に行う独立した調査、競合箇所の三角測量、変更前のリスクレビュー、ブロックされた試行後のコンテキスト変更があります。これらは推奨の合図であり、再帰的な子の追加、共有ライター、ランタイムスケジューラーを許可するものではありません。

モデルの選択

役割ごとに必要最低限の能力のモデルを使用してください。機械的な作業（1～2 ファイル、完全な仕様あり）には、高速で低コストのモデルを使用します。統合（複数ファイル、パターンマッチング）には標準モデルを使用します。アーキテクチャ、設計、レビューには最も高性能なモデルを使用します。

実装担当者のステータスへの対応

実装担当者への各プロンプトには、次の内容を含める必要があります。

• 有効なタスクの内容
• 目標の設定、長時間のタスク、またはマルチエージェント作業が有効な場合は SubagentContextPacket
• 関連するベースライン参照
• 最新の TodoCheckpointDraft
• ResumeStateHint があればその内容
• 明示的な非目標
• タスクで期待される検証

実装担当者はタスク内の証拠を更新できますが、統合チェックポイントの管理責任はコントローラーにあります。 Git の変更もすべてコントローラーが管理します。ただし、同時に書き込む担当者がいない状態で、所有権が明示的かつ完全に移譲されている場合は除きます。

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

DONE： 仕様準拠のレビューに進みます。

DONE_WITH_CONCERNS： 実装担当者は作業を完了しましたが、懸念点を挙げています。続行する前にその懸念点を確認してください。正確性またはスコープに関する懸念であれば、レビューの前に対処してください。「このファイルは大きくなってきています」のような所見であれば、記録してレビューに進みます。

NEEDS_CONTEXT： 提供されていない情報が必要です。不足しているコンテキストを提供し、再度割り当ててください。

BLOCKED： 実装担当者はタスクを完了できません。ブロッカーを評価してください。

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

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

プロンプトテンプレート

• ./implementer-prompt.md - 実装担当者のサブエージェントを割り当てる
• ./spec-reviewer-prompt.md - 仕様準拠レビュアーのサブエージェントを割り当てる
• ./code-quality-reviewer-prompt.md - コード品質レビュアーのサブエージェントを割り当てる

危険信号

絶対に行わないでください：

• レビューを省略する（仕様への準拠またはコード品質）
• 未修正の問題を残したまま進める
• 複数の実装サブエージェントを並行して実行する（競合が発生します）
• サブエージェントに計画ファイルを読ませる（代わりに全文を渡してください）
• 状況を説明するコンテキストを省略する（サブエージェントはタスクの位置付けを把握する必要があります）
• サブエージェントからの質問を無視する（作業を進めさせる前に回答してください）
• 仕様への準拠について「おおむね問題ない」で済ませる（仕様レビューで問題が見つかった場合は、完了していません）
• レビューの反復を省略する（レビュー担当者が問題を発見したら、実装担当者が修正し、再度レビューしてください）
• 実装担当者のセルフレビューを実際のレビューの代わりにする（どちらも必要です）
• 仕様への準拠が✅になる前にコード品質レビューを開始する（順序が間違っています）
• どちらかのレビューに未解決の問題がある状態で次のタスクに進む
• 実装担当者やレビュー担当者に、ステージング、コミット、ブランチ作成、または worktree の作成や削除を許可する
• 同じタスクに取り組むエージェントごとに worktree を作成する

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

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

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

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

仕様への準拠とコード品質のレビューに合格したら、統合チェックポイントを更新し、次のタスクに進む前にドリフトチェックを実行します。 コーディネーターはまず最新の検証を実行し、対象を限定したタスクコミットを1つ作成してから、HEAD、コミットされたファイルの一覧、残りのタスク差分を読み返します。

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

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

統合

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

• aegis:writing-plans - このスキルが実行する計画を作成します
• aegis:requesting-code-review - レビュー担当サブエージェント向けのコードレビュー用テンプレートです
• aegis:using-git-worktrees - 必要な並行チェックアウトに対する条件付き例外です
• aegis:finishing-a-development-branch - タスク用に作成したブランチまたは worktree の条件付き統合／クリーンアップです

サブエージェントは次を使用する必要があります：

• 親の TDD 判定を検証して適用します。判定が欠落しているか無効な auto の場合は、ソースを編集する前に判定を選択した担当者に差し戻します。off の場合は、aegis:test-driven-development を自動で読み込んだり、RED／GREEN を強制したりせず、タスクに応じた検証を行います。TDD Route: strict の場合、またはユーザー／プロジェクトから明示的に TDD を求められた場合にのみ読み込みます。

代替ワークフロー：

• aegis:executing-plans - 同一セッション内で実行する代わりに、並行セッションで使用します