cavecrew
Cavecrew は、Anthropic のデフォルトエージェントの出力を圧縮し、コンテキストトークンの消費を大幅に削減するサブエージェントプリセットのセットです。コードの調査、外科的編集、バグチェックのための調査者、ビルダー、レビューアーモードを提供し、複数回の委任でコンテキストの枯渇を回避し、開発効率を向上させます。
npx skills add https://github.com/juliusbrussee/caveman --skill cavecrewBefore / After 効果比較
1 组Anthropic のデフォルトの `Explore` サブエージェントでコード調査を行う際、その詳細な散文形式の出力は大量のコンテキストトークンを消費し、1回の操作で2000トークンを占めることがあり、複数回の対話後にコンテキストが急速に枯渇します。
`cavecrew-investigator` サブエージェントで同じコード調査を行うと、その圧縮された構造化された出力によりトークン消費が約700トークンに削減され、コンテキストの寿命が大幅に延長され、複雑な複数ターンタスクを円滑に完了できます。
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.
When to use cavecrew vs alternatives
| Task | Use |
|---|---|
| "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 refactor | Main 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 know | Main 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.
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.
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.
Chaining patterns
Locate → fix → verify (most common):
cavecrew-investigatorreturns site list.- Main thread picks 1-2 sites, hands paths to
cavecrew-builder. cavecrew-revieweraudits 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.
What NOT to do
- Don't use
cavecrew-builderwhen you don't already know the file. Spawn investigator first or main thread will eat tokens passing context. - Don't chain
cavecrew-investigator → cavecrew-builderfor a 5-file refactor. Builder will returntoo-big.and you'll have wasted a turn. - Don't ask
cavecrew-reviewerfor "general feedback" — it returns findings only, no architecture opinions. UseCode Reviewerfor that. - Don't expect prose. Cavecrew output is structured, sometimes terse to the point of cryptic. If a human will read it directly, paraphrase.
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.
ユーザーレビュー (0)
レビューを書く
レビューなし
統計データ
ユーザー評価
この Skill を評価