caveman-review
コードレビューの指摘を、行番号・問題・直し方の 1 行ずつに絞って書かせる。前置きや「〜かもしれません」を削り、PR にそのまま貼れる形で出させる
npx skills add juliusbrussee/caveman/caveman-review入れる前にこのスキルがすること・注意点・SKILL.md の原文を確かめてください。解析は安全性の判定ではありません。
- インストール
- 418,585
- 実用度
- 52
- GitHub star
- 117,973
- 最終更新
- 2026/11/6
頼み方の例
そのままコピーして使えますcaveman-reviewで、いまのブランチの差分をレビューしてください。指摘は1件1行で、行番号・問題・直し方を書いてください。コードの修正はしないでください。
対象のファイルや状況は、ご自身の作業に合わせて置き換えてください。
このスキルがすること
SKILL.md の記述から機械的に抽出- 外部通信・シェル実行・ファイル操作の記述は見つかりませんでした
これは安全性の判定ではありません。 SKILL.md にそう書かれているという事実だけを並べています。実際に問題があるかは使い方と文脈で決まるため、当サイトでは断定しません。導入前に SKILL.md の原文を確認してください。
SKILL.md の規模
いつ使うか
レビューの指摘が長くて読まれないと感じたときに効きます。エージェントに PR を見せると、「〜に気づきました」「〜を検討してもよいかもしれません」で始まる段落が並びがちです。このスキルは、1 件を 1 行に縮める書き方を与えます。
1 行の形
L<行番号>: <問題>. <直し方>.
複数のファイルにまたがる差分では、先頭にファイル名を付けて <ファイル>:L<行番号>: ... とします。範囲を指すときは L88-140 のように書きます。
重さの印は 4 つ
重さの違う指摘が混ざるときだけ、行の頭に印を付けます（付けるかどうかは任意）。
| 印 | 意味 |
|---|---|
🔴 bug: | 動きが壊れている。事故になる |
🟡 risk: | 動くが脆い。競合、null の確認漏れ、握りつぶしたエラーなど |
🔵 nit: | 書き方・名前・細かい最適化。作者は無視してよい |
❓ q: | 提案ではなく、本当に聞きたいこと |
削るものと残すもの
削る
「〜に気づきました」「〜のようです」などの前置き、「ただの提案ですが」、指摘ごとの褒め言葉、その行が何をしているかの言い直し、「たぶん」「かもしれない」
残す
正確な行番号、バッククォートで囲んだ関数名や変数名、具体的な直し方、問題から直し方が自明でないときの理由
褒め言葉は、言うなら最初に 1 回だけにします。迷いのある指摘は、ぼかして書かずに q: にします。「作り直しを検討して」ではなく、何をどう分けるかまで書くのが決まりです。
例の書き換え
本文には、長い指摘を 1 行に直した例が 3 つあります。言い直すと次のとおりです。
- null の確認漏れ3 文の説明が
L42: 🔴 bug:で始まる 1 行になる。find のあと user が null になりうる、email の前で確かめる - 長すぎる関数「分けると読みやすいかも」が
L88-140: 🔵 nit:の 1 行になる。50 行で 4 つの仕事、検証・整形・保存に分ける - 429 の扱い「どうなるか考えましたか」が
L23: 🟡 risk:の 1 行になる。429 で再試行しない、withBackoff(3) で包む
サブエージェントの cavecrew-reviewer との違い
同じ公開元の cavecrew には、よく似た形で答える cavecrew-reviewer というサブエージェントがあります。こちらは本体の会話で、貼り付ける文面を書く道具です。向こうは別のサブエージェントに差分を読ませ、短い結果だけを本体に返させる道具です。
| caveman-review | cavecrew-reviewer | |
|---|---|---|
| 動く場所 | 本体の会話 | サブエージェント |
| 行の形 | L<行番号>:（複数ファイルならファイル名を付ける） | 常に path:line: |
nit | 重さが混ざれば付ける | 丁寧に見るよう頼まれたときだけ出す |
| 締め | 決まりなし | 最後に印ごとの件数、指摘が無ければ No issues. |
PR に貼るコメントが欲しいならこちら、長い作業の途中で文脈を節約しながら差分を確かめたいなら cavecrew-reviewer、という分け方になります。
使わないほうがいいとき
コードを直してほしいとき
このスキルはレビューの文面を書くだけです。直すコードは書かず、承認や変更依頼の操作もせず、リンターも動かしません。直すところまで任せたいなら、指摘を受けたあとに別の依頼として出します。
理由や代案をじっくり読みたいとき
1 行の形は、理由を短く削る方向に働きます。設計の考え方や代わりの案まで読みたいレビューなら、code-review のように説明まで書くスキルのほうが向いています。
入ったばかりの人への指摘
本文自身が、新しく入った作者に「なぜか」を伝える場面では短い形をやめる、と決めています。相手が新人ばかりのチームでは、1 行の指摘は不親切に読まれやすいので、最初から普通の書き方を選ぶほうが素直です。
注意点
文面の書き方を与えるだけのスキル
SKILL.md の解析では、外部通信・シェル実行・ファイル書き換えの記述はありません。指摘を、PR に貼れる形で出すところまでが範囲です。同梱ファイルは人向けの README.md の 1 件です（2026-10-22 時点）。
短い形をやめる 3 つの場面
次の場面では、普通の段落で書いてから、残りの指摘を 1 行の形に戻します。
- セキュリティの指摘。CVE に当たるような不具合は、説明と参照先まで要る
- 設計への反対意見。1 行ではなく理由が要る
- 入ったばかりの作者が相手で、「なぜか」が要るとき
やめるときの言葉
stop caveman-review か normal mode と言えば、普通の長さのレビューに戻ります。
同じ公開元のスキル
同じ公開元の caveman-commit は、コミットメッセージを同じ方針で短くします。レビューもコミットも短くしたいなら、組み合わせると書き方がそろいます。
インストール数の推移
日次で記録9月18日 〜 11月7日（49日分）
インストール数と 1 日あたりの増加は Skillselion が に集計した値です。上流の更新は数日おきなので、前日比ではありません。GitHub star と最終更新は に GitHub から取得しました。
併用すると強いスキル
cavecrew
コードの場所探し・1〜2 ファイルの小さな修正・差分のレビューを、短い定型で答える 3 つのサブエージェントへ振り分けさせる。結果が短いぶん、会話の文脈が長持ちする
caveman-commit
コミットメッセージを Conventional Commits で、意図だけに絞って書かせる。AI の署名も入れない
code-review
レビューを「規約」と「仕様」の 2 軸に分けて並行で走らせる。前提の準備が必要
receiving-code-review
レビューの指摘に「おっしゃるとおりです」と返させない。検証してから直す
よくある質問
日本語のレビューでも使えますか
使えますが、形の決まりは英語の例で書かれています。L42: や bug: のような頭の部分はそのままにして、問題と直し方を日本語で書かせると崩れにくくなります。依頼文で「指摘は日本語で」と言っておくのが確実です。
印が付かない指摘があります
印は、重さの違う指摘が混ざるときに付ける任意のものです。すべて同じ重さなら、印を省いた L<行番号>: <問題>. <直し方>. の形になります。毎回付けてほしいなら、依頼文でそう指定してください。
PR に直接コメントを書き込みますか
書き込みません。出すのは貼り付けられる形のコメントの文面だけで、承認や変更依頼の操作もしません。GitHub への書き込みは、文面を確かめてから自分で行います。