計劃編排
將計劃文件橋接到 /orchestrate custom，為每個步驟產出一個可直接貼上的調用。此技能僅用於生成 — 它永遠不會執行 /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 中決定（見下方）。在輸出的命令字串中始終使用一種具體形式 — 絕不混合，也絕不使用佔位符。
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 風格清理doc-updater— 文件、程式碼地圖、READMEdocs-lookup— 第三方函式庫 API 查詢 (Context7)e2e-runner— 端到端測試編排database-reviewer— PostgreSQL schema、遷移、效能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 模式與語言
-
讀取
<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並在輸出頂部發出一行警告：> 警告：無法偵測到 ECC 安裝；將預設使用傳統形式。如果您使用附加元件安裝，請手動編輯前綴。 - 如果兩個標記都存在（混合安裝），
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. .../ 頂層有序列表。 - 表格中的「步驟」欄位。
---分隔的區塊，帶有動詞引導的標題。- 否則將每個 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，則無論<lang>為何，都為build鏈使用pytorch-build-resolver。不存在python-build-resolver；--lang=python且pytorch=true為false時解析為build-error-resolver。 - 零標記步驟：如果沒有觸發詞匹配，將鏈設定為
code-reviewer並在「鏈的設計理念」中寫入未匹配到標記；預設僅審查鏈。 - 去重後鏈長度 ≤ 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>。- 總覽表的「鏈」欄位使用相同的
{AGENT(name)}呈現。 - 每個步驟的 bash 程式碼區塊僅包含可執行的命令。沒有
# 附加元件形式或# 傳統形式註解 — 形式是隱含的，且整個輸出保持一致。
輸出結構：
# 計劃編排結果
**計劃**：`<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] <壓縮的任務描述>; Acceptance: <1–3 項>; Out of scope: <…>"
```
上述的
{ORCH_CMD}和{AGENT(...)}符號描述了此技能在執行時進行的替換。實際輸出的 Markdown 包含解析後的字串，絕不會包含佔位符。
在末尾附加一個「批次執行」區塊，按順序彙總每個步驟的命令，以便使用者一次貼上所有命令。在僅總覽模式下跳過批次區塊（請參閱「大型計劃」邊緣案例）：當僅產出總覽表時，沒有每個步驟的命令需要彙總。
階段 5 — 自我檢查（在產出前執行）
- 每個鏈中的每個代理都來自目錄（在剝離了計劃中出現的任何
ecc:前綴後；請參閱階段 0 步驟 5）。 - 解析後的
{ORCH_CMD}和每個解析後的{AGENT(...)}使用相同形式（plugin或legacy）— 在一個輸出中絕不混合。 - 呈現的輸出中沒有殘留
# 附加元件形式/# 傳統形式註解和「剝離前綴」的指示。 - 沒有發明的
--mode/--gate/--agents=...欄位。 - 每個任務描述是單行、雙引號包圍，內嵌的
"已轉義。 - 每個任務描述以
[Plan: <path>#step-<id>]開頭，並包含 Acceptance（1–3 項）。Out of scope:子句僅在從計劃繼承時出現。 - 任何鏈中沒有重複的代理（在階段 2 去重後）。
- 鏈長度 ≤ 4。
- 標記為
impl/refactor/migration的步驟以審查者類別代理結尾（-reviewer、code-reviewer、security-reviewer 或 database-reviewer）。 - 對於
scope=step:n：僅產出包含步驟 n 的區塊。對於scope=range:a-b：僅產出包含步驟 a 到 b 的區塊。總覽表會相應地進行過濾。 -
--dry-run：不產出 bash 指令碼區塊或批次區塊。輸出僅包含總覽表 + 每個步驟的設計理念（意圖、標記、鏈的設計理念作為純文字）。沒有壓縮的任務描述。 -
lang=unknown已正確處理：目錄輸出顯示unknown，總覽表鏈使用code-reviewer（或build-error-resolver），使用者在最後會收到一則通知：「> 注意：專案語言無法確定。審查和建置解析已回退為通用代理。請考慮使用--lang明確指定。」
邊緣案例
大型計劃（超過 12 個步驟）
當步驟總數超過 12 時，僅輸出總覽表（步驟 #、標題、標記、鏈）。省略每個步驟的詳細區塊和批次區塊。結尾處的訊息：> 偵測到大型計劃（<N> 個步驟）。每個步驟都有多個標記，由於篇幅限制，已省略詳細區塊。請使用 --scope=step:<n> 或 --scope=range:<a>-<b> 逐一請求步驟。。
無明確步驟
如果計劃文字使用散文而不是明確的第 1/2/3 步，請識別語義斷裂（主題、段落邊界）並為每個斷裂合成一個步驟。在輸出頂部包含一則通知：> 注意：未偵測到明確步驟編號。步驟是從語義斷裂推斷出來的 — 請驗證邊界是否匹配您的意圖。。
格式錯誤的計劃
如果計劃完全不可讀（語法亂碼、非文字二進位），回報：錯誤：無法解析計劃文件。請提供格式正確的 Markdown 或文字計劃。 並停止。
單一步驟計劃
即使只有一個步驟，也要繼續執行。這樣做可以將此技能作為一個統一的介面來使用，始終分解並通過 /orchestrate custom 執行，而不是手動 /orchestrate 一個鏈。
Out of scope 不匹配
如果 --scope=step:3，但步驟 3 的標記表示它是一個測試步驟（鏈 = tdd-guide,e2e-runner），則鏈是正確的。不要因為步驟 3 包含設計討論而覆蓋。標記總是勝過步驟編號。
路徑繞行
如果 <plan-doc-path> 是一個目錄（而不是單一文件），則按字母順序列出該目錄中的每個 .md 或 .txt 文件，並回報：<path> 是一個目錄。請指定一個計劃文件，而非目錄。可用的計劃文件：...。
在 plugin 模式下偵測到混合使用
如果在一個計劃中偵測到 ecc:agent-name 和 agent-name 的混合使用，將所有使用標準化為附加元件形式，對所有後續鏈使用 ecc:<name>，並在頂部發出：> 注意：在計劃文字中偵測到混合的代理引用（ecc: 前綴和非前綴）。為保持一致性，所有鏈都使用附加元件命名空間。。如果 ECC_MODE=legacy，則剝離所有 ecc: 前綴並在頂部發出：> 注意：在計劃文字中偵測到附加元件前綴 (ecc:)，但正在使用傳統安裝。已剝離前綴。。
變更建議
當使用者有 lang 或 scope 的偏好的時，希望技能引導他們使用 CLI 參數而不是片語。例如，使用者說「只做步驟 2」→ 用 --scope=step:2 回應；「這是 Python 專案」→ 用 --lang=python 回應。不要嘗試解釋使用者的偏好並無視參數。
範例
輸入
plan-orchestrate @docs/implementation-plan.md --lang=python --scope=step:3
輸出（附加元件 ECC 模式）
# 計劃編排結果
**計劃**：`@docs/implementation-plan.md`
**語言**：`python`
**ECC 模式**：`plugin`
**步驟數**：5
**範圍**：`step:3`
> 注意：未偵測到明確步驟編號。步驟是從語義斷裂推斷出來的 — 請驗證邊界是否匹配您的意圖。
## 步驟總覽
| # | 標題 | 標記 | 鏈 |
|---|---|---|---|
| 3 | 資料庫 schema 遷移 | db, impl | `ecc:tdd-guide,ecc:database-reviewer,ecc:python-reviewer` |
---
## 步驟 3 — 資料庫 schema 遷移
**意圖**：建立一個 Alembic 遷移來新增 `users` 表的 `last_login` 時間戳記。
**標記**：`db`, `impl`
**鏈的設計理念**：`tdd-guide` 驅動測試，`database-reviewer` 驗證 schema 和遷移安全性，`python-reviewer` 確保最終程式碼品質。
```bash
/ecc:orchestrate custom "ecc:tdd-guide,ecc:database-reviewer,ecc:python-reviewer" "[Plan: @docs/implementation-plan.md#step-3] 建立 Alembic 遷移，為 users 表新增 last_login 時間戳記。編寫遷移測試，確保向前相容性，並更新 ORM 模型。; Acceptance: (1) 遷移套用成功 (2) 測試通過 80%+ (3) 模型已更新; Out of scope: 效能基準測試"