caveman (JuliusBrussee/caveman, SKILL.md only)

レビュー

Mac テストマシン上で Codex CLI 0.166（gpt-6-astra、低推論）、実行ごとに新規の一時プロジェクトと一時 HOME/TMPDIR/キャッシュを使用、スキルをインストール（スキルあり群）、スキルなし（対照群）、またはスキルの中核要件をプロンプト末尾に付けた一文に圧縮（一文プロンプト群）、タスクごとに各群 2 実行、ネットワーク無効、/tmp への書き込みはブロック。プロンプトはスキル名に一切言及しません（以下で注記する表現を除く）。各プロンプトは技術的な質問（無限 useEffect ループ、遅い Postgres クエリ、共有ブランチでの merge か rebase か）で、末尾に 'Be brief; I'm paying per token.' が付きます。このフレーズはスキル自身のトリガーの 1 つで、対照群にも同じ文が与えられます。つまり、このテストは、単に簡潔さを求める依頼に加えてスキルが何を追加するのかを問うものです。

3群の比較

Codex CLI で 18 実行を計測し、LLM 判定なしのルールベースのチェックで採点。合計 21.7 / 30、判定は 状況次第。

判定：状況次第（21.7 / 30）。 出典：JuliusBrussee/caveman、skills/caveman、コミット 9b68f7e 時点。インストール：npx skills@latest add JuliusBrussee/caveman --skill caveman。ライセンス： MIT（リポジトリの LICENSE。リポジトリ内の hooks とインストーラーはインストールも実行もしていません）。

概要

caveman スキル（skills/caveman/SKILL.md のみ。リポジトリの hooks とインストーラーはインストールしませんでした）。簡潔な返答スタイルです。先に答える、挨拶と要約を省く、短い単語、冠詞は省くが否定は絶対に省かない、コード・パス・数値・エラーはそのまま残す、警告と取り返しのつかない操作は平易な文章で書く、という内容。'caveman mode'、'be brief'、'less tokens' でトリガーされます。約 600 語の Markdown で、スクリプトはありません。

テスト方法

Mac テストマシン上で Codex CLI 0.166（gpt-6-astra、低推論）、実行ごとに新規の一時プロジェクトと一時 HOME/TMPDIR/キャッシュを使用、スキルをインストール（スキルあり群）、スキルなし（対照群）、またはスキルの中核要件をプロンプト末尾に付けた一文に圧縮（一文プロンプト群）、タスクごとに各群 2 実行、ネットワーク無効、/tmp への書き込みはブロック。プロンプトはスキル名に一切言及しません（以下で注記する表現を除く）。

各プロンプトは技術的な質問（無限に続く useEffect ループ、遅い Postgres クエリ、共有ブランチでの merge 対 rebase）で、末尾は 'Be brief; I'm paying per token.' です。このフレーズはスキル自身のトリガーの 1 つで、対照群にも同じ文を与えています。つまりこのテストは、単に簡潔さを求める依頼にスキルが何を上乗せするのかを問うています。

1. 無限の useEffect ループを説明する — React コンポーネントに const fetchData = async () => { const r = await fetch('/api/items'); setItems(await r.json()); } と useEffect(() => { fetchData(); }, [fetchData]); があります。このコンポーネントは無限ループで再フェッチします。なぜか、そして修正は何か？ Be brie…
2. 遅い Postgres クエリを修正する — Postgres：SELECT id, total FROM orders WHERE customer_id = 42 ORDER BY created_at DESC LIMIT 20; が、主キーインデックスしかない 5000 万行の orders テーブルで数秒かかります。どうすればよいか？ Be brief; I'm paying per token.
3. 共有ブランチでの merge か rebase か — チームは、他の人がすでに pull している共有フィーチャーブランチで作業しています。最新の main を取り込みたいです。git merge と git rebase のどちらを使うべきか、またその理由は？ Be brief; I'm paying per token.

採点はプログラム的（隠しテスト／仕込み問題の検出／制約チェック／該当する場合はレンダリング+OCR）で、実行ごとに 0〜5 点。スコアはどの LLM 判定者も決めていません。

