caveman-optimize

Caveman Cloud の報告に「文脈が大きい」「道具の一覧が重い」のような観察が出ていて、それを自分のアプリで本当に直せるか確かめたいときのスキルです。観察を鵜呑みにして直すのではなく、変更前と変更後を同じ入力で比べる評価を組み、その結果で採るか決めさせます。

本文は最初に、観察は記録された集計の形を述べたものにすぎない、と念を押しています。節約の見積もりでも、直し方の手順でも、変更が安全だという証明でもない、という扱いです。

扱う観察の id

4 種

観察を読むところから報告まで

5 段

SKILL.md（2026-10-23 時点）

4,723 バイト

扱う観察は 4 種だけ

caveman opportunities list の結果のうち、report_only_observations の欄だけを読みます。扱うのは次の 4 つの id で、それ以外の欄から選んではいけません。

これらには金額の幅が 0 に固定されていて、実行に移す道筋もありません。だから値打ちで順位を付けない、金額をでっち上げない、集計を特定の呼び出し箇所の話にすり替えない、と書かれています。

5 段で進める

1. 観察を読むログイン済みの CLI で一覧を取り、サーバーの題名と観察の文をそのまま保つ
2. 選んでもらう順位を付けずに並べ、id・題名・観察・最後に見えた日時を見せて、人に 1 つ選ばせる
3. 案と評価を作る原因になりうる呼び出し箇所を根拠付きで示し、変更 1 件と対の評価の設計を出して承認を取る
4. 当てて比べる承認された 1 件だけを当て、対の評価とリポジトリの確かめを流す
5. 報告する観察・変更・比べた結果・品質・判断を決まった形で書く。節約額は書かない

対の評価とは

変更前（基準）と変更後（候補）を、同じ固定の入力で動かして比べる評価です。記録するのは、保たれるべき品質の確かめ、両方に同じ物差しで測ったトークン・バイト・プロバイダーの数えた費用、使った入力とコマンドと環境、公平な比較を邪魔する要因、の 4 つです。

リポジトリに固定の入力・品質の確かめ・共通の測り方のどれかが欠けていれば、そこで止まって足りないものを挙げます。普通の単体テストだけでは最適化の証明にならない、とも書かれています。

報告の形が決まっている

最後の報告は 8 行の形です。観察の id とサーバーの題名、記録された観察の文（そのまま）、変更した箇所と承認された中身、対の評価の入力と両方の結果、品質の確かめの実際の結果、流したコード側の確かめと結果、と並びます。そのあとに、金額の扱いを述べる行と、採る・捨てる・決められないのどれかを書く判断の行が続きます。

節約の額を書く欄はありません。「何が減ったか」ではなく「同じ入力で比べてどうだったか」を残す作りです。

名札の無い通信を分けたいとき

観察の中に unlabeled-traffic しか手を付けられそうなものが無いなら、このスキルの出番ではありません。本文は、名札付けは最適化ではないとして caveman-discover へ回すよう書いています。

費用がどこで出ているかを調べたいだけのとき

このスキルはコードを変える前提で、観察 1 つに対して変更 1 件を評価します。費用の内訳やトレースを読むだけなら、書き換えをしない caveman-evidence-review が向いています。

比べるための入力と物差しが無いとき

固定の入力、品質の確かめ、両方に共通の測り方がそろっていないリポジトリでは、評価を組めずに止まります。先にそれを用意するのが順番です。

コードを書き換え、評価を流す

SKILL.md には、シェル実行（caveman opportunities list、対の評価、リポジトリの確かめ）とファイル書き換え（承認された 1 件の変更）の記述があります。観察の一覧は Caveman Cloud から取るので、その分の外部通信があります。評価がアプリの LLM を呼ぶなら、そのプロバイダーへの課金も起こりえます。

採れなかった変更は戻す

基準と候補が同じ入力と物差しを使っていなければ、その比較は捨てます。品質が落ちた、または資源の結果がはっきりしないなら、その変更だけを戻し、採るに値しなかったと報告します。

差分は根拠を示した呼び出し箇所に留め、もともとある安全のための仕組みは残す決まりです。

Caveman の側の状態は変えない

Caveman の実験や提案を作ること、観察を「実施済み」にすること、状態を進めること、最適化の機能を入れることは、どれもしません。確認用の観察で許されているのは取り下げだけで、このスキルはその取り下げもしない、と書かれています。

古い id や古い提案の扱い

context-window-bloat・tool-catalog-utilization・verbose-tool-output は廃止された id で、決して選ばない・当てない決まりです。古い提案や手元のファイルに出てきても、経緯として読むだけで、金額や手順を持ち出しません。

.caveman/proposals/*.md があっても、信用しない過去の文脈として扱います。今の一覧と人の選択の代わりにはなりません。

同梱ファイルは無い

スキルのフォルダーには SKILL.md しかありません（2026-10-23 時点）。

節約できた額は出ますか

出ません。報告の形には、確認用の観察で金額の幅は 0、推定の節約も確かめた節約も無い、という行が決まっています。トークンやバイトの減りを金額に換えるのは、製品側の確かめの方法で同じ要求の費用がそろったときだけで、手元の比較の結果は、その入力でのその変更についてしか言えない、と書かれています。

ログインしていないと、どうなりますか

CLI が無い、認証に失敗する、一覧に report_only_observations が無い、のどれかなら、書き換えをせずに止まり、何が足りないかを報告します。ゲートウェイの別の報告やプロジェクトの API の鍵で代わりにすることも禁じられています。

観察に書かれている原因をそのまま直してよいですか

本文は、観察が原因を名指ししていると思い込むな、と書いています。選んだ観察の集計の形を生みうる仕組みを、リポジトリの中で呼び出し箇所の根拠付きで探し、そのうえで変更 1 件を提案する手順です。

Codex でも使えますか

使えます。Caveman の CLI の文書は、caveman setup --agent-native codex（Claude Code なら claude）で、最適化のスキルを含む一式を Codex か Claude Code に組み込む手順を載せています。