• — 必填；可為相對路徑或絕對路徑（接受@docs/...格式）。
• --lang— 審查者語言變體；預設為auto（從專案中偵測）。
• --scope— 限制產出的步驟；預設為all。
• --dry-run— 僅輸出分解 + 鏈結理由；不輸出最終提示。

權威性/orchestrate格式（請勿偏離）

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

其中{ORCH_CMD}於第 0 階段確定（見下文）。發出的輸出中的命令字串始終採用一種具體形式——絕不同時使用兩種形式，也絕不使用佔位符。

• custom是一個順序鏈；每個代理的 HANDOFF 會傳遞給下一個。
• 以逗號分隔的代理清單。建議不要使用空格；允許出現一個空格。
• 不存在--mode/--gate/--agents=...等參數 — 切勿自行新增。
• 代理名稱取自此技能的目錄。任務描述中嵌入的雙引號會以\" 進行轉義。

ECC 安裝格式與命名空間

兩種安裝形式決定了斜線指令及每個代理名稱的前綴。這兩者必須保持同步——每種形式對應一種輸出，絕不可混用：

讓 表示 Claude Code 的主目錄：macOS/Linux 為~/.claude，Windows 為%USERPROFILE%\.claude。請依照主機平台解析使用者主目錄的方式進行解析（切勿硬編碼~）。

為何這很重要：在外掛程式安裝模式下，代理程式會以everything-claude-code:tdd-guide 進行註冊。純名稱會強制進行模糊比對，這在並行呼叫時會間歇性地失敗。在傳統模式下，帶前綴的形式不會被註冊，因此會直接失敗。

可用代理程式目錄（必須從中選擇）

一般類別：

• 規劃者— 需求重述、風險分解、步驟規劃
• architect— 架構、系統設計、重構提案
• tdd-guide— 編寫測試 → 實作 → 覆蓋率達 80% 以上
• 程式碼審查員— 一般程式碼審查
• 安全審查員— 安全稽核、OWASP、機密洩漏
• 重構清理員— 死碼、重複碼、knip 類別清理
• 文件更新員— 文件、程式碼映射、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/存在且包含至少一個 ECC 代理程式檔案（例如tdd-guide.md、code-reviewer.md）→ECC_MODE=legacy。
   3. 否則 → 預設為ECC_MODE=legacy，並在輸出頂端顯示一行警告：> 警告：無法偵測到 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是一個哨兵變數 — 它並非代理名稱。第二階段的規則 4 和 5 會在鏈組建時將其轉換為代碼審查者/建置錯誤解決者。

4. 偵測PyTorch 子配置檔：當lang=python且pyproject.toml/requirements.txt/uv.lock中的任何檔案宣告對torch 的依賴時，將pytorch 設為 true。這僅影響建置鏈的選取（參見下文第二階段規則）；審查者仍維持為python-reviewer。

5. 將計畫中宣告的任何代理名稱標準化：若計畫文字以帶有外掛程式前綴的形式引用代理（例如everything-claude-code:tdd-guide），則在驗證或組合鏈之前，移除前綴以取得原始目錄名稱。 根據ECC_MODE（第 4 階段），僅在輸出時才會重新添加前綴。切勿讓已添加前綴的名稱流入鏈組建流程——這會在外掛程式模式下導致前綴重複。

第 1 階段 — 分解步驟

依優先順序識別「步驟單位」：

1. 明確編號：## 步驟 N/### 階段 N/## N. .../ 頂層有序清單。
2. 表格中的「步驟」欄位。
3. ----以動詞開頭的標題分隔各區塊。
4. 否則將每個 H2 視為一個步驟。

針對每個步驟，萃取ID（從 1 開始計數）、標題（≤ 80 個字元）、意圖（1–3 句）及標籤。

第二階段 — 標籤與鏈選

根據意圖進行標籤標記（允許多標籤；標籤鏈由主要標籤 + 堆疊的次要標籤構成）：

以下觸發詞的匹配不區分大小寫。只要語義與列出的英文觸發詞一致，系統便會透過匹配任何語言的詞幹來支援多語言計畫。

鏈結組合規則：

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. 當 lang=unknown 時，-reviewer會解析為code-reviewer。
6. 當 `lang=unknown` 時，`-build-resolver`會解析為`build-error-resolver`。特殊情況：若第 0 階段設定了`pytorch=true`，則無論如何，建置鏈皆使用`pytorch-build-resolver`。不存在python-build-resolver；若未設定pytorch=true且使用--lang=python，則解析為build-error-resolver。
7. 零標籤步驟：若無觸發詞匹配，則將鏈設定為code-reviewer並註明「無標籤匹配」；預設在「鏈邏輯依據」下採用僅審查鏈。
8. 去重後鏈長 ≤ 4。若超過此限制，則捨棄最弱的標籤（優先捨棄「查詢」與「文件」）。
9. 請勿在實作鏈中將規劃者與架構師配對（浪費標籤）。僅在設計步驟中將其配對。
10. 標記為impl、refactor 或migration的步驟，必須以審查員類別的代理作為結尾——包括-reviewer、code-reviewer、security-reviewer 或database-reviewer 中的任何一種。 最符合領域特性的審查者將佔據尾端位置（例如：規則 2 的impl+security以security-reviewer 結尾；規則 3 的impl+db則以-reviewer結尾，因為database-reviewer已在鏈條較早階段對 migration 進行了閘門控制）。測試與 建置步驟由各自的驗證器（分別為e2e-runner和建置解析器）進行門控，無需額外的審查員。

第三階段 — 壓縮任務描述

每個發出的 必須：

• 具備自包含性（第一個代理程式無需開啟計畫文件）。
• 以[Plan:#step-] 開頭。
• 包含 1 至 3 項可驗證的驗收準則。
• 僅當計畫為此步驟宣告了範圍守護條件（範圍外：...）時，才需包含該守護條件。須逐字繼承。若計畫中未包含範圍外聲明，則應完全省略該條款——切勿自行編造。
• 字數須為 200–600 個字元；僅佔一行；嵌入的"須以\" 轉義；不得包含字面上的換行符。

第 4 階段 — 輸出

根據 ECC_MODE決定的格式輸出 Markdown。 輸出須貫徹單一格式 — 每個{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 | ... | 實作, 資料庫 | `{AGENT(tdd-guide)},{AGENT(database-reviewer)},{AGENT(python-reviewer)}` |
| ... | | | |

---

## 步驟 1 —