協調器管道（共享引擎）
orch-* 技能是輕量級包裝器。它們不會重新實作任何工作——它們會
對請求進行分類，選擇這個管道執行的階段，
並將每個階段委派給現有的 ECC 代理或指令。這個檔案就是這個管道。
請調用作業技能（
orch-add-feature、orch-fix-defect……）， 而不是直接調用這個引擎。這個檔案是它們所指的參考。
使用時機
- 每當
orch-*作業技能執行時，間接載入。 - 只有在為系列新增作業或調整共享階段、閘門或代理對應時，才直接閱讀。
作業系列
| 技能 | 作業 | 觸發條件 | 第一步 |
|---|---|---|---|
orch-add-feature | 功能 | 能力尚不存在 | 研究 + 規劃一個新切片 |
orch-change-feature | 調整 | 功能可運作，但期望的行為不同 | 修改現有行為及其測試 |
orch-fix-defect | 修正 | 功能損壞；行為錯誤 | 重現為失敗的測試，然後修正 |
orch-refine-code | 重構 | 行為保持不變，結構改進 | 重組程式碼，同時保持測試通過 |
orch-build-mvp | MVP | 從設計/規格文件引導 | 讀入文件 → 垂直切片 |
這些包裝器組合現有的 ECC 指令，而不是取代它們：
/feature-dev、/plan、/code-review、/build-fix、/refactor-clean和/gan-build，以及tdd-workflow技能。orch-*系列在其之上增加了共享的 規模分類器和兩個閘門， 因此一個傘狀結構涵蓋了所有五個作業，保持一致。
第 0 步 —— 分類規模（適度調整）
程序規模與影響範圍成正比。根據三個信號對請求進行評分，取任何信號達到的最高 級別，並在一行中陳述結果，以便使用者可以覆寫：
| 級別 | 觸及的檔案 | 新的依賴項/合約 | 設計模糊性 | 執行的階段 |
|---|---|---|---|---|
| 瑣碎 | 1 個，幾行程式碼 | 無 | 無 —— 變更是顯而易見的 | 4 → 5 → 6 |
| 小型 | 1 個檔案 / 1 個函式 | 無 | 閱讀程式碼後很明確 | (1 輕量) → 4 → 5 → 6 |
| 標準 | 2–5 個檔案 | 可能是新的內部模組 | 需要做出一個實際的選擇 | 1 → 2 → 4 → 5 → 6 |
| 大型 | 多個 / 橫切 | 新的外部依賴項、公開 API 或規格文件 | 多個未解決的問題 | 1 → 2 → (3) → 4 → 5 → 6 |
第 0 階段（接收）始終執行，並從上面的遮罩欄中省略。 打破平局規則：任何涉及安全觸發器（如下）或公開 API / 合約的內容至少是標準級別，無論檔案數量多少。
階段
每個階段都進行委派 —— 不會內聯執行工作。
- 0. 接收 —— 重新陳述請求。對於
orch-build-mvp，讀取規格/設計文件並提取範圍、已鎖定的決策和功能列表。 - 1. 研究與重用 —— 按照
rules/common/development-workflow.md：gh search repos/gh search code，然後是 Context7 / 廠商文件，然後是套件註冊表，然後是 Exa。優先採用經過驗證的實作，而不是全新程式碼。 - 2. 規劃 —— 委派給
planner代理（或architect/code-architect以進行結構性決策）。輸出一個按薄垂直切片排序的task_list。→ 閘門 1。 - 3. 搭建 —— 僅限
orch-build-mvp：建立第一個端到端切片。 - 4. 實作（TDD） —— 透過
tdd-guide代理（或tdd-workflow技能）驅動每個任務： 紅 → 綠 → 重構。遵守作業的第一步規則。 - 5. 審查 ——
code-reviewer代理 //code-review。每當變更差異觸及安全觸發器（如下）時，加入security-reviewer。 - 6. 提交 —— 常規提交（
feat:/fix:/refactor:/ …），每個邏輯區塊一個。→ 閘門 2。
兩個閘門
這個系列是受閘門控制，而非自主執行：
- 閘門 1 —— 規劃後。 顯示
task_list；在使用者批准之前，不要撰寫實作程式碼。 - 閘門 2 —— 提交前。 顯示變更差異摘要和建議的訊息；在使用者確認之前，不要提交。
兩個閘門之間的一切會不間斷地流動。
代理 / 指令對應
| 階段 | 主要 | 備用 / 升級 |
|---|---|---|
| 接收 / 理解 | code-explorer | 在調整、修正或重構之前追蹤現有路徑 |
| 規劃 | planner | architect、code-architect 用於結構性呼叫 |
| 實作 | tdd-guide（或 tdd-workflow 技能） | build-error-resolver / /build-fix 用於建置中斷 |
| 審查 | code-reviewer / /code-review | 語言審查員（python-reviewer、typescript-reviewer……） |
| 安全 | security-reviewer | — |
| MVP 內部循環 | /gan-build "<簡述>" --skip-planner | 驅動 gan-generator → gan-evaluator；調整 --max-iterations / --pass-threshold |
將語言審查員與儲存庫配對（請參閱儲存庫本身的 CLAUDE.md）。
安全審查觸發器
當變更差異觸及以下任何一項時，引入 security-reviewer：驗證或授權、使用者輸入處理、資料庫查詢、檔案系統路徑、外部 API 呼叫、加密或秘密/憑證。（根據 rules/common/security.md。）
交接工件
管道不攜帶隱藏狀態 —— 規劃文件就是交接文件：
task_list（來自規劃）驅動實作循環。- 較大的工作也可能在儲存庫的
docs/下，根據rules/common/development-workflow.md輸出 PRD / 架構 / 系統設計。 - 審查結果（CRITICAL / HIGH）必須在閘門 2 之前解決。
驗證
- 規模等級已被陳述並與工作相符
- 閘門 1（規劃）和閘門 2（提交）都已遵守
- 當且僅當觸及安全觸發器時，
security-reviewer已執行 - 提交是常規的，且範圍限定在一個邏輯變更
- 新的/變更的行為有測試；根據
rules/common/testing.md，覆蓋率 ≥ 80%