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

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つの形式のみを使用し、混在させないでください。

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

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

これが重要な理由：プラグインインストールでは、エージェントは 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インストール形式を検出し、一度決定した値を 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	アーキテクチャ、設計、選択、評価、RFC	planner,architect
plan	計画、ブレイクダウン、マイルストーン	planner
impl	実装、構築、追加、作成、移植	tdd-guide,<lang>-reviewer
test	テスト、カバレッジ、e2e、統合	tdd-guide,e2e-runner
refactor	リファクタリング、クリーンアップ、重複排除、分割	architect,refactor-cleaner,<lang>-reviewer
migration	移行、アップグレード、書き換え、移植	architect,tdd-guide,<lang>-reviewer
db	スキーマ、マイグレーション、インデックス、SQL、Postgres、alembic、sqlmodel	database-reviewer,<lang>-reviewer
security	暗号化、認証、シークレット、OWASP、PII	security-reviewer,<lang>-reviewer
build	ビルド、コンパイル、lint失敗、CI	<lang>-build-resolver（build-error-resolver にフォールバック）
docs	ドキュメント、readme、コードマップ、変更履歴	doc-updater
lookup	検索、リファレンス、API使用法	docs-lookup
review	レビュー、監査、検証	<lang>-reviewer,code-reviewer
loop	ループ、自律、ウォッチドッグ	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 は存在しません。pytorch=true なしの --lang=python は build-error-resolver に解決されます。
7. タグなしステップ: トリガーワードが一致しない場合、チェーンを code-reviewer に設定し、「チェーンの根拠」の下に「一致するタグがありません。デフォルトのレビューのみのチェーンです。」と書き込みます。
8. 重複排除後のチェーン長は4以下。超過した場合は、最も弱いタグ（最初に lookup、次に docs）を削除します。
9. planner と architect を impl チェーンでペアにしないでください（トークンの無駄）。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: <パス>#step-<id>] で始まること。
• 検証可能な1～3つの受け入れ基準（Acceptance criteria）を含むこと。
• 計画がこのステップに対してスコープガード（範囲外項目）を宣言している場合のみ、スコープガード（Out of scope: ...）を含めること。計画からそのまま継承します。計画に範囲外の記述がない場合は、この句を完全に省略します — 発明しないでください。
• 200～600文字であること。1行であること。埋め込まれた " は \" としてエスケープすること。リテラルの改行を含まないこと。

フェーズ4 — 出力

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

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

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

出力構造：

# Plan-Orchestrate 結果

**計画**: `<パス>`
**言語**: `<検出または指定された言語>`
**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つの出力内で混在させないこと。
• レンダリング出力に # プラグイン形式 / # レガシー形式 の注釈や「プレフィックスを削除してください」という指示が残っていないこと。
• 発明された --mode / --gate / --agents=... フィールドがないこと。
• 各タスク説明が1行、二重引用符で囲まれ、埋め込まれた " がエスケープされていること。
• 各タスク説明が [Plan: <パス>#step-<id>] で始まり、受け入れ基準（1～3項目）を含んでいること。Out of scope: 句は計画から継承した場合のみ存在すること。
• フェーズ2の重複排除後、どのチェーンにも重複するエージェントがないこと。
• チェーン長が4以下であること。
• impl/refactor/migration とタグ付けされたステップがレビュワークラスのエージェントで終わっていること（ルール10の通り）。
• 各bashブロックに実行可能なコマンドのみが含まれ、メタコメントがないこと。
• バッチ実行ブロック（該当する場合）が概要テーブルの直後、かつ各ステップのコマンドブロックの後に配置されていること。
• クリップボードに関する指示や「この行を貼り付けてください」といった自然言語の誘導がないこと — ユーザーは貼り付けるべきものを認識しています。

（…

[省略されました。翻訳対象外]