القائمة
規模に応じた計画、承認、実装、検証、エスカレーションのフローでサブエージェントを調整。サブエージェントへの作業振り分け、承認済み作業計画の実行、自律実行の再開時に使用。
يُحدَّد Prompt الذي يراجع المصدر أولًا بشكل افتراضي. يمكنك التبديل إلى أمر مباشر أو تنزيل نسخة محلية.
اقرأ SKILL.md وأي ملفات مرافقة يعرضها SkillsMP قبل أن تقرر التثبيت.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
يتجاوز الأمر المباشر Prompt المخصّص للمراجعة. افحص المصدر قبل تشغيله.
npx skills add https://github.com/shinpr/ai-coding-project-boilerplate --skill subagents-orchestration-guideيبقى الأمر في سطر واحد. مرّر أفقيًا لمراجعته كاملًا قبل النسخ.
تفضّل نسخة محلية؟ نزّل الملفات المتاحة حاليًا لدى SkillsMP.
عرض SKILL.md
| name | subagents-orchestration-guide |
| description | 規模に応じた計画、承認、実装、検証、エスカレーションのフローでサブエージェントを調整。サブエージェントへの作業振り分け、承認済み作業計画の実行、自律実行の再開時に使用。 |
ユーザーの明示的な指示: ユーザーは、呼び出されたレシピで名前が挙げられたすべてのサブエージェント呼び出しを明示的に指示し、承認している。各呼び出しの前提条件を満たした時点で、該当する呼び出しを実行する。
新しいタスクを受け取ったら、ユーザー要件をrequirement-analyzerに直接渡す。その依頼・スコープ・コスト・質問のエビデンスを用いて要件収束を実行し、構造スケールを割り当てる。どちらの判定もオーケストレーターが持つ。requirement-analyzer を再実行するのは、ヒアリングの回答が分析対象または必要なスコープエビデンスを変える場合のみとする。
フロー実行中にユーザーレスポンスで以下を検知したら、フローを停止してrequirement-analyzerへ：
いずれかに該当する場合は、統合した要件を記録する。requirement-analyzerから再開するのは新たなリポジトリのエビデンスが必要な場合のみとし、それ以外は既存のエビデンスから再収束・再ルーティングする。
「何を達成するか」「どこで作業するか」を渡す。各サブエージェントは「どう実行するか」を自律的に決定する。
渡す情報（what/where/制約）:
サブエージェントに委ねる判断（how）:
| Bad（howを指定） | Good（whatを指定） | |
|---|---|---|
| quality-fixer | 「lint → test の順でチェックして」 | 「品質チェックと修正をすべて実行して」 |
| task-executor | 「ファイルXにハンドラYを追加して」 | 「タスクファイル: docs/plans/tasks/003-feature.md」 |
出力が矛盾した場合の優先順位:
サブエージェント同士の判断が衝突した場合、またはサブエージェントの出力が期待と異なる場合、上記の優先順位を適用する。リポジトリの客観的状態（3）で検証し、1・2と整合する出力に従う。矛盾がある場合はユーザー指示、次いで設計成果物に従う。
サブエージェントがblockedを返した場合、まずリポジトリのエビデンスから発見可能な入力やルーティングの問題を修正し、その修正で呼び出し内容が実質的に変わる場合は再実行する。前進のためにユーザーが持つ成果・権限・不可逆な外部判断が必要な場合に限りエスカレーションする。
対応可能な成果物レビューの検出事項には references/review-resolution.md を適用する。処理方針の決定、結果の検証、作業のルーティングはオーケストレーターが行い、成果物の作成・変更は指名した専門エージェントが行う。検出事項単位の修正ループ — 処理方針の割り当て、apply の逐語ハンドオフ、prior_feedback による再レビュー、収束とエスカレーションの条件 — は、この参照先が最初から最後まで持つ。
task-executorの責務:
quality-fixerの責務:
基本サイクル: task-executor → ユーザーが持つ境界の判定・フォローアップ → quality-fixer → コミット の4ステップサイクルを管理。
各タスクごとにこのサイクルを繰り返し、品質を保証。
レイヤー別ルーティング: レイヤー横断機能では、タスクファイル名パターンに基づいてexecutorとquality-fixerを選択（レイヤー横断オーケストレーション参照）。
ワークフローの連携はフラットに保つ。各 specialist の呼び出しと結果の受け取りはすべてオーケストレーターが行い、specialist の定義では Agent をツールセットに含めない。
オーケストレーターは、収束した成果とリポジトリのエビデンスに documentation-criteria を適用する。スケールは判断負荷に従う: 小規模は1つの責務境界の中に明白な実装が1つ、中規模は境界をまたいだ調整または持続的になりうる選択を含み、大規模は別個の設計判断を要する独立した成果を複数含む。ファイル数は補助的なエビデンスにとどまる。
| スケール | PRD | ADR | Design Doc | 作業計画書 |
|---|---|---|---|---|
| 小規模 | プロダクトスコープが変わる場合は更新 | 不要 | 不要 | 不要 — task-executor が明示プロンプトから実行する |
| 中規模 | プロダクトスコープが変わる場合は更新 | ADRの両フィルタを通過した決定ポイントのみ | 必須 | 必須 |
| 大規模 | 必須 — 新規作成・更新・リバースPRDのいずれか | ADRの両フィルタを通過した決定ポイントのみ | 必須 | 必須 |
適格なADRが存在する場合、スケールは最低でも中規模に引き上げられる。適格なADRはすべて1つのバッチとしてレビューし、受理した決定を Design Doc 作成前に Accepted にする。
すべてのサブエージェント呼び出しは Agent ツール を使用し、以下を渡す:
subagent_type: エージェント名（例: "task-executor"）description: 簡潔なタスク記述（3〜5語）prompt: 成果物のパスを含む具体的な指示オーケストレーターは以下のツールのみで作業を統制する:
| ツール | 用途 |
|---|---|
| Agent | サブエージェントの呼び出し |
| AskUserQuestion | ユーザー確認・質問 |
| Bash | シェル操作（git commit、ls、検証コマンド） |
| Read | サブエージェント間の情報橋渡しのための成果物ドキュメント参照 |
実装作業（Edit、Write、MultiEdit）はすべてサブエージェントが実施する。オーケストレーター自身は行わない。
サブエージェントはJSON形式で応答する。各エージェントは自身の入出力契約を宣言しているため、呼び出しを組み立てる際はその契約をエージェント側で読む。この表が持つのは、分岐に使う信号と、各値が選ぶ行動だけである。
| Agent | 分岐に使う信号 | 各値での行動 |
|---|---|---|
| requirement-analyzer | requestSignals、scopeEvidence、costEvidence、questions | 要件を収束させ、構造スケールを割り当て、より深いコードベースのエビデンスが必要かを判断する |
| codebase-analyzer / ui-analyzer | — | JSON全体をそのまま次の専門エージェントへ渡す。各エージェントは自身の入力宣言が挙げるフィールドを消費する |
| technical-designer / technical-designer-frontend | status | completed → 続行。evidence_exhausted → 正確な前提と確認済みのエビデンスを終端報告として現在の設計試行を終える。再度の修正には、その前提を直接扱う新しいエビデンスが必要であり、ユーザーへのエスカレーションにはユーザーが所有する判断が必要となる。contradiction → 出典ソースの優先順位で解決し、残る判断をユーザーが所有する場合だけエスカレーションする |
| task-executor / task-executor-frontend | status、escalation_type、requiresTestReview | completed → サイクルを継続。escalation_needed → エージェントが定義する escalation_type に従って処理し、ユーザー判断が要る項目は提示する。requiresTestReview: true → quality-fixer の前に integration-test-reviewer を実行 |
| quality-fixer / quality-fixer-frontend | status | approved → コミット。stub_detected → incompleteImplementations[] を実装ステップに戻し再実行。blocked → ユーザーが判断すべき内容をそのまま提示 |
| document-reviewer | verdict.decision | approved → 次へ。needs_revision → レビュー裁定を実行。rejected → 出典ソースの衝突を解消するか、ユーザーの権限が必要な場合はエスカレーション |
| integration-test-reviewer | status | approved → 次へ。needs_revision → レビュー裁定を実行。blocked → 変更されたテストパスを解決して呼び出しを1回だけ是正する。テストが存在しない場合はその欠陥を executor へ差し戻す。再度 blocked が返る場合はレビュー未実施を記録し、その未証明の状態を完了レポートに引き継ぐ |
| code-verifier / security-reviewer | summary.status / status | 「実装後検証の合否基準」を参照。不可逆操作のハザードによる security の blocked は必要な判断を名指しし、エージェント層の権限の外にある |
| design-sync | sync_status |
オーケストレーターが持つエージェント間の配線: quality-fixer には、未追跡・削除・リネームを含む現在の未コミットのワークツリー全体を調べるよう依頼する。実装ステップの runnableCheck を引き継ぎ、レシピまたは technical-spec がプロジェクトの正典となる品質コマンドを示している場合は qualityCommand として渡す。
quality-fixer は、実行できなかったチェックと無関係と確認済みの既存失敗を、既存のチェック結果に記録する。今回の変更に関係する実行可能なチェックがパスした後は、approved として通常のルーティングを続ける。今回の変更が原因の失敗、または受け入れ済みの成果に必要な依存の失敗は、元のタスクにそのパスがなくても修正対象とする。
新機能や変更要求を受け取ったら、まず要件のエビデンスを収集し、要件を収束させ、構造スケールを割り当てる。
ADRBatch モードで実行 → document-reviewer によるバッチレビュー → 検出事項の裁定 → 受理したADRを Accepted にする [停止]DesignDoc モードで実行 → code-verifier → document-reviewer → design-sync → Design Doc承認 [停止]ADRBatch モードで実行 → document-reviewer によるバッチレビュー → 検出事項の裁定 → 受理したADRを Accepted にする [停止]DesignDoc モードで実行 → code-verifier → document-reviewer → design-sync → Design Doc承認 [停止]小規模では作業計画書もタスクファイルも作成しない。新たに適格なADRが判明した場合は中規模へ移行し、それ以外では計画ドキュメントを導入しない。
該当するStructural Scaleフローを、エビデンスで区切られたシーケンスとして扱う。現在のフェーズに、明記されたルーティング条件で必要な成果物、承認、または結果が存在する場合にのみ次へ進む。完了を報告する前に、そのエビデンスが存在しない最も早い適用可能なフェーズから再開する。
オーケストレーターが scopeEvidence.affectedLayers から、機能が backend と frontend にまたがると判断した場合、単一のコードベース分析とDesign Docの区間を、以下のbackend先行・frontend後続の順序に置き換える。
標準のDesign Doc作成ステップをレイヤー別作成に置き換え:
| ステップ | エージェント | 目的 |
|---|---|---|
| 8 | codebase-analyzer | 確認済みのレイヤー横断スコープ全体を分析する。出典ソースは prd_path または requirements のちょうど1つを渡す |
| 9 | technical-designer | バックエンドDesign Doc（ステップ8のうちバックエンドに関係するエビデンスを使用） |
| 10 | code-verifier | バックエンドDesign Docを既存コードに対して検証（結果JSONはステップ12にprior_layer_verificationとして渡す） |
| 11 | document-reviewer | バックエンドDesign Docをレビュー（ステップ10の結果をverification_evidence、ステップ8のJSONをcodebase_analysisとして入力）。needs_revision は裁定して解消し、rejected では停止する |
| 12 | technical-designer-frontend | フロントエンドDesign Doc（ステップ8のうちフロントエンドに関係するエビデンス + レビュー済みバックエンドDesign Doc + ステップ10のprior_layer_verification + UI Spec） |
| 13 | code-verifier | フロントエンドDesign Docを既存コードに対して検証 |
| 14 | document-reviewer | フロントエンドDesign Docをレビュー（ステップ13の結果と記録した処理方針をverification_evidence、ステップ8のJSONをcodebase_analysisとして入力）。needs_revision は裁定して解消し、rejected ではステップ15の前で停止する |
| 15 | design-sync | レイヤー間整合性検証 [停止] |
ステップ8は1回だけ実行し、そのJSON全体を両方のdesignerがそのまま再利用する。各designerは自身のレイヤーに関係するエビデンスを消費する。バックエンド経路（ステップ9〜11）はステップ12の前に直列で完了させる。これによりフロントエンドdesignerは、リポジトリ上の検証結果とレビュー済みのバックエンド契約の両方を受け取る。
Design Doc作成時のレイヤーコンテキスト指定:
maintained のレビュー issue のみを不安定な契約として扱う。UI Spec [パス] のコンポーネント構造を参照。対象: コンポーネント階層、状態管理、UI操作、データ取得。」design-sync: フロントエンドDesign Docをソースとして使用。docs/design/内の他のDesign Docを自動検出して比較。
全Design Docをwork-plannerに渡し、垂直スライスで構成を指示:
自律実行中、タスクファイル名パターンに基づいてエージェントを選択する。この表は、作業計画書のタスクエントリが選ぶ2つの Executor lane も定義している:
| Executor lane | ファイル名パターン | Executor | Quality Fixer |
|---|---|---|---|
backend | *-task-* または *-backend-task-* | task-executor | quality-fixer |
frontend | *-frontend-task-* | task-executor-frontend | quality-fixer-frontend |
作業計画書のタスクエントリは lane をちょうど1つ記録する。タスク実体化はその値をコピーし、対象パスからレイヤーを推論するのではなく、この表からファイル名を選ぶ。
自律実行モード開始後：
status: escalation_needed または status: blocked → 宣言されたユーザーが持つ境界を確認し、リポジトリのエビデンスを調べても未解決の場合はエスカレーションrequiresTestReview が true → integration-test-reviewer を実行
status が needs_revision → レビュー裁定を適用し、同じ task_file と apply の quality-issue オブジェクト一式を逐語で渡して、ルーティング先の executor（レイヤー別エージェントルーティング 参照、task-executor または task-executor-frontend）を Fix Mode で再実行するstatus が blocked → 移動・リネームされた変更テストパスを解決してレビュアを1回だけ再実行する。requiresTestReview: true にもかかわらず変更されたテストが存在しない場合は、その executor 出力の欠陥を Fix Mode でルーティング先の executor に差し戻す。再実行でも blocked が返る場合はレビュー未実施を記録して quality-fixer へ進むstatus が approved → quality-fixer へ進む以下の場合に自律実行を停止し、ユーザーにエスカレーション：
サブエージェントが示した、ユーザーが持つ境界
要件変更検知時
work-planner更新制限に抵触時
ユーザー明示停止時
すべてのサブエージェントプロンプトに以下を含める:
エージェントのInput Parametersセクションと、フロー内のその時点で利用可能な成果物からプロンプトを構成する。
追加の2つのルール:
[placeholder] は Agent ツール呼び出し前にすべて具体値へ置換する。選択したフローの完了後、以下を返す：
{
"status": "completed | blocked", "scale": "small | medium | large", "completedTasks": [{"taskFile": "path", "status": "completed", "commit": "sha-or-null"}], "filesModified": ["path"],
"verification": [{"check": "name", "result": "passed | failed | not_run", "evidence": "command or verifier result"}], "verifiers": [{"name": "agent",
選択したフローで必須のタスク、品質ゲート、検証エージェント、commit stepがすべて完了した場合にstatusをcompletedとする。実行できなかったチェックはverificationに記録し、未解決のユーザー判断によって完了できない場合に限りblockedとする。
状態管理: 現在のフェーズ、各サブエージェントの状態、次のアクションを把握
情報の橋渡し: サブエージェント間のデータ変換と伝達
渡すもの: オーケストレーターが判定した convergence 記録を、それを引き継ぐエージェントへ渡す。内容は変更せずに渡し、各フィールドの readiness ラベルも一緒に運ぶ。
outcome は 成功基準 に、ユーザーが挙げた nonGoals は Out of Scope に残す。PRDには確認済みの要件と境界だけを残し、評価依頼、推測的なアイデア、未選択の実装手段は要件確認前の収束コンテキストに留めるRequirement Convergence へ永続化し、weak-but-explicit のまま残ったフィールドは常にそこへ記録するnonGoals を受け取る。未選択の候補からUI Specの内容を作らないnonGoals は全タスクエントリから除外し、未選択の候補から計画上の作業を作らない。小規模ではPRDもDesign Docも存在しないため、weak-but-explicit のフィールドは保存プロトコルに従いオーケストレーター自身のコンテキストに留め、タスクファイルのブロッキング項目にはしないcodebase-analyzerへの入力: 出典ソースちょうど1つ — 承認済みPRDが存在する場合はそのパス、存在しない場合は確認済み要件 technical-designerへの入力: codebase-analyzerのJSON出力をDesign Doc作成プロンプトの追加コンテキストとして渡す。必須の使い道:
focusAreas → Fact Disposition Tableの正典となるdisposition targetリスト（各focusAreaを1行に展開し、fact_idとevidenceをそのまま引き継ぐ）dataModel、dataTransformationPipelines、qualityAssurance → 「既存コードベース分析」「検証戦略」の各セクションに反映code-verifierへの入力: Design Docパス（doc_type: design-doc）。code_pathsは指定を省略する — verifierがドキュメントからコードスコープを独自に発見する。
document-reviewerへの入力: 最新のcode-verifier結果と記録したレビュー裁定の処理方針をあわせてverification_evidenceとして、designerに渡したものと同じcodebase-analyzerのJSONをcodebase_analysisとして、出典ソースをconfirmed_requirement_contextとして渡す。該当する場合は元の依頼をrequirements_verbatimとして渡す。reviewerはでFact Disposition Tableのカバレッジを検証し、確認済み要件のコンテキストでドキュメントの成果と契約を検証する。
approved を返した後にタスクをコミットできる| Verifier | Pass | Fail | Blocked |
|---|---|---|---|
| code-verifier | summary.statusがconsistent | summary.statusがneeds_reviewまたはinconsistent | summary.statusがblocked → blockingReasonを添えてエスカレーション。検証可能な入力がなかった状態である |
| security-reviewer | statusがapproved | statusがneeds_revision | statusがblocked → 不可逆操作、またはエージェントの権限外として名指しされた判断をエスカレーション |
再実行ルール: 不合格となった検証エージェントの検出事項にレビュー裁定を適用し、修正対象になった検出事項を返した検証エージェントだけを再実行する。修正の収束とエスカレーションはレビュー裁定が担い、合格した検証エージェントの記録済みエビデンスは維持する。
修正サイクルのハンドオフ: レビュー裁定を適用し、必要な各 executor には apply の検出事項オブジェクト全体を逐語で、処理方針のみ付加して渡す。照合を受け付けるレビュアー入力には prior_feedback を引き継ぐ。
CONFLICTS_FOUND → 矛盾をユーザーに提示してから進む |
| acceptance-test-generator | generatedFiles[] | 出力された各パスの存在を確認し、work-planner へ渡す。空のリストは、追加のスケルトンを要する未充足の証明義務がないことを示す |
codebase_analysis.focusAreas担当designerへの入力: 新規の update 呼び出しに、既存のDesign Docパスと、apply の処理方針だけを加えてそれ以外はそのままコピーした correction_findings 全体を渡す。承認済み要件、受理済みの決定、従来のエビデンス、影響を受けない設計コンテキストは既存成果物が保持するため、オーケストレーターが設計指示を追加しない。designer はレビューを起点とする範囲限定セルフ検証ゲートを適用し、確立済みのエビデンスに基づいて成果物を更新する。起点となった verifier または reviewer を再実行するのは、update が完了した場合だけとする。
次レイヤーのtechnical-designerへの入力: レビュー済みの前レイヤーDesign Docパスに加えてprior_layer_verification（前レイヤーcode-verifierのJSON）を渡す。シーケンスは「レイヤー横断オーケストレーション」セクションを参照。prior_layer_verification.discrepancies[]と前レイヤーのレビュー指摘を用いて不安定な契約を識別する。検証済みと見なせる主張は検証結果JSONに明示されているものに限定する。verifierで確認されていない主張に設計が依存せざるを得ない場合、フロントエンドDesign Docの「## Cross-Layer Assumptions」セクションに正当化と検証先を記載する（エスカレートする場合は同セクションで 検証先: ユーザーへエスカレーション と記載する — エスカレーションは下流の検証ステップで依存を閉じられない場合のみ選ぶ）。
work-plannerへの入力: Design Docパス。work-plannerは出典セクションとACを実装タスクへマッピングする。カバーされていない義務は修正すべき計画の漏れであり、作業計画書はカバー漏れや設計内容の不足をユーザー確認項目に変換しない。
ギャップ発生時の制御（オーケストレーターの責務）: work-plannerがgapを含むドラフト計画書を出力した場合、オーケストレーターは以下を実行する:
acceptance-test-generatorへの入力: Design Doc のパス、UI Spec のパス（存在する場合）。
オーケストレーターの検証: generatedFiles[] の各パスがディスク上に存在すること。空のリストも有効な生成結果である。
work-plannerへの入力: 生成されたパスとタイミングガイダンス — 統合テストは各フェーズ実装と並行して作成し、fixture-e2e テストは UI 機能フェーズと並行して作成し、service-integration-e2e テストは必要なサービスが利用可能になった後に実行する。
ADRステータス管理: ユーザー判断後のADRステータス更新（Accepted/Rejected）