Orchestrator Pipeline（共享引擎） 是做什麼的？
orch-* 技能是薄封裝層。它們不會重新實作任何工作，而是
分類請求、選擇此流程中要執行的階段，並將每個階段委派給
現有的 ECC 代理或指令。此檔案即為該流程。
請調用作業技能（
orch-add-feature、orch-fix-defect……）， 而非直接使用此引擎。此檔案是它們參考的基礎。
使用時機
- 每當
orch-*作業技能執行時間接載入。 - 僅在為家族新增作業或調整共享階段、閘門或代理對應表時直接閱讀。
作業家族
| 技能 | 作業 | 觸發條件 | 第一動作 |
|---|---|---|---|
orch-add-feature | feature | 功能尚未存在 | 研究 + 規劃新切面 |
orch-change-feature | tweak | 可運作但預期行為不同 | 修改既有行為及其測試 |
orch-fix-defect | fix | 故障；行為錯誤 | 以失敗測試重現，然後修正 |
orch-refine-code | refactor | 行為不變，結構改善 | 在維持測試綠燈下重構 |
orch-build-mvp | mvp | 從設計/規格文件啟動 | 擷取文件 → 垂直切面 |
這些封裝層組合現有 ECC 指令而非取代它們：
/feature-dev、/plan、/code-review、/build-fix、/refactor-clean及/gan-build，加上tdd-workflow技能。orch-* 家族在它們之上添加了共享 規模分類器和兩個閘門， 因此一個統一架構即可涵蓋全部五種作業。
步驟 0 — 分類規模（適度規模化）
儀式規模與影響範圍成正比。根據三個訊號對請求評分，取任何訊號達到的最高層級， 並以一行陳述結果，讓使用者可以覆寫：
| 層級 | 觸及檔案 | 新增相依/合約 | 設計模糊性 | 執行的階段 |
|---|---|---|---|---|
| trivial | 1 個檔案，幾行 | 無 | 無 — 變更顯而易見 | 4 → 5 → 6 |
| small | 1 個檔案 / 1 個函式 | 無 | 閱讀程式碼後即可釐清 | (1 輕量) → 4 → 5 → 6 |
| standard | 2–5 個檔案 | 可能有新的內部模組 | 需做一項實際決策 | 1 → 2 → 4 → 5 → 6 |
| large | 多個 / 跨層面 | 新的外部相依、公開 API 或規格文件 | 多個待解問題 | 1 → 2 → (3) → 4 → 5 → 6 |
階段 0（接收）永遠執行，且未列於上方遮罩欄中。 打破平手規則：任何觸及安全觸發條件（如下）或公開 API / 合約的事項 至少為 standard，無論檔案數量為何。
階段
每個階段皆為委派 — 不直接執行工作。
- 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. 提交 — conventional commits（
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/目錄下產出 PRD / architecture / system_design， 根據rules/common/development-workflow.md。 - 審查發現（CRITICAL / HIGH）必須在閘門 2 前解決。
驗證
- 規模層級已陳述並與工作相符
- 閘門 1（規劃）與閘門 2（提交）皆已遵守
security-reviewer僅在觸及安全觸發條件時執行- 提交為 conventional 格式且範圍限於單一邏輯變更
- 新增/變更行為有測試；覆蓋率 ≥ 80% 根據
rules/common/testing.md