委派給穴居人風格子代理的決策指南。告訴主執行緒何時產生 `cavecrew-investigator`（定位程式碼）、`cavecrew-builder`（1-2 個檔案編輯）或 `cavecrew-reviewer`（差異審查），而不是內聯執行工作或使用一般的 `Explore`。子代理輸出經過穴居人壓縮，因此回傳到主脈絡的工具結果約縮小 60%——主脈絡在長時間工作階段中能撐更久。 觸發詞：「委派給子代理」、「使用 cavecrew」、「產生 investigator/builder/reviewer」、「節省脈絡」、「壓縮代理輸出」。
Cavecrew = 三個子代理預設，輸出穴居人風格的結果。與 Anthropic 預設（Explore、編輯型代理、審查者）功能相同；差異在於回傳的工具結果經過壓縮，因此每次委派都能減少主脈絡佔用。
何時使用 cavecrew 與替代方案
| 任務 | 使用 |
|---|---|
| 「X 定義在哪裡 / 誰呼叫 Y / 列出 Z 的使用處」 | cavecrew-investigator |
| 同上但還想要建議/架構評論 | Explore（一般） |
| 精準編輯，≤2 個檔案，範圍明確 | cavecrew-builder |
| 新功能 / 3 個以上檔案 / 跨領域重構 | 主執行緒或 feature-dev:code-architect |
| 審查差異、分支或檔案中的錯誤 | cavecrew-reviewer |
| 深度程式碼審查，附理由與替代方案 | Code Reviewer（一般） |
| 你已經知道答案的一行回覆 | 主執行緒，不使用子代理 |
經驗法則：如果你希望子代理的輸出只用 1/3 的 token，選 cavecrew。如果你希望有完整敘述，選一般版本。
為什麼存在（真正的優勢）
子代理的工具結果會原封不動注入主脈絡。一個回傳 2000 token 敘述的一般 Explore，每次耗費 2000 token 的主脈絡預算。同樣的發現來自 cavecrew-investigator 只回傳約 700 token。在一個工作階段中進行 20 次委派，這就決定了脈絡耗盡與完成任務的差別。
輸出合約
主執行緒可依賴每個代理的輸出格式：
cavecrew-investigator
<Header>:
- path:line — `symbol` — 簡短備註
totals: <計數>.
或 No match.。始終以檔案路徑開頭、附上行號、反引號括起符號。可用 path:\d+ 安全地 grep。
cavecrew-builder
<path:line-range> — <變更 ≤10 字>.
verified: <re-read OK | mismatch @ path:line>.
或其中之一：too-big. / needs-confirm. / ambiguous. / regressed.（終端第一個 token）。
cavecrew-reviewer
path:line: <emoji> <嚴重性>: <問題>. <修正>.
totals: N🔴 N🟡 N🔵 N❓
或 No issues.。發現按檔案 → 行號升序排列。
鏈式模式
定位 → 修正 → 驗證（最常見）：
cavecrew-investigator回傳位置列表。- 主執行緒挑選 1-2 個位置，將路徑交給
cavecrew-builder。 cavecrew-reviewer審查差異。
平行偵查（當調查範圍廣泛時）：
在單一訊息中產生 2-3 個 cavecrew-investigator 呼叫（不同角度：定義 vs 呼叫者 vs 測試）。在主執行緒中彙整。
單次編輯（當位置已知時）：
跳過 investigator。直接將精確的 path:line 交給 cavecrew-builder。
不該做的事
- 當你還不知道檔案時，不要使用
cavecrew-builder。先產生 investigator，否則主執行緒會浪費 token 傳遞脈絡。 - 不要為了 5 個檔案的重構而鏈式使用
cavecrew-investigator → cavecrew-builder。Builder 會回傳too-big.，浪費一次回合。 - 不要要求
cavecrew-reviewer提供「一般回饋」——它只回傳發現，沒有架構意見。請使用Code Reviewer來做這件事。 - 不要期待敘述。Cavecrew 輸出是結構化的，有時簡潔到難以理解。如果需要人類直接閱讀，請改寫。
自動清晰化（繼承）
子代理在安全警告、不可逆操作確認，以及任何片段可能造成誤解時，會從穴居人風格切換為正常英文。之後恢復穴居人風格。
