• — 必須。相対パスまたは絶対パス（@docs/...も有効）。
• --lang— レビュー対象の言語バリエーション。デフォルトはauto（プロジェクトから検出）。
• --scope— 出力されるステップを制限します。デフォルトはall です。
• --dry-run— 分解とチェーンの根拠のみを出力し、最終的なプロンプトは出力しない。

標準的な/orchestrateシェイプ（これから逸脱しないでください）

{ORCH_CMD} custom ",,...," ""

ここで、{ORCH_CMD}はフェーズ 0 で決定される（後述）。出力されるコマンド文字列は常に 1 つの具体的な形式を使用する— 両方を併用したり、プレースホルダーを使用したりしてはならない。

• custom は順次連結されたチェーンであり、各エージェントの HANDOFF が次のエージェントに渡されます。
• エージェントのリストはコンマ区切りです。スペースは含まないことが推奨されますが、1 スペース程度なら許容されます。
• --mode/--gate/--agents=...といったフラグは存在しません。決してこれらを独自に作成しないでください。
• エージェント名は、このスキル内のカタログから取得されます。タスクの説明文中に埋め込まれた二重引用符は、\" としてエスケープされます。

ECCのインストール形式と名前空間

2つのインストール形式によって、スラッシュコマンドおよびすべてのエージェント名のプレフィックスが決定されます。これら2つは必ず同期を保つ必要があります。出力ごとに1つの形式を使用し、決して混在させてはいけません：

ここで をClaude Codeのホームディレクトリとします：macOS/Linuxでは~/.claude、Windowsでは%USERPROFILE%\.claude。ホストプラットフォームがユーザーのホームディレクトリを解決する方法に従って解決してください（~をハードコードしないでください）。

これが重要な理由：プラグインインストールでは、エージェントはeverything-claude-code:tdd-guide として登録されます。プレフィックスなしの名称ではあいまい一致が強制されるため、並列呼び出し時に断続的に失敗します。レガシー方式では、プレフィックス付きの形式は登録されず、即座に失敗します。

利用可能なエージェント一覧（これらの中から選択する必要があります）

一般：

• planner— 要件の再定式化、リスクの分解、ステップごとの計画
• architect— アーキテクチャ、システム設計、リファクタリングの提案
• tdd-guide— テスト作成 → 実装 → カバレッジ80%以上
• コードレビュー担当者— 一般的なコードレビュー
• セキュリティレビュー担当者— セキュリティ監査、OWASP、機密情報の漏洩
• リファクタリング・クリーナー— デッドコード、重複コード、knipクラスのクリーンアップ
• doc-updater— ドキュメント、コードマップ、README
• docs-lookup— サードパーティライブラリのAPI検索 (Context7)
• e2e-runner— エンドツーエンドテストのオーケストレーション
• database-reviewer— PostgreSQL スキーマ、マイグレーション、パフォーマンス
• harness-optimizer— ローカルエージェントハーネスの設定
• loop-operator— 長時間実行される自律ループ
• chief-of-staff— マルチチャネルのトリアージ（プランのステップとして適することは稀）

ビルドエラー解決ツール:

• build-error-resolver（汎用） /cpp-build-resolver/go-build-resolver/java-build-resolver/kotlin-build-resolver/rust-build-resolver/pytorch-build-resolver

コードレビューア:

• python-reviewer/typescript-reviewer/go-reviewer/rust-reviewer/cpp-reviewer/java-reviewer/kotlin-reviewer/flutter-reviewer

エージェント名のスペルが間違っていると、/orchestrate が失敗します。発行する前に、このリストと照合してください。

仕組み

フェーズ 0 — ECC モードと言語の検出

1. 読み込み 。欠落または空の場合は、報告して停止する。

