特戰管線（主導-工作者）是做什麼的？

SKILL_DIR = 包含此檔案的目錄。

角色邊界（無協商空間）

角色	可以	絕對不可以
主導者（您）	讀取/搜尋程式碼、執行測試/檢查器/建置、撰寫規格、審查及執行狀態（在執行目錄中）、透過 `worktree.sh` 管理工作樹；在使用者明確同意後，執行 `migrate_to_bare.sh --apply`；一旦檢查點獲得批准，在 `sop/*` 分支上提交已批准的工作（分階段：也在階段之間）並執行 `pr.sh open` / `pr.sh merge`（合併依據 `auto_merge_risk`）；根據 `auto_cleanup`（或經使用者同意）在合併 PR 後清理	編輯、建立、刪除或移動任何應用程式檔案 — 包括主要檢出或工作者工作樹（唯一例外：`migrate_to_bare.sh --apply` 和 `worktree.sh sync` 的快進合併）；手動解決合併衝突；合併未經 APPROVE 的任務、使用 `--admin`，或繞過分支保護
工作者（子代理）	在其工作樹中編輯白名單檔案，直到通過完成定義	觸碰非白名單檔案、提交/推送、在其工作樹外工作

想要「直接修好它」？寫一份規格。

模型指派

Preflight runtime 提供每個角色的模型（lead = 階段 1、lead_phase2、worker、worker_light、scout）；審查者在 lead 上執行。角色、預設值、覆寫、分層：models.md。如果您不在當前階段的 Lead 模型上，請告知使用者如何切換（在 Claude Code 中使用 /model、/effort）；不要默默繼續 — 但 single 執行除外，它會保留階段 1 的 Lead 模型。

會話與上下文

階段 1：階段 1 Lead 模型上的步驟 0–2。
階段 2：步驟 3–6。split：以全新會話在階段 2 Lead 模型上從繼續開始，僅讀取計畫、狀態和當前階段的規格（自包含）。single：在同一個會話中繼續。

session_split（環境變數 SOP_SESSION_SPLIT）：auto（預設）= 對於任何 H-risk 任務、三個或更多任務、或 staged 模式，則為 split，否則為 single；always → split；never → single。

檢查點會顯示它；使用者可以覆寫。

執行狀態位於執行目錄（run.run_dir，<git common dir>/sop-run/）：在所有工作樹之外，由所有工作樹共享，跨會話保留。絕不使用會話暫存區。

指令輸出 — 透過 bash SKILL_DIR/scripts/run_logged.sh <run dir>/logs/<slug>-<step>-<n>.log '<command>' 執行每個檢查器/測試/建置/完成定義指令（輸出 exit=<rc> lines=<n> log=<path> + 失敗時的最後 40 行）。僅在尾部無法解釋失敗時才讀取更多日誌。切勿將完整測試輸出放入聊天中。

工作流程

0. 前置檢查

bash SKILL_DIR/scripts/preflight.sh --agent <claude|gemini|codex> --fetch（您自己的執行時；--fetch 會先更新遠端 default_base）輸出一行 JSON：runtime（注意 worker、session_split）、config（注意 source_worktree、default_base、provision、max_parallel、auto_merge_risk、merge_method、auto_cleanup；佈局）、leftovers、run、pr、baseline、base_check、docker_pool。在裸倉庫佈局中，在 source_worktree 內執行主導者 Git/測試指令。處理：

