プラン・オーケストレート

Plan Orchestrate

プラン文書を /orchestrate custom に橋渡しし、各ステップに対してすぐに貼り付け可能な呼び出しを1つずつ出力します。このスキルは生成のみを行い、/orchestrate を実行することはありません。ユーザーは各コマンドを準備ができた時点で貼り付けます。

いつアクティブにするか

• ユーザーが複数ステップの計画文書（PRD、RFC、実装計画）を持ち、それを /orchestrate で実行したい場合。
• ユーザーが「この計画をオーケストレートして」「各ステップのオーケストレートプロンプトを出して」「この計画用のチェーンを構成して」と言った場合。
• ステップバイステップの計画は存在するが、ユーザーが各ステップのエージェントを手動で選択したくない場合。

以下の場合はスキップ：

• 作業が単一のアドホックステップである場合 → /orchestrate custom を直接呼び出します。
• 計画が読めない、または空の場合。明示的な番号がないだけではスキップ条件にはなりません — 以下の「明確なステップがない」エッジケースを参照。

入力

<plan-doc-path> [--lang=python|typescript|go|rust|cpp|java|kotlin|flutter|auto] [--scope=all|step:<n>|range:<a>-<b>] [--dry-run]

• <plan-doc-path> — 必須。相対パスまたは絶対パス（@docs/... も可）。
• --lang — レビュアーの言語バリアント。デフォルトは auto（プロジェクトから自動検出）。
• --scope — 出力するステップを制限。デフォルトは all。
• --dry-run — 分解とチェーン設計の根拠のみを表示。最終プロンプトは出力しない。

信頼できる /orchestrate の形式（逸脱しないこと）

{ORCH_CMD} custom "<agent1>,<agent2>,...,<agentN>" "<タスク説明>"

ここで {ORCH_CMD} はフェーズ0で決定されます（以下参照）。出力されるコマンド文字列は常に1つの具体的な形式を使用します — 両方の形式を混在させたり、プレースホルダーを使用したりしないでください。

• custom は連続チェーンです。各エージェントの HANDOFF が次のエージェントに渡されます。
• カンマ区切りのエージェントリスト。スペースなしが推奨ですが、1つのスペースは許容されます。
• --mode / --gate / --agents=... フラグは存在しません — 絶対に発明しないでください。
• エージェント名はこのスキルのカタログから取得します。タスク説明内の二重引用符は \" でエスケープします。

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

2つのインストール形式によって、スラッシュコマンドとすべてのエージェント名の両方のプレフィックスが決まります。この2つは同期している必要があります — 1回の出力につき1つの形式のみを使用し、混在させないでください：

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

形式	検出方法	{ORCH_CMD}	エージェント名の形式
プラグインインストール (2.0.0+)	<claude-home>/plugins/marketplaces/ecc/ が存在する	/ecc:orchestrate	ecc:<name>
レガシー素インストール	上記が存在せず、<claude-home>/agents/ 以下にエージェントファイルがある	/orchestrate	<name>

これが重要な理由：プラグインインストールでは、エージェントは ecc:tdd-guide として登録されます。ベア名は曖昧一致を強制し、並列呼び出し時に断続的に失敗します。レガシーでは、プレフィックス付きの形式は登録されておらず、そのまま失敗します。

利用可能なエージェントカタログ（これらから選択すること）

汎用：

• planner — 要件の再記述、リスク分解、ステップ計画
• architect — アーキテクチャ、システム設計、リファクタ提案
• tdd-guide — テスト作成 → 実装 → 80%以上のカバレッジ
• code-reviewer — 汎用コードレビュー
• security-reviewer — セキュリティ監査、OWASP、秘密情報漏洩
• refactor-cleaner — デッドコード、重複、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. <plan-doc-path> を読み取ります。存在しないか空の場合は、報告して停止します。

2. ECCのインストール形式を1回検出し、ECC_MODE に固定します。アルゴリズム（順に実行し、最初に一致したもので停止）：

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

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

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が、チェーン構成時に code-reviewer / build-error-resolver に変換します。

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

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

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

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

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

各ステップについて、id（1始まり）、title（80文字以内）、intent（1〜3文）、tags を抽出します。

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

意図に基づいてタグ付け（複数タグ可。チェーンはプライマリ + スタックされたセカンダリから構築）：

以下のトリガーワードは大文字小文字を区別せずに一致します。多言語計画は、意味がリストされた英語のトリガーワードと一致する限り、任意の言語の語幹に一致することでサポートされます。

タグ	トリガーワード	デフォルトチェーン
design	architecture, design, choose, evaluate, RFC	planner,architect
plan	plan, breakdown, milestone	planner
impl	implement, build, add, create, port	tdd-guide,<lang>-reviewer
test	test, coverage, e2e, integration	tdd-guide,e2e-runner
refactor	refactor, cleanup, dedupe, split	architect,refactor-cleaner,<lang>-reviewer
migration	migrate, upgrade, rewrite, port	architect,tdd-guide,<lang>-reviewer
db	schema, migration, index, SQL, Postgres, alembic, sqlmodel	database-reviewer,<lang>-reviewer
security	encrypt, auth, secret, OWASP, PII	security-reviewer,<lang>-reviewer
build	build, compile, lint failure, CI	<lang>-build-resolver（build-error-resolver にフォールバック）
docs	docs, readme, codemap, changelog	doc-updater
lookup	lookup, reference, API usage	docs-lookup
review	review, audit, verify	<lang>-reviewer,code-reviewer
loop	loop, autonomous, watchdog	loop-operator

