subagent-driven-developmentlisted

# 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コントラクトを破壊していな