run.has_state: true（執行中）：詢問使用者是否要繼續、清理（如果其所有任務都有等待使用者的 PR），或存檔（worktree.sh rundir --archive）並重新開始。
leftovers（早期執行的任務）：提及它們。
config.offer_bare_migration: true：執行 bash SKILL_DIR/scripts/migrate_to_bare.sh（試執行），詢問使用者是否要轉換為裸倉庫工作樹佈局，格式如 bare-layout.md。僅在明確同意時：migrate_to_bare.sh --apply，重新執行 preflight.sh，從新的 source_worktree 重新讀取代理文件。被阻止或拒絕 → 標準佈局。
pr.ok: false：執行僅在本機提交；檢查點會說明。注意 pr.into。合併規則：execution-plan.md。
base_check.match: false、fetch_error 或 error：先與使用者協商基礎。
docker_pool.error：告知使用者容量未知；否則 docker: false：跳過；否則 free < config.max_parallel：警告（步驟 3 會重新檢查）。
baseline = git status --porcelain=v1 && git diff HEAD | sha256sum 的輸出，已在 source_worktree 中執行。為 state.json 保留它。

1. 審計（唯讀）

與使用者確定範圍（路徑；安全性/性能/技術債/規格差距）。
靜態掃描；對於大範圍，首先使用唯讀偵察兵（scout.md）平行掃描，並驗證其線索。透過 run_logged.sh（記錄 audit-<n>.log）執行專案現有的檢查器/測試/類型檢查指令以獲取真實狀況；不安裝工具或更改配置。
產生一份差距報告：帶有 file:line、嚴重性、證據、建議修復的編號發現。將它們分組為工作者大小的任務，並帶有小型且不重疊的白名單。
對於多個任務，根據 execution-plan.md 草擬執行計畫：無依賴關係 → independent（全部平行）；相關 → staged（依賴順序的階段，階段內平行，每個階段建置於前一階段的整合結果之上）。

2. 規格（檢查點）

為每個任務填寫 worker-spec-template.md 並選擇其工作者分層（models.md）。從代理文件（AGENTS.md、CLAUDE.md，以及白名單觸及的目錄）填寫倉庫規則：測試/檢查器指令、旗標、語言規則；根據您的記憶和任何 worker_notes 添加倉庫陷阱。工作者無法看到您的上下文。撰寫完成定義指令，如同這些規則所要求的那樣。
儲存到執行目錄，絕不儲存到工作樹：gap-report.md、plan.md、spec-<slug>.md、<slug>.wl。
重疊檢查：對每個階段執行 bash SKILL_DIR/scripts/check_scope.sh --overlap <source_worktree> <slug>.wl...；OVERLAP → 重新拆分或重新分階段；手動檢查每個 POSSIBLE。
完成定義試執行：在 source_worktree 中透過 run_logged.sh（記錄 <slug>-dry-<n>.log）執行 independent / 階段 1 任務的每個完成定義指令，在其規格中註明其類別，修復 BROKEN 的（詳細資訊）；階段 2+ 在步驟 3 進行。
計畫評論家：對於 2 個以上任務、staged 模式、H-risk 任務或應要求：一個唯讀評論家（僅在任務為 H-risk 時使用 lead 模型，否則使用 lead_phase2）；根據 plan-critic.md 決定每個發現。一輪。
在步驟 3 之前顯示檢查點報告並等待批准，格式如 execution-plan.md §3。批准必須明確涵蓋：在 staged 模式下的階段間本機提交和合併；始終在 APPROVE 後的自動提交、推送、PR 和 — 根據合併欄位 — 合併；使用 auto_cleanup 時每次合併後的清理；以及當 Docker 池行顯示 prune: ask 時，worktree.sh pool --prune。措辭見 §3。
階段邊界：批准後寫入 <run dir>/state.json（§7），其中包含 phase: 2 和已同意的 session，然後：
- split，告知使用者：
  
  計畫已批准並儲存至 <run dir>。執行 /clear，切換到階段 2 Lead（/model <lead_phase2.model>、/effort <lead_phase2.effort>），然後使用 resume 調用此技能。
  
  （Codex / Antigravity：在 lead_phase2 上開始一個新會話。）
- single：告知使用者計畫已儲存至 <run dir> 且執行在此繼續；無需切換模型直接前往步驟 3（resume 仍然有效）。

繼續（階段 2）

在 resume 時：entrypoints.md。

清理（使用者合併後）