チェーン構成ルール：

1. プライマリタグの選択: ステップが複数のタグに一致する場合、テーブル順で最初のもの（テーブルの先頭 = 最も優先度が高い）がプライマリ、残りはセカンダリです。以下のルール2と3が特定の複数タグの組み合わせを明示的に処理し、それ以外の場合はセカンダリチェーンをタグテーブル順に追加します。
2. impl + security → tdd-guide,<lang>-reviewer,security-reviewer。
3. impl + db → tdd-guide,database-reviewer,<lang>-reviewer。
4. 結果のチェーンから重複を削除（最初の出現を保持）。例：review + lang=unknown はルール5の後で code-reviewer,code-reviewer になりますが、重複削除により code-reviewer にまとめられます。
5. <lang>-reviewer は lang=unknown の場合 code-reviewer に解決されます。
6. <lang>-build-resolver は lang=unknown の場合 build-error-resolver に解決されます。特殊ケース: フェーズ0で pytorch=true が設定された場合、build チェーンには <lang> に関係なく pytorch-build-resolver を使用します。python-build-resolver は存在しません。--lang=python で pytorch=true がない場合は build-error-resolver に解決されます。
7. タグなしステップ: トリガーワードが一致しない場合、チェーンを code-reviewer に設定し、「チェーン根拠」に「タグが一致しませんでした。デフォルトのレビューのみのチェーン」と書き込みます。
8. 重複削除後のチェーン長は4以下。超過した場合は、最も弱いタグ（lookup と docs が先）を削除します。
9. impl チェーンで planner と architect をペアにしないでください（トークンの無駄）。design ステップでのみペアにします。
10. impl、refactor、または migration とタグ付けされたステップは、レビュアークラスのエージェント（<lang>-reviewer、code-reviewer、security-reviewer、database-reviewer のいずれか）で終了します。最もドメイン固有のレビュアーが末尾の位置を獲得します（例：ルール2の impl+security は security-reviewer で終了。ルール3の impl+db は <lang>-reviewer で終了。これは database-reviewer がチェーンの前半でマイグレーションをゲートするため）。test および build ステップは、それぞれ独自のバリデーター（e2e-runner およびビルドリゾルバー）でゲートされており、追加のレビュアーは必要ありません。

フェーズ3 — タスク説明の圧縮

出力される各 <タスク説明> は以下を満たす必要があります：

• 自己完結型であること（最初のエージェントは計画文書を開いている必要はありません）。
• [Plan: <path>#step-<id>] で始まること。
• 検証可能な1〜3つの受入基準を含むこと。
• 計画がこのステップに対してスコープガードを宣言している場合にのみ、スコープガード（対象外: ...）を含むこと。そのまま継承します。計画に対象外の記述がない場合は、節全体を省略します — 発明しないでください。
• 200〜600文字であること。1行であること。埋め込み " は \" としてエスケープすること。リテラルの改行を含まないこと。

フェーズ4 — 出力

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

具体的なレンダリングルール：

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

出力構造：

# Plan-Orchestrate 結果

**計画**: `<path>`
**言語**: `<検出または指定されたもの>`
**ECCモード**: `<plugin | legacy>`
**ステップ数**: <N>
**範囲**: <all | step:n | range:a-b>

## ステップ概要

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

---

## ステップ1 — <タイトル>

**意図**: <1〜3文>
**タグ**: <a, b>
**チェーン根拠**: <このチェーンの理由。どのエージェントがループを閉じるか>

```bash
{ORCH_CMD} custom "{AGENT(tdd-guide)},{AGENT(database-reviewer)},{AGENT(python-reviewer)}" "[Plan: docs/foo.md#step-1] <圧縮されたタスク説明>; 受入: <1〜3項目>; 対象外: <…>"
```

上記の {ORCH_CMD} および {AGENT(...)} 表記は、このスキルが実行時に行う置換を説明しています。実際に出力されるMarkdownには、解決された文字列が含まれ、プレースホルダーは含まれません。

すべてのステップのコマンドを順にまとめた「一括実行」ブロックを最後に追加します。これにより、ユーザーはすべてを一度に貼り付けることができます。概要のみのモード（以下の「大規模計画」エッジケースを参照）では「一括実行」ブロックをスキップします。概要テーブルのみが出力される場合、集約するステップごとのコマンドはありません。

フェーズ5 — 自己チェック（出力前に実行）

• すべてのチェーン内のすべてのエージェントがカタログからのものであることを確認（計画内に現れた ecc: プレフィックスを削除した後。フェーズ0のステップ5を参照）。
• 解決された {ORCH_CMD} とすべての解決された {AGENT(...)} が同じ形式（plugin または legacy）を使用していることを確認 — 1つの出力内で混在させない。
• レンダリングされた出力に # plugin形式 / # legacy形式 の注釈や「プレフィックスを削除」の指示が残っていないことを確認。
• 発明された --mode / --gate / --agents=... フィールドがないことを確認。
• 各タスク説明が1行で、二重引用符で囲まれ、埋め込み " がエスケープされていることを確認。
• 各タスク説明が [Plan: <path>#step-<id>] で始まり、受入基準（1〜3項目）を含んでいることを確認。対象外: 節は、計画から継承された場合にのみ存在する。
• フェーズ2の重複削除後、どのチェーンにも重複するエージェントがないことを確認。
• チェーン長が4以下であることを確認。
• impl/refactor/migration とタグ付けされたステップがレビュアークラスのエージェントで終了していることを確認。

…（翻訳のため省略）