2. ECCのインストール形式を一度検出し、それをECC_MODEとして固定する。アルゴリズム（順に実行し、最初の一致で停止）：

   1. /plugins/marketplaces/everything-claude-code/が存在する場合 →ECC_MODE=plugin。
   2. それ以外の場合、/agents/が存在し、少なくとも 1 つの ECC エージェントファイル（例:tdd-guide.md、code-reviewer.md）が含まれている場合 →ECC_MODE=legacy。
   3. それ以外の場合 → デフォルトでECC_MODE=legacyとし、出力の先頭に 1 行の警告を出力します：> 警告: ECC のインストールを検出できませんでした。デフォルトでレガシー形式を使用します。プラグインインストールを使用する場合は、プレフィックスを手動で編集してください。
   4. 両方のマーカーが存在する場合（混合インストール）、プラグインが優先されます。つまり、プラグインのネームスペースのみが、あいまい一致なしでエージェント名を解決します。

   この時点以降、出力されるすべての行では、スラッシュコマンドとすべてのエージェント名の両方に、一致するプレフィックスが使用されます。同じ出力に両方の形式を出力することは決してありません。

3. --lang を解決します。「auto」の場合、多言語対応の検出を実行します：

   • 検出対象のマーカー：pyproject.toml/uv.lock/requirements.txt→ python;package.json→ typescript;go.mod→ go;Cargo.toml→ rust;CMakeLists.txtまたはトップレベルの*.cpp→ cpp;pom.xml/build.gradle(Java) → java;build.gradle.ktsまたはトップレベルの Kotlin → kotlin;pubspec.yaml→ flutter。
   • 複数言語が検出された場合の優先順位: 複数のマーカーが一致する場合は、ソースファイル数が最も多い言語を選択します（git ls-files を使用してカウントし、vendor/、node_modules/、dist/、build/、.venv/、生成ファイル、および明らかなテスト用フィクスチャは除外します）。 同数の場合、またはソースファイルの 60% を超える言語がない場合は、lang=unknown に設定します。
   • 一致するマーカーがない場合 →lang=unknown に設定します。
   • lang=unknown はセンチネルであり、エージェント名ではありません。フェーズ 2 のルール 4 および 5 により、チェーン構成時にこれがコードレビュー担当者/ビルドエラー解決担当者に変換されます。

4. PyTorch サブプロファイルを検出：lang=pythonであり、かつpyproject.toml/requirements.txt/uv.lockのいずれかでtorch への依存関係が宣言されている場合、pytorch=true に設定します。これはビルドチェーンの選択（以下のフェーズ 2 のルール）にのみ影響し、レビュアーはpython-reviewer のままです。

5. プラン内で宣言されたエージェント名を正規化する：プランのテキスト内で、プラグイン接頭辞が付いた形式（例:everything-claude-code:tdd-guide）でエージェントが参照されている場合、チェーンの検証や構成を行う前に、接頭辞を削除してカタログ名のみを取得する。 プレフィックスの再付与は、ECC_MODEに基づき出力時（フェーズ 4）にのみ行われます。プレフィックスが既に付与された名前がチェーンの構成に流れないようにしてください。そうしないと、プラグインモードでプレフィックスが二重に付与されてしまいます。

フェーズ 1 — ステップの分解

優先順位に従って「ステップ単位」を特定します：

1. 明示的な番号付け：## ステップ N/### フェーズ N/## N. .../ トップレベルの順序付きリスト。
2. 表内の「ステップ」列。
3. ----で区切られた、動詞で始まる見出しを持つブロック。
4. それ以外の場合は、各H2見出しを1つのステップとして扱う。

ステップごとに、ID（1から始まる）、タイトル（80文字以内）、意図（1～3文）、タグを抽出する。

フェーズ 2 — タグ付けとチェーンの選定

意図に基づいてタグ付けを行う（複数タグ可。チェーンは主要タグ＋積み重ねられた二次タグで構成）：

以下のトリガーワードは、大文字小文字を区別せずに照合されます。多言語プランは、意味が記載された英語のトリガーワードと一致する限り、どの言語の語幹とも照合することでサポートされます。

チェーン構成ルール：

