Back to Details

cavecrew

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese
Cavecrew = three subagent presets that emit caveman output. Same job as Anthropic defaults (
Explore
, edit-style agents, reviewer); difference is the tool-result they return is compressed, so main context shrinks per delegation.
Cavecrew = 三个生成穴居人风格输出的子代理预设。其功能与Anthropic的默认代理（
Explore
、编辑风格代理、审查代理）相同；区别在于它们返回的工具结果经过压缩，因此每次委托都会减小主上下文的体积。

When to use cavecrew vs alternatives

何时使用Cavecrew vs 替代方案

TaskUse
"Where is X defined / what calls Y / list uses of Z"
cavecrew-investigator
Same but you also want suggestions/architecture commentary
Explore
(vanilla)
Surgical edit, ≤2 files, scope obvious
cavecrew-builder
New feature / 3+ files / cross-cutting refactorMain thread or 
feature-dev:code-architect
Review diff, branch, or file for bugs
cavecrew-reviewer
Deep code review with rationale + alternatives
Code Reviewer
(vanilla)
One-line answer you already knowMain thread, no subagent
Rule of thumb: if you'd want the subagent's output in 1/3 the tokens, pick cavecrew. If you'd want prose, pick vanilla.
任务使用对象
"X定义在哪里/什么调用了Y/列出Z的用法"
cavecrew-investigator
上述任务，但还需要建议/架构评论
Explore
（原生）
精准编辑，≤2个文件，范围明确
cavecrew-builder
新功能开发 / 3个及以上文件修改 / 跨模块重构主线程或
feature-dev:code-architect
审查差异、分支或文件中的Bug
cavecrew-reviewer
包含理由和替代方案的深度代码审查
Code Reviewer
（原生）
你已知答案的单行问题主线程，无需子代理
经验法则：如果希望子代理的输出占用1/3的tokens，选择cavecrew；如果需要完整 prose（散文式表述），选择原生代理。

Why this exists (the real win)

为什么存在这个工具（真正的优势）

Subagent tool results get injected into main context verbatim. A vanilla 
Explore
that returns 2k tokens of prose costs 2k tokens of main-context budget every time. The same finding from 
cavecrew-investigator
returns ~700 tokens. Across 20 delegations in one session that's the difference between context exhaustion and finishing the task.
子代理的工具结果会原封不动地注入主上下文。一个返回2k tokens散文内容的原生
Explore
，每次都会消耗2k tokens的主上下文预算。而
cavecrew-investigator
得出相同结论仅需返回约700 tokens。在一个会话中进行20次委托时，这就是上下文耗尽与完成任务的区别。

Output contracts

输出约定

What main thread can rely on per agent:
cavecrew-investigator
<Header>:
- path:line — `symbol` — short note
totals: <counts>.
Or 
No match.
Always file-path-first, line-number-attached, backticked symbols. Safe to grep with 
path:\d+
.
cavecrew-builder
<path:line-range> — <change ≤10 words>.
verified: <re-read OK | mismatch @ path:line>.
Or one of: 
too-big.
/ 
needs-confirm.
/ 
ambiguous.
/ 
regressed.
(terminal first token).
cavecrew-reviewer
path:line: <emoji> <severity>: <problem>. <fix>.
totals: N🔴 N🟡 N🔵 N❓
Or 
No issues.
Findings sorted file → line ascending.
主线程可依赖各代理的输出规范：
cavecrew-investigator
<Header>:
- path:line — `symbol` — short note
totals: <counts>.
或返回
No match.
始终以文件路径优先，附带行号，符号用反引号包裹。可使用
path:\d+
安全地进行grep检索。
cavecrew-builder
<path:line-range> — <change ≤10 words>.
verified: <re-read OK | mismatch @ path:line>.
或返回以下其中一项：
too-big.
/ 
needs-confirm.
/ 
ambiguous.
/ 
regressed.
（首词为终端标识）。
cavecrew-reviewer
path:line: <emoji> <severity>: <problem>. <fix>.
totals: N🔴 N🟡 N🔵 N❓
或返回
No issues.
结果按文件→行号升序排列。

Chaining patterns

链式模式

Locate → fix → verify (most common):
  1. cavecrew-investigator
    returns site list.
  2. Main thread picks 1-2 sites, hands paths to 
    cavecrew-builder
    .
  3. cavecrew-reviewer
    audits the diff.
Parallel scout (when investigation is broad): Spawn 2-3 
cavecrew-investigator
calls in one message (different angles: defs vs callers vs tests). Aggregate in main thread.
Single-shot edit (when site is already known): Skip investigator. Hand exact path:line to 
cavecrew-builder
directly.
定位 → 修复 → 验证（最常见）：
  1. cavecrew-investigator
    返回目标位置列表。
  2. 主线程选择1-2个位置，将路径交给
    cavecrew-builder
    。
  3. cavecrew-reviewer
    审查差异。
并行侦察（当调查范围较广时）： 在一条消息中发起2-3次
cavecrew-investigator
调用（不同角度：定义 vs 调用方 vs 测试）。在主线程中汇总结果。
单次编辑（当已知目标位置时）： 跳过调查环节，直接将精确的path:line交给
cavecrew-builder
。

What NOT to do

禁止操作

  • Don't use 
    cavecrew-builder
    when you don't already know the file. Spawn investigator first or main thread will eat tokens passing context.
  • Don't chain 
    cavecrew-investigator → cavecrew-builder
    for a 5-file refactor. Builder will return 
    too-big.
    and you'll have wasted a turn.
  • Don't ask 
    cavecrew-reviewer
    for "general feedback" — it returns findings only, no architecture opinions. Use 
    Code Reviewer
    for that.
  • Don't expect prose. Cavecrew output is structured, sometimes terse to the point of cryptic. If a human will read it directly, paraphrase.
  • 当你不知道目标文件时，不要使用
    cavecrew-builder
    。先调用调查代理，否则主线程会因传递上下文消耗大量tokens。
  • 不要为5个文件的重构链式调用
    cavecrew-investigator → cavecrew-builder
    。Builder会返回
    too-big.
    ，浪费一次调用机会。
  • 不要让
    cavecrew-reviewer
    提供“通用反馈”——它仅返回问题结果，不提供架构意见。此类需求请使用
    Code Reviewer
    。
  • 不要期望散文式输出。Cavecrew的输出是结构化的，有时简洁到近乎晦涩。如果需要人类直接阅读，请自行转述。

Auto-clarity (inherited)

自动清晰化（继承特性）

Subagents drop caveman → normal English for security warnings, irreversible-action confirmations, and any output where fragment ambiguity could be misread. Resume caveman after.
当涉及安全警告、不可逆操作确认，以及任何可能因片段歧义导致误读的输出时，子代理会从穴居人风格切换为标准英文表述。完成相关内容后恢复穴居人风格输出。