計劃編排器 是做什麼的？
將計劃文件橋接到 /orchestrate custom，為每個步驟發出一個可直接貼上的調用。此技能僅產生——它絕不執行 /orchestrate。使用者在準備好時貼上每一行。
何時啟用
- 使用者有一個多步驟計劃文件（PRD、RFC、實作計劃）並且希望透過
/orchestrate驅動它。 - 使用者說「編排這個計劃」、「為每個步驟提供 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>" "<task description>"
其中 {ORCH_CMD} 在第 0 階段決定（見下文）。發出的輸出中的命令字串始終使用一種具體形式——絕不兩者兼用，絕不使用佔位符。
custom是順序鏈；每個代理的 HANDOFF 會饋送給下一個。- 逗號分隔的代理清單。首選無空格；容忍一個空格。
- 不存在
--mode/--gate/--agents=...旗標——切勿發明。 - 代理名稱來自此技能中的目錄。任務描述中的嵌入式雙引號應轉義為
\"。
ECC 安裝形式和命名空間
兩種安裝形式決定斜線命令和每個代理名稱的前綴。兩者必須保持同步——每個輸出僅一種形式，絕不混合：
令 <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-class 清理doc-updater— 文件、程式碼映射、READMEdocs-lookup— 第三方函式庫 API 查詢 (Context7)e2e-runner— 端到端測試編排database-reviewer— PostgreSQL 架構、遷移、效能harness-optimizer— 本地代理 harness 配置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 模式 + 語言
-
讀取
<plan-doc-path>。如果遺失或為空，報告並停止。 -
偵測 ECC 安裝形式一次，並將其凍結為
ECC_MODE。演算法（按順序執行，在第一次匹配時停止）：- 如果
<claude-home>/plugins/marketplaces/ecc/存在 →ECC_MODE=plugin。 - 否則如果
<claude-home>/agents/存在且包含至少一個 ECC 代理檔案（例如tdd-guide.md、code-reviewer.md）→ECC_MODE=legacy。 - 否則 → 預設為
ECC_MODE=legacy並在輸出頂部發出一行警告：> Warning: could not detect ECC install; defaulting to legacy form. If you use the plugin install, edit the prefixes manually. - 如果兩個標記都存在（混合安裝），
plugin獲勝——外掛程式命名空間是唯一能在沒有模糊匹配的情況下解析代理名稱的命名空間。
從這一刻起，發出的每一行都使用斜線命令和每個代理名稱上的匹配前綴。切勿在同一個輸出中發出兩種形式。
- 如果
-
解析
--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。
- 探測標記：
-
偵測 PyTorch 子設定檔：當
lang=python且pyproject.toml/requirements.txt/uv.lock中的任何一個宣告了對torch的依賴時，設定pytorch=true。這只會影響build鏈的選擇（下面的第 2 階段規則）；審查員仍為python-reviewer。 -
正規化計劃中宣告的任何代理名稱：如果計劃文字引用帶外掛程式前綴形式的代理（例如
ecc:tdd-guide），請在驗證或組合鏈之前剝離前綴，以取得裸目錄名稱。重新加上前綴僅在輸出時根據ECC_MODE（第 4 階段）進行。絕不要讓預先加上前綴的名稱流入鏈組合——這會在外掛程式模式下導致雙重前綴。
第 1 階段 — 分解步驟
按優先順序識別「步驟單元」：
- 明確編號：
## Step N/### Phase N/## N. .../ 頂層有序清單。 - 表格中的「Step」欄。
---分隔的區塊，帶有動詞開頭的標題。- 否則將每個 H2 視為一個步驟。
每個步驟提取 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 |
鏈組合規則：
- 主要標記選擇：當一個步驟匹配多個標記時，表格順序中的第一個（表格頂部 = 最高優先順序）是主要標記；其餘的是次要標記。下面的組合規則 2 和 3 明確處理特定的多標記組合；否則，按標記表格順序附加次要鏈。
impl+security→tdd-guide,<lang>-reviewer,security-reviewer。impl+db→tdd-guide,database-reviewer,<lang>-reviewer。- 去重結果鏈（保留首次出現）。例如，
review+lang=unknown會在規則 5 之後產生code-reviewer,code-reviewer；去重將其折疊為code-reviewer。 - 當
lang=unknown時，<lang>-reviewer解析為code-reviewer。 - 當
lang=unknown時，<lang>-build-resolver解析為build-error-resolver。特殊情況：如果第 0 階段設定了pytorch=true，則對build鏈使用pytorch-build-resolver，無論<lang>為何。沒有python-build-resolver；--lang=python但沒有pytorch=true時解析為build-error-resolver。 - 零標記步驟：如果沒有觸發詞匹配，將鏈設為
code-reviewer，並在「鏈原理」下寫入no tag matched; default review-only chain。 - 去重後鏈長度 ≤ 4。如果超過，則丟棄最弱的標記（先丟棄
lookup和docs）。 - 不要在
impl鏈中配對planner和architect（浪費 token）。僅在design步驟上配對它們。 - 標記為
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 階段 — 壓縮任務描述
每個發出的 <task description> 必須：
- 是自包含的（第一個代理不需要開啟計劃文件）。
- 以
[Plan: <path>#step-<id>]開頭。 - 包含 1–3 個可驗證的驗收標準。
- 僅當計劃為此步驟宣告了範圍保護時，才包含範圍保護（
Out of scope: ...）。逐字繼承。如果計劃沒有超出範圍的陳述，則完全省略該子句——不要發明一個。 - 長度為 200–600 個字元；單行；嵌入式
"轉義為\"；沒有文字換行。
第 4 階段 — 輸出
使用 由 ECC_MODE 決定的形式 發出 Markdown。輸出從頭到尾使用一種形式——每個 {ORCH_CMD} 和每個代理名稱都使用第 0 階段的匹配前綴進行渲染。不要發出兩種形式；不要在渲染的輸出中包含「這是外掛程式形式」/「剝離前綴」的說明。
具體渲染規則：
{ORCH_CMD}= 在plugin下為/ecc:orchestrate，在legacy下為/orchestrate。{AGENT(name)}= 在plugin下為ecc:<name>，在legacy下為<name>。- 概覽表的「Chain」欄使用相同的
{AGENT(name)}渲染。 - 每個步驟的 bash 區塊僅包含可執行的命令。沒有
# plugin form或# legacy form註釋——形式是隱含的，並且在整個輸出中保持一致。
輸出結構：
# Plan-Orchestrate Result
**Plan**: `<path>`
**Lang**: `<detected-or-given>`
**ECC mode**: `<plugin | legacy>`
**Steps**: <N>
**Scope**: <all | step:n | range:a-b>
## Steps overview
| # | Title | Tags | Chain |
|---|---|---|---|
| 1 | ... | impl, db | `{AGENT(tdd-guide)},{AGENT(database-reviewer)},{AGENT(python-reviewer)}` |
| ... | | | |
---
## Step 1 — <title>
**Intent**: <1–3 sentences>
**Tags**: <a, b>
**Chain rationale**: <why this chain; which agent closes the loop>
```bash
{ORCH_CMD} custom "{AGENT(tdd-guide)},{AGENT(database-reviewer)},{AGENT(python-reviewer)}" "[Plan: docs/foo.md#step-1] <compressed task description>; Acceptance: <1–3 items>; Out of scope: <…>"
```
上面的
{ORCH_CMD}和{AGENT(...)}標記描述了此技能在執行時執行的替換。實際發出的 Markdown 包含解析後的字串，絕不包含佔位符。
附加一個最終的「Batch execution」區塊，按順序聚合每個步驟的命令，以便使用者可以一次全部貼上。在僅概覽模式下跳過 Batch 區塊（請參閱「大型計劃」邊緣情況）：當僅發出概覽表時，沒有每個步驟的命令可以聚合。
第 5 階段 — 自我檢查（在發出前執行）
- 每個鏈中的每個代理都來自目錄（在剝離計劃中出現的任何
ecc:前綴後；請參閱第 0 階段步驟 5）。 - 解析後的
{ORCH_CMD}和每個解析後的{AGENT(...)}使用相同形式（plugin或legacy）——絕不在一個輸出中混合。 - 渲染的輸出中沒有
# plugin form/# legacy form註釋，也沒有「剝離前綴」的說明。 - 沒有發明的
--mode/--gate/--agents=...欄位。 - 每個任務描述都是單行、雙引號括起來，且嵌入式
"已轉義。 - 每個任務描述以
[Plan: <path>#step-<id>]開頭，並包含 Acceptanc（1–3 個項目）。僅在從計劃繼承時才存在Out of scope:子句。 - 在第 2 階段去重後，任何鏈中都沒有重複的代理。
- 鏈長度 ≤ 4。
- 標記為
impl/refactor/migration的步驟以審查員類代理（<lang>-reviewer、code-reviewer、security-reviewer或database-reviewer）結尾。test和build步驟由其各自的驗證器（e2e-runner和建置解析器）守門，並且不需要附加審查員。
邊緣情況
沒有明確步驟
如果計劃沒有明確的編號步驟（例如它是一個連續的散文文件）：
- 按段落或 H2 邊界劃分。
- 將每個區塊視為一個步驟，並照常標記。
- 在頂部寫一條註釋：
Plan has no explicit step structure; inferred steps from section boundaries.
大型計劃（> 12 個步驟）
當步驟數超過 12 時：
- 始終設定
--dry-run（如果尚未設定的話）。 - 僅發出概覽表。不要發出每個步驟的 bash 區塊。
- 在概覽表下方新增一節：
## Truncated output This plan has <N> steps. Rerun with `--scope=step:<n>` or `--scope=range:<a>-<b>` to emit per-step prompts for a specific subset. - 跳過 Batch execution 區塊。
混合安裝
當同時存在外掛程式和舊版目錄時，plugin 獲勝。使用外掛程式的 {ORCH_CMD} 和 {AGENT(...)} 渲染每一行。不要發出混合形式。
多語言計劃
可以檢測用於標記觸發詞的語言。支援任何語言的計畫文檔，只要步驟意圖與標記表（例如「implementar」、「concevoir」、「テスト」）中列出的英文觸發詞一致。觸發詞比對基於詞幹，不區分大小寫。
深度巢狀計劃
某些計劃（RFC 或遷移指南）具有 ## Step N / ### Sub-step 結構。將每個 H3 子步驟提升為一個頂層步驟，但保留其父步驟編號作為標籤。例如 ### Step 1.3 — Migrate ORM 在概覽表中呈現為 1.3。不要降低巢狀層級——每個子步驟獲得自己的鏈和 bash 區塊。
包含幻燈片投影片的計劃
某些計劃文件每張幻燈片包含一個步驟。透過下列方式偵測：
---分隔線後面緊跟著幻燈片編號註釋，例如<!-- slide 4 -->。- 或者具有類
slide的 HTML<section>元素。
將每個幻燈片視為一個步驟，並從幻燈片內容中提取意圖。在每一步的 ## Step N 標題中使用「幻燈片」而不是「步驟」（例如 ## Slide 2 — Architecture）。適用於所有其他規則。
限制
- 不發現徽標或瀏覽器——僅文字。圖片容器被跳過。
- 如果不存在相應的 ECC 代理，則無法處理資料管道、Kubernetes 清單或基礎設施即程式碼步驟。鏈將回退到
code-reviewer。 - 大型計劃被截斷為僅概覽（第 2 階段規則 8 強制執行總鏈長度限制）。
提示
讓使用者知曉輸出格式並鼓勵回饋：
I've decomposed your plan into steps. Each bash block below is a ready-to-paste
/orchestrate custominvocation. Paste the one you want to run now, or paste all of them in sequence from the Batch section at the bottom.
如果使用 --dry-run，改為說：
Dry-run mode. Below is the decomposition and chain rationale only. No executable commands were emitted. Re-run without
--dry-runto get paste-ready blocks.