需要在子代理委派中压缩工具输出、节省主上下文时，用…

当要把代码定位、1-2 文件小改或 diff 评审交给子代理，并希望返回值极简以延长主上下文时使用。

适用场景

解决思路

1. 把 Cavecrew 当作三个子代理预设使用：`cavecrew-investigator`（定位代码）、`cavecrew-builder`（1-2 文件编辑）、`cavecrew-reviewer`（diff 评审）；它们与 Anthropic 默认代理做同样的事，但返回的 tool result 被压缩。
2. 查找 `X` 定义、谁调用 `Y`、列出 `Z` 的用法时用 `cavecrew-investigator`。
3. 同样查找但还想要建议/架构评论时用 `Explore`（vanilla）。
4. 做外科手术式编辑、影响 ≤2 个文件、范围明确时用 `cavecrew-builder`。
5. 做新功能、涉及 3+ 文件或横切重构时用主线程或 `feature-dev:code-architect`。
6. 评审 diff、分支或文件以找 bug 时用 `cavecrew-reviewer`。
7. 做带理由和替代方案的深度代码评审时用 `Code Reviewer`（vanilla）。
8. 对已知答案的一行回答用主线程，不派子代理。
9. 选择规则：若希望子代理输出只有 1/3 token，选 cavecrew；若希望散文式输出，选 vanilla。
10. 利用主上下文收益：子代理 tool result 会原样注入主上下文；vanilla `Explore` 返回 2k tokens 时 `cavecrew-investigator` 约 700 tokens，多次委派可决定上下文是否耗尽。
11. 按 `cavecrew-investigator` 输出契约消费结果：`<Header>:` 后接 `- path:line — `symbol` — short note` 和 `totals: <counts>.`，或返回 `No match.`；始终文件路径优先、附行号、符号用反引号；可用 `path:\d+` 做 grep。
12. 按 `cavecrew-builder` 输出契约消费结果：`<path:line-range> — <change ≤10 words>. verified: <re-read OK | mismatch @ path:line>.` 或首 token 为 `too-big.` / `needs-confirm.` / `ambiguous.` / `regressed.` 之一。
13. 按 `cavecrew-reviewer` 输出契约消费结果：`path:line: <emoji> <severity>: <problem>. <fix>. totals: N🔴 N🟡 N🔵 N❓` 或 `No issues.`；findings 按 file → line 升序排序。
14. 常用链式模式 `Locate → fix → verify`：1) `cavecrew-investigator` 返回 site list；2) 主线程选 1-2 个 site，把 paths 交给 `cavecrew-builder`；3) `cavecrew-reviewer` 审计 diff。
15. 调查范围广时用并行侦察：在同一条消息里 spawn 2-3 个 `cavecrew-investigator` 调用（分别从 defs、callers、tests 等角度），在主线程聚合。
16. 已知 site 时用单次编辑：跳过 investigator，直接把精确 `path:line` 交给 `cavecrew-builder`。
17. 使用 auto-clarity：遇到安全警告、不可逆操作确认、或片段歧义可能被误读时，子代理从 caveman 输出切换为正常英文；之后再恢复 caveman。
18. 若输出会被人类直接阅读，主线程需把结构化、有时过于简略的 Cavecrew 输出转述成自然语言。

适用边界 · 注意事项

• 不知道文件时不要用 `cavecrew-builder`；先 spawn `cavecrew-investigator`，否则主线程会消耗大量 token 传递上下文。
• 不要为 5 文件重构链式调用 `cavecrew-investigator → cavecrew-builder`；builder 会返回 `too-big.`，浪费一轮。
• 不要向 `cavecrew-reviewer` 要 general feedback；它只返回 findings，不含架构意见；需要架构意见时用 `Code Reviewer`。