用原始人压缩输出的子代理节省长会话上下文：调查/编辑/审查三…

在长会话中把代码定位、1-2 文件小改、diff 审查委派给输出压缩的子代理，可让回注主上下文的 tool-result 缩小约 60%，避免上下文耗尽。

适用场景

解决思路

1. 按任务选代理：问「X 定义在哪 / 谁调用 Y / Z 的全部用法」用 genshijin-investigator；同样问题但还要架构讲解或建议则用 vanilla Explore；范围明确、≤2 文件的精准编辑用 genshijin-builder；新功能、3+ 文件或跨切面重构留在主线程或用 feature-dev:code-architect；diff/branch/file 的 bug 审查用 genshijin-reviewer；需要带理由和备选方案的深度代码审查用 vanilla Code Reviewer；一行就能答完的确定内容直接在主线程做，不必起子代理。
2. 判断标准：希望子代理输出只占约 1/3 token 就用 genshijin-crew，希望是散文式输出就用 vanilla。
3. 依赖各代理的输出契约：genshijin-investigator 返回 `<Header>:` 加 `- path:line — `symbol` — short note` 列表和 `集計: <counts>。`，或 `No match.`，文件路径必须在前、带行号、符号用反引号，可用 `path:\d+` grep；genshijin-builder 返回 `<path:line-range> — <change ≤10語>。` 加 `verified: <re-read OK | mismatch @ path:line>。`，或以 `too-big.` / `needs-confirm.` / `ambiguous.` / `regressed.` 作为首 token 终止；genshijin-reviewer 返回 `path:line: <emoji> <severity>: <問題>. <修正>.` 加 `totals: N🔴 N🟡 N🔵 N❓`，或 `No issues.`，按文件再按行升序。
4. 用「定位 → 修改 → 验证」链（最常用）：先用 genshijin-investigator 拿到 site list，主线程挑 1-2 个 site 把路径交给 genshijin-builder，再用 genshijin-reviewer 审查 diff。
5. 调查面很广时用并行侦察：在一条消息里并行起 2-3 个 genshijin-investigator，从不同角度（定义 vs 调用方 vs 测试）调查，在主线程汇总。
6. site 已知时用单发编辑：跳过 investigator，直接把 path:line 交给 genshijin-builder。
7. 禁止在文件未定位时使用 genshijin-builder：先起 investigator，否则主线程为传上下文而消耗 token。
8. 禁止对 5 文件级重构使用 genshijin-investigator → genshijin-builder 链：builder 会返回 `too-big.`，浪费回合。
9. 禁止向 genshijin-reviewer 要「总体反馈」：它只返回 findings，不给架构意见，那类需求用 Code Reviewer。
10. 不要期待散文式输出：genshijin-crew 输出是结构化的、有时晦涩，需要给人直读时由主线程改写。
11. 注意自动解除机制：子代理在安全警告、不可撤销操作确认、或片段含糊有误读风险的输出处会从原始人风格切回正常日语，该部分结束后再恢复。

适用边界 · 注意事项

• 需要架构讲解、建议或带理由与备选方案的深度审查时（应改用 vanilla Explore / Code Reviewer）。
• 任务涉及新功能、3+ 文件或跨切面重构时（应留在主线程或用 feature-dev:code-architect）。
• 需要人类直接阅读的散文式输出时（genshijin-crew 输出结构化且可能晦涩）。