cavecrew

サブエージェントに何度も仕事を投げる長い作業で効きます。このスキル自体は作業をしません。「どの仕事を、どのサブエージェントに渡すか」の判断表です。

狙いは、戻ってくる結果を短くすること

サブエージェントの結果は、本体の会話にそのまま差し込まれます。SKILL.md の説明では、標準の Explore が 2,000 トークンの文章を返せば、そのたびに本体の文脈が 2,000 トークン減ります。同じ調べものを path:line の短い表で返させれば、1 回あたりの減りが小さくなる、という考え方です。

本文は、1 回の作業で 20 回委譲するなら、文脈を使い切るか最後まで終えられるかの差になる、と書いています。ただし同梱の README.md は、効果は作業と委譲の回数しだいで、決まった削減率は示さないと断っています。

3 つのサブエージェント

• cavecrew-investigator定義・呼び出し元・使われている場所を探す。読むだけで、修正の提案もしない
• cavecrew-builder場所が分かっている 1〜2 ファイルの小さな修正。3 ファイル以上は断る
• cavecrew-reviewer差分・ブランチ・ファイルのレビュー。指摘を 1 件 1 行で返す

答え方は 3 つとも、同じ公開元の caveman のうち、文法まで削る ultracave の口調です。道具を動かしている間は、始めと終わりに 1 行ずつ状況を書くだけで、途中の決まりきった呼び出しの合間には何も書きません。

選び分けの目安

本文の表を言い直すと、次のとおりです。

目安は 1 文に絞られています。結果を 3 分の 1 のトークンで欲しいなら cavecrew、文章で欲しいなら標準のものを選びます。

つなぎ方は 3 通り

いちばんよく使うのは、探す → 直す → 確かめる、の順です。

1. 探すcavecrew-investigator が該当箇所の一覧を返す
2. 選ぶ本体が 1〜2 か所を選び、経路を cavecrew-builder に渡す
3. 確かめるcavecrew-reviewer が差分を見る

調べる範囲が広いときは、cavecrew-investigator を 1 回のメッセージで 2〜3 本同時に出します（定義・呼び出し元・テストのように角度を変える）。直す場所がもう分かっているなら、探す段を飛ばして cavecrew-builder に経路と行を直接渡します。

人がそのまま読む結果が欲しいとき

本文は、出力は定型で、ときに暗号のように短いと認めています。人が直接読むなら本体が言い換えるように、とあります。説明や理由を読みたいなら、最初から標準の Explore や Code Reviewer を使うほうが早いです。

3 ファイル以上にまたがる修正

cavecrew-investigator から cavecrew-builder へつないで 5 ファイルの作り直しをさせるのは、本文が名指しで止めています。builder が too-big. と返して 1 回分が無駄になるからです。大きな変更は本体の会話で扱います。

どのファイルを直すか分かっていないとき

場所を知らないまま cavecrew-builder を使わない、とも書かれています。先に investigator で探すか、本体で探してから渡します。そうしないと、説明を渡すぶん本体のトークンがかさみます。

全体の感想や設計の意見が欲しいレビュー

cavecrew-reviewer は指摘だけを返し、設計の意見は言いません。「全体的にどうか」を聞きたいなら、標準の Code Reviewer か、code-review のような理由まで書くレビューのスキルが向いています。

スキルだけでは委譲先がそろわない

SKILL.md は 3 つのサブエージェントを呼ぶ前提で書かれていますが、その定義はスキルのフォルダーには入っていません。定義はリポジトリの agents/ にある 3 つの .md で、Claude Code のプラグイン（plugins/caveman/agents/）や公開元のインストーラーが入れます。

同梱ファイルは、当サイトが読んでいる経路（plugins/caveman/skills/cavecrew/）では 0 件です。同じ中身の skills/cavecrew/ には人向けの README.md が 1 件あります（2026-10-22 時点）。2 つの SKILL.md は同じ版です。

SKILL.md が書いていること・いないこと

SKILL.md の解析では、外部通信・シェル実行・ファイル書き換えの記述はありません。書き換えやシェルを使うのは委譲先のほうです。定義を読むと次のようになっています。

builder は、壊す操作が要るときは needs-confirm. を返して止まります。直したあとテストが通らず範囲内で直せないときは regressed. と、戻す場所を返します。

モデルは既定で軽いものに固定されている

定義の先頭で、investigator と reviewer は model: haiku を指定しています。builder には指定が無く、その回の既定のモデルで動きます。変えたいときは、Claude Code を起動する前に CAVECREW_REVIEWER_MODEL などの環境変数を入れます（同梱の README.md）。

この上書きは、入っているサブエージェントの定義の model: の行を書き換える仕組みです。書き換えられる定義ファイルがあるのはプラグインで入れた場合だけで、プラグインを更新するか入れ直すと戻ります。

警告は普通の文で書く

口調を崩す場面も決められています。セキュリティの警告、取り返しのつかない操作の確認、断片では誤読されそうな出力は、普通の英語に戻してから元の口調に戻ります。

標準の Explore と何が違いますか

仕事の中身は同じで、違うのは返ってくる形です。cavecrew-investigator は、1 件 1 行で経路と行番号、記号、6 語以内の短い説明を返し、最後に件数をまとめます。修正の提案や設計の意見は返しません。それが欲しいときは Explore のほうが合います。

スキルを入れたのに、cavecrew-investigator が見つからないと言われます

委譲先のサブエージェントが入っていないためです。スキルのフォルダーには判断表しか無く、3 つの定義はリポジトリの agents/ にあります。Claude Code のプラグインとして入れるか、公開元のインストーラーを使うと一緒に入ります。

builder が `too-big.` と返してきました

3 ファイル以上にまたがる変更だと判断して、手を付けずに断った印です。返答には、1 行ずつの小さな仕事に分ける案が付きます。分けて渡し直すか、本体の会話で作業してください。

Codex でも使えますか

公開元の技術文書は、cavecrew を Claude Code のサブエージェント 3 つのための判断表と説明しています。インストーラーは、サブエージェントの仕組みを持つほかのエージェント（Cursor や opencode など）にも定義を入れますが、Codex については書かれていません。当サイトでは対応エージェントを Claude Code だけにしています。