結果

第3群に与えた一文プロンプト："簡潔に答える：先に答える、挨拶・つなぎ・言い淀み・要約をしない、不要な冠詞は省く、技術的事実・コード・数値・否定はすべて正確に残す。"

平均スコア：スキルなし 4.67 対 スキルあり 4.67（差分 +0.0）。1 実行あたりのトークン：14k 対 31k（2.20 倍）、時間 12 秒 対 19 秒。一文プロンプト群：4.5（一文プロンプトに対するスキルの上乗せ：+0.17、スキルなしに対する一文プロンプト自身の上乗せ：-0.17）。一文プロンプトのトークンは 1 実行あたり 14k で、スキルのコストは一文プロンプトの 2.20 倍です。

何が起きたか

• スキルなしでも、簡潔さを求めるとエージェントはすでに約 59 語（45〜70）で答えます。スキルありは 52 語（39〜64）、一文版は 54 語です。7 語の差は実行間のばらつきの範囲内です。どの群もつなぎの書き出しや締めを使いませんでした。18 の回答すべてがコード、コマンド、主要な事実を残していました。
• 事実の保持も同じでした。各回答で必須の技術的事実 5 個中 3〜5 個をどの群も保持（保持された必須事実の割合：対照群 87%、一文プロンプト 80%、スキルあり 87%）。エージェントがよく落とした 1 つの事実（state の更新がコンポーネントを再レンダリングして effect を再実行するという点）は、3 群すべてが等しく落としました。「共有ブランチを rebase しない」という点は、私たちのチェックで対照群 2 実行中 1、一文プロンプト 2 実行中 0、スキルあり 2 実行中 1 が該当しました。私たちが読んだ回答ではすべて merge を推奨し、rebase はプライベートまたは未公開の作業向けに取っておいていたため、これらの取りこぼしは部分的に表現の問題です。
• プロンプトにトリガーとなるフレーズが含まれるため、スキルは 6/6 実行で読み込まれました。1 実行あたり 31k トークン（14k の 2.2 倍）かかります。エージェントは、直接答えられる質問に答える前にスキルを読み込み、それを読むためにコマンドを 2 回実行するからです。一文プロンプトのコストは対照群と同じです。
• 回答を読むと、スタイルは同じです。先に答える、断片的な文、短いコードブロック。スキルありの回答と対照群の回答を見分けられませんでした。

次元別スコア

このテストの限界

• このテストは、明示的な 'be brief' の依頼に上乗せしてスキルを測っています。スキルの本来の用途は持続的です。セッション全体で有効になり、毎回依頼を繰り返す必要がなくなる、というものですが、この 3 問のテストでは試していません。
• ここで数えたトークンのコストは、会話ごとに 1 回だけのスキル読み込みです。長いセッションで回答ごとに数語節約できれば元が取れるかもしれませんが、それは計測していません。
• 確認したのは 3 つの技術的な質問へのチャット回答のみです。コミットメッセージ、コードレビューのコメント、長いエージェントセッション（スキルに他のルールがある場面）はテストしていません。
• リポジトリの hooks、ステータスライン、その他の caveman スキルはインストールも実行もしていません。
• タスク・群ごとに n=2。1 ポイント未満の差はノイズです。
• ルールベースの採点はチェックで見えるものだけを測ります。センスや、その結果が可能な限り最良かどうかは判定できません。

セキュリティ

security.md を参照。スキャン：0 CRITICAL / 0 HIGH / 0 MEDIUM。判定：実行しても安全（ネットワーク無効のサンドボックス）。クリーンなスキャン結果はスキルの安全性を証明しません。

まとめ

単なる 'be brief' の依頼に上乗せした場合、caveman は測定できる範囲で回答を短くも正確にもしませんでした。読み込むと短い回答のトークンが倍になります。セッション全体で毎回頼まずにエージェントを簡潔にしたいなら、このスキルがそれを実現します。1 つの質問で簡潔さだけが必要なら、プロンプトでそう伝えてください。