subagent-driven-development

Subagent-Driven Development

実装計画の各タスクを専門サブエージェントに委譲し、2段階レビュー（spec準拠+品質）で高品質な実装を高速に回す。

Iron Law

NO MERGE WITHOUT TWO-STAGE REVIEW

Spec Reviewerによる仕様準拠確認とQuality Reviewerによる品質確認の両方を通過しない限り、タスクを完了としない。

Common Rationalizations

こう思ったら	現実
「Spec Reviewは実装者を信頼してスキップ」	信頼とレビューは別。2段階は必須
「小さい修正だからQuality Review不要」	小さい修正こそバグが潜む。スキップ禁止
「前のタスクと同じパターンだからレビュー軽め」	各タスクは独立評価。前回の結果は根拠にならない

核心原則: Fresh subagent per task + two-stage review = high quality, fast iteration

---

プロセス概要

Plan読み込み → タスク抽出 → 各タスクについて:
  1. Implementerサブエージェント派遣
  2. Spec Reviewerサブエージェント派遣
  3. (問題あれば) Implementer修正 → 再レビュー
  4. Quality Reviewerサブエージェント派遣
  5. (問題あれば) Implementer修正 → 再レビュー
  6. タスク完了 → 次のタスクへ
→ 全タスク完了後、最終統合レビュー

---

Step 1: 計画読み込みとタスク抽出

1. plan.md と todo.md を読む
2. 各タスクに以下の情報を付与:
   • 変更対象ファイル
   • 受入基準（specから該当部分を抽出）
   • 依存関係（前のタスクの完了が必要か）
   • 推奨モデル（複雑度に応じて選択）

モデル選択ガイド

タスク複雑度	推奨	例
低（機械的）	haiku	単純なCRUD、テンプレート適用
中（統合）	sonnet	API連携、コンポーネント結合
高（設計判断）	opus	アーキテクチャ決定、複雑なロジック

Step 2: Implementerサブエージェント派遣

各タスクに対して、以下の情報を含むプロンプトでサブエージェントを起動:

タスク: {タスク名}
スコープ: {変更対象ファイル}
受入基準: {具体的な基準}
既存パターン: {プロジェクトの既存実装パターン}
制約: {アーキテクチャ構造、依存方向、命名規則}

Implementerのルール:

• 不明点があれば実装前に質問する（推測で進めない）
• 既存パターンに従う
• テストを含める
• 実装後にセルフレビューを行う

Step 3: Spec Reviewerサブエージェント派遣

Implementerの成果物に対して、spec準拠レビューを実施:

チェック項目:
□ 受入基準を全て満たしているか
□ スコープ外の変更がないか
□ 既存のAPIコントラクトを破壊していないか
□ テストが受入基準をカバーしているか

判定: PASS / FAIL（修正必須箇所を明示）

FAIL → Implementerに差し戻し → 修正 → 再レビュー

Step 4: Quality Reviewerサブエージェント派遣

Spec PASSした成果物に対して、コード品質レビューを実施:

チェック項目:
□ アーキテクチャ原則の遵守（レイヤー間依存方向）
□ 命名の一貫性
□ エラーハンドリング
□ パフォーマンス（N+1クエリ、不要なデータ取得）
□ セキュリティ（入力バリデーション、認証・認可）
□ テスト品質（境界値、異常系）

判定: PASS / WARN（改善提案）/ FAIL（修正必須）

FAIL → Implementerに差し戻し → 修正 → 再レビュー

Step 5: 最終統合レビュー

全タスク完了後:

1. 全変更ファイルの統合的なレビュー
2. コンフリクトの確認
3. プロジェクトの検証コマンド実行（lint/test/typecheck）
4. todo.md の全チェック更新