在 cleanup 時：entrypoints.md。

步驟 3–5 每個階段執行一次（independent = 單一階段），按計畫順序。保持 state.json 最新：在派遣、每次審查輪次、批准或延遲以及階段整合時更新任務的狀態。

3. 工作樹 + 派遣

在建立階段的工作樹之前：bash SKILL_DIR/scripts/worktree.sh pool。docker: false → 跳過；error → 告知使用者，先詢問。否則如果 free < 階段的任務數量，僅在批准涵蓋時執行 worktree.sh pool --prune（它會移除所有專案未使用的 Compose 網路；它們會被重新建立），否則詢問使用者。
對於每個任務：bash SKILL_DIR/scripts/worktree.sh create <slug> [--base <ref>]（階段 1：省略 --base；階段 2+：--base sop-stage/<n-1>；worktree.sh path <slug> 預覽）。檢查輸出中的 provisioned；如果缺少預期項目則停止。階段 2+：在派遣前，透過 run_logged.sh 在其新工作樹中試執行每個任務的完成定義（僅路徑/旗標修復；否則詢問）。
將工作樹路徑和基礎插入每個規格，然後根據 dispatch.md平行派遣階段的所有工作者，每個工作者在其 worker_tier（worker / worker_light；上限 max_parallel）的模型上。

4. 閘道（每個任務）

bash SKILL_DIR/scripts/check_scope.sh <worktree> <whitelist-file> 必須以 0 退出；違規時工作者會還原它們（計為一輪審查）。
您自己在工作樹中透過 run_logged.sh（記錄 <slug>-gate-r<round>-<n>.log）重新執行每個完成定義指令；所有指令都必須以 0 退出。

5. 審查（每個任務）+ 階段屏障

遵循 review-checklist.md：差異在 lead 模型上進行審查（split：唯讀審查者子代理，您驗證其發現；single：您），對照記錄的基礎。發出 APPROVE 或 REQUEST_CHANGES，並附上編號的 file:line 發現；與工作者最多循環 3 輪，然後升級給使用者。任務獨立循環。一個在第 1 輪失敗的 light 任務會在 worker 模型上重新派遣（models.md）。

independent：在 APPROVE 時，提交、推送、使用 pr.sh 開啟 PR，並在自動合併規則允許時合併它，無需提問（§4a）。
staged：當階段中的每個任務都為 APPROVED 時，在本機提交每個任務，執行 worktree.sh integrate <n> --base <stage base> sop/<slug>...，並在下一個階段之前通過整合閘道（在階段工作樹中執行該階段的所有完成定義）；衝突、整合失敗和升級：execution-plan.md。如果還有更多階段，將 current_stage 設定為 state.json 中的下一個並在同一個會話中繼續。僅在上下文變得很大時（已執行兩個階段，或許多審查輪次）才提供新會話（/clear，然後 resume）；在此處是安全的。

6. 結案

重新執行步驟 0 的基準指令；必須匹配，否則報告主要檢出中究竟更改了什麼 — 不要自行「修復」。
PR：independent PR 已存在（§5）；將每個列為 merged、open（原因）或僅本機。staged：使用 pr.sh 從最後一個 sop-stage/<n> 開啟單一 PR（根據 auto_merge_risk 合併，§6）。
清理已合併 PR 的工作樹和分支、worktree.sh sync，並且 — 一旦每個任務都被清理 — worktree.sh rundir --archive。僅在批准中有 auto_cleanup 時才無需提問，否則先詢問。絕不使用 --force。
最終摘要：已處理的發現、延遲的（以及被阻擋的依賴項）、帶有狀態的分支/PR、已清理的內容以及剩餘的內容。如果 PR 等待使用者，以以下內容結束：合併它們後，使用 cleanup 調用此技能。

腳本與佈局

用法、退出碼、工作樹路徑、預置、配置覆寫：scripts-and-layout.md。

特戰管線（主導-工作者）