subagent-driven-development

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

タスクごとに新しいサブエージェントを割り当て、各タスクの後に2段階のレビューを行います。

基本原則： タスクごとに新しいサブエージェントを割り当てる＋2段階のレビュー（仕様、その後に品質）＋差分ベースの検証＝高品質かつ迅速な反復

クイックリファレンス

フェーズ	担当者	アクション	完了条件
1	コントローラー	計画を読み、タスクを抽出し、BASE_SHAを記録してタスクリストを作成する	すべてのタスクがBASE_SHAとともに記録されている
2	サブエージェント	実装する（templates/implementer.md）	コミットが存在し、テストが合格し、レポートにHEAD_SHAが含まれている
3	サブエージェント	仕様レビュー（templates/spec-reviewer.md）	レビュアーがdiff(BASE..HEAD)を確認し、✅またはファイル名:行番号の問題を返している
4	サブエージェント	品質レビュー（templates/code-quality-reviewer.md）	レビュアーが差分を承認している、または重大度付きの問題を返している
5	コントローラー	状態を更新して完了にし、ステップ2を繰り返す	すべてのタスクが完了している
6	サブエージェント	実装全体の最終レビュー	承認されている
7	コントローラー	finishing-a-development-branchを使用する	ブランチが完了している

タスクの契約

すべてのタスクは、次の制約を満たす必要があります。

範囲：

• 1つのタスク＝1つのコミット（または密接に関連するコミットのまとまり）
• ついでのリファクタリングは禁止。フォーマットの不要な変更も禁止
• 無関係なファイルを変更しない

検証：

• すべてのテストに合格する（全テストスイート、または影響を受ける範囲を実行する）
• リント／型チェックに合格する（該当する場合）
• コマンドを実際に実行する（実行したと仮定しない）

レポートに必ず含める項目：

• BASE_SHA（コントローラーから受け取ったもの）
• HEAD_SHA（コミット後のもの）
• 実行したコマンド（正確で、コピーして実行できるもの）
• テスト結果の概要（合格／失敗と件数）
• 変更したファイル（一覧）
• 範囲の確認（「無関係な変更はありません」）

状態管理

コントローラーはタスクごとの記録を管理します。

{
  task_id: string,
  base_sha: string,      # Captured before implementer starts
  head_sha: string,      # From implementer report after commit
  status: pending|in_progress|spec_review|quality_review|complete,
  spec_review_cycles: number,
  quality_review_cycles: number
}

各フェーズの移行後に状態を更新します。

プロセス

セットアップ（一度だけ）

1. 計画ファイルを一度読む
2. すべてのタスクを全文とコンテキストとともに抽出する
3. 最初のタスクのBASE_SHAとして現在のHEADを記録する
4. すべてのタスクを含むタスクリストを作成する（ステータス：pending）

タスクごとのループ

1. このタスクのBASE_SHAを記録する（現在のHEAD）
2. タスクの全文、コンテキスト、BASE_SHAを添えて実装担当者を割り当てる
3. 質問がある場合： すべて回答し、回答を添えて再度割り当てる
4. 実装担当者が完了： 実装、テスト、コミットを行い、HEAD_SHAを報告する
5. 状態を更新： HEAD_SHAを記録し、ステータスをspec_reviewに設定する
6. タスク要件とdiff(BASE_SHA..HEAD_SHA)を添えて仕様レビュアーを割り当てる
7. 仕様上の問題がある場合： 実装担当者が修正し、仕様レビュアーが再レビューする → サイクル数を増やす → ✅になるまで繰り返す
8. 状態を更新： ステータスをquality_reviewに設定する
9. BASE_SHAとHEAD_SHAを添えてコード品質レビュアーを割り当てる
10. 品質上の問題がある場合： 実装担当者が修正し、品質レビュアーが再レビューする → サイクル数を増やす → ✅になるまで繰り返す
11. 状態を更新： ステータスをcompleteに設定し、次のタスクのBASE_SHAを現在のHEAD_SHAにする

完了

1. 実装全体を対象とする最終コードレビュアーを割り当てる（最初のBASE_SHAから最終HEAD_SHAまで）
2. finishing-a-development-branchスキルを使用する

プロンプトテンプレート

• templates/implementer.md — 実装サブエージェント
• templates/spec-reviewer.md — 仕様準拠の検証（差分ベース）
• templates/code-quality-reviewer.md — コード品質の評価（差分ベース）

SHA追跡を含む一連の手順については、references/example-workflow.mdを参照してください。

注意すべき兆候

決して次のことをしないでください：

• レビューを省略する（仕様への準拠またはコード品質）
• 未修正の問題があるまま先に進む
• 同じ作業ツリーで並行して実装担当者を割り当てる（競合が発生します）
• サブエージェントに計画ファイルを読ませる（全文を渡してください）
• BASE_SHA/HEAD_SHA の追跡を省略する
• 特定の差分ではなく「リポジトリ」全体をレビューするようレビュアーに任せる
• 必須フィールド（SHA、コマンド、テスト出力）がない報告を受け入れる

並行作業に関する補足： 別々のブランチやワークツリーを使った「並行セッション」は、executing-plans を通じて問題ありません。同じ作業ツリーに変更を加える「並行する実装担当者」は禁止です。

サブエージェントから質問があった場合： 作業を進める前に、明確かつ完全に回答してください。

レビュアーが問題を見つけた場合： 実装担当者が修正 → レビュアーが特定の差分を再レビュー → 承認されるまで繰り返します。

実装担当者が必要なリファクタリングに気づいた場合： 作業を止め、コントローラーに報告し、計画の修正を依頼してください。強引に進めないでください。

依存関係

必須： writing-plans（計画を作成します）

サブエージェントが使用： test-driven-development、requesting-code-review（テンプレート）

完了時に使用： finishing-a-development-branch

代替手段： executing-plans（並行する実装担当者ではなく、並行セッションやブランチ向け）

環境に関する注意： このスキルでは、git（SHA の追跡用）、タスク一覧ツール（TodoWrite または同等のもの）、およびサブエージェントを割り当てる機能が利用できることを前提としています。ツール名は、ご利用の環境に合わせて調整してください。