1. プライマリタグの選択：あるステップが複数のタグに一致する場合、テーブル順で最初のもの（テーブルの先頭＝最優先）がプライマリとなり、残りはセカンダリとなる。以下の構成ルール2および3は、特定のマルチタグの組み合わせを明示的に扱う。それ以外の場合は、タグテーブルの順序に従ってセカンダリチェーンを連結する。
2. impl+security→tdd-guide,-reviewer,security-reviewer.
3. impl+db→tdd-guide,database-reviewer,-reviewer。
4. 結果として得られたチェーンから重複を削除する（最初に現れたものを保持する）。例：review+lang=unknownの場合、ルール5の適用後はcode-reviewer,code-reviewerとなるが、重複削除によりcode-reviewer に統合される。
5. -reviewer は、lang=unknown の場合、code-reviewerに解決される。
6. -build-res olver は、lang=unknown の場合、build-error-resolverに解決されます。特例：フェーズ 0 でpytorch=true が設定されている場合、 。python-build-resolverは存在しません。pytorch=trueでない場合の--lang=pythonは、build-error-resolverに解決されます。
7. タグなしのステップ：一致するトリガーワードがない場合、チェーンをcode-reviewerに設定し、「一致するタグなし」と記述する。「チェーンの根拠」の下に、デフォルトのレビュー専用チェーンを記載する。
8. 重複除去後のチェーンの長さは 4 以下とする。これを超える場合は、最も弱いタグを削除する（検索とドキュメントを優先）。
9. 実装チェーンでは、plannerと architectをペアにしない（トークンの無駄）。これらをペアにするのは設計ステップに限る。
10. impl、refactor、またはmigrationのタグが付いたステップは、-reviewer、code-reviewer、security-reviewer、またはdatabase-reviewer のいずれかのレビュアークラスのエージェントで終了する。 最もドメイン特化度の高いレビュアーが末尾の位置を占める（例：ルール2の「impl+security」 はsecurity-reviewerで終了する；ルール3の「impl+db」は -reviewerで終了する。これは、データベースレビュアーがチェーンの前の段階で既に移行をゲートしているためである）。テストおよびビルドのステップは、それぞれ独自のバリデータ（e2e-runnerおよびビルド・リゾルバー）によってゲート制御されており、追加のレビュー担当者は必要ありません。

フェーズ3 — タスク記述の圧縮

出力される各 は、以下の条件を満たす必要があります：

• 自己完結していること（最初のエージェントがプラン文書を開いていなくてもよい）。
• [Plan:#step-] で始まること。
• 1～3つの検証可能な受け入れ基準を含めること。
• 計画書がこのステップに対してスコープガード（範囲外：...）を宣言している場合にのみ、それを含めること。その内容をそのまま継承すること。計画書に範囲外の記述がない場合は、その条項を完全に省略すること — 勝手に作成してはならない。
• 200～600 文字とし、1 行に収め、埋め込みの" は \" でエスケープし、リテラルな改行は含めないこと。

フェーズ 4 — 出力

ECC_MODEによって決定された形式を使用してMarkdownを出力する。 出力は一貫して1つの形式を使用する — すべての{ORCH_CMD}およびエージェント名は、フェーズ0で指定された対応するプレフィックス付きでレンダリングされる。両方の形式を出力してはならない。また、レンダリングされた出力に「これはプラグイン形式です」や「プレフィックスを削除する」といった指示を含めてはならない。

具体的なレンダリング規則：

• {ORCH_CMD}=プラグイン環境では/everything-claude-code:orchestrate、レガシー環境では/orchestrate。
• {AGENT(name)}=plugin 環境ではeverything-claude-code:、 レガシー環境では。
• 概要表の「Chain」列では、同じ{AGENT(name)}レンダリングを使用します。
• ステップごとのbashブロックには、実行可能なコマンドのみが含まれます。 # plugin形式や# legacy形式のコメントは含まれません。形式は暗黙的であり、出力全体を通じて統一されています。

出力の構造:

#Plan-Orchestrate の結果

**計画**: ``
**言語**: ``
**ECC モード**: ``
**ステップ**:
**スコープ**:

## ステップの概要

| # | タイトル | タグ | チェーン |
|---|---|---|---|
| 1 | ... | impl, db | `{AGENT(tdd-guide)},{AGENT(database-reviewer)},{AGENT(python-reviewer)}` |
| ... | | | |

---

## ステップ 1 —