Skills juliusbrussee caveman Caveman
caveman-review
- Use it when:
- You want code review comments short enough to paste straight into a pull request.
- It does:
- Writes one line per finding: the line number, the problem and a concrete fix, optionally tagged as a bug, risk, nit or question.
- You get:
- Comments ready to paste, like "L42: 🔴 bug: user can be null after .find(). Add guard before .email.".
- Switches to prose:
- For security findings, design disagreements and authors new to the code who need the why.
- Won't:
- Write the fix, approve the pull request or run linters.
Skill 5 of 16 in the Caveman bundle, after caveman-commit and before caveman-compress.
TL;DR
Caveman is a skill set whose main mode makes the agent reply in short, plain fragments to save tokens. That mode keeps anything saved outside the chat, PR comments included, in normal prose; this skill makes review comments terse too. Each finding is one line, L<line>: <problem>. <fix>., with the file name added on diffs that span several files, and an optional severity: 🔴 bug for broken behavior, 🟡 risk for fragile code such as a race or a swallowed error, 🔵 nit for style the author can ignore, ❓ q for a genuine question. It drops openers like "I noticed that", hedging, praise on every comment and descriptions of what the line already does. It keeps exact line numbers, function and variable names in backticks, and a concrete fix rather than "consider refactoring". Security issues, architectural disagreements and reviews for newcomers get a normal paragraph, then the terse lines resume. It stays in this style until you say "stop caveman-review" or "normal mode".
Summarizes the skill at bad48a0.
npx skills add https://github.com/juliusbrussee/caveman --skill caveman-review skills.sh pageSource on GitHubAll skills from juliusbrussee/caveman
- Total Downloads
- 426,611 on skills.sh, Nov 9, 2026
- Repo stars
- 118,416 juliusbrussee/caveman
- First seen
- Apr 8, 2026 on skills.sh
Weekly values
| Week to | Installs |
|---|---|
| Sep 21 | 14,058 |
| Sep 28 | 11,810 |
| Oct 5 | 10,875 |
| Oct 12 | 9,223 |
| Oct 19 | 7,869 |
| Oct 26 | 8,232 |
| Nov 2 | 7,790 |
| Nov 9 | 7,292 |
| Category |
Find root causes, review code and test what you built. Change how the agent replies: shorter, clearer, fewer tokens. Everything for building software: planning, coding, debugging, design, frameworks, cloud, agents and skills. |
|---|---|
| Type |
Knowledge and rules the agent applies while it works: best practices, design principles, API references. |
| Effect |
Adds no side effects of its own. It shapes how the agent thinks, writes or reviews. Guidelines and routers are always effect:none, even when the task they support edits code. |
| Needs |
Instructions only. Works in any agent that supports skills. |
| Publisher |
Everyone else. Unverified vendor claims default to community. |
| Topics |
SKILL.md
From juliusbrussee/caveman at bad48a0. Checked daily, last changed Oct 20, 2026.
Frontmatter
name: caveman-review
description: >
Compressed code review - one line per finding with location, problem and fix.
Use for /caveman-review, "review this PR", or "review the diff".Write code review comments terse and actionable. One line per finding. Location, problem, fix. No throat-clearing.
Rules
Format: L<line>: <problem>. <fix>. — or <file>:L<line>: ... when reviewing multi-file diffs.
Severity prefix (optional, when mixed):
🔴 bug:— broken behavior, will cause incident🟡 risk:— works but fragile (race, missing null check, swallowed error)🔵 nit:— style, naming, micro-optim. Author can ignore❓ q:— genuine question, not a suggestion
Drop:
- "I noticed that...", "It seems like...", "You might want to consider..."
- "This is just a suggestion but..." — use
nit:instead - "Great work!", "Looks good overall but..." — say it once at the top, not per comment
- Restating what the line does — the reviewer can read the diff
- Hedging ("perhaps", "maybe", "I think") — if unsure use
q:
Keep:
- Exact line numbers
- Exact symbol/function/variable names in backticks
- Concrete fix, not "consider refactoring this"
- The why if the fix isn't obvious from the problem statement
Examples
❌ "I noticed that on line 42 you're not checking if the user object is null before accessing the email property. This could potentially cause a crash if the user is not found in the database. You might want to add a null check here."
✅ L42: 🔴 bug: user can be null after .find(). Add guard before .email.
❌ "It looks like this function is doing a lot of things and might benefit from being broken up into smaller functions for readability."
✅ L88-140: 🔵 nit: 50-line fn does 4 things. Extract validate/normalize/persist.
❌ "Have you considered what happens if the API returns a 429? I think we should probably handle that case."
✅ L23: 🟡 risk: no retry on 429. Wrap in withBackoff(3).
Auto-Clarity
Drop terse mode for: security findings (CVE-class bugs need full explanation + reference), architectural disagreements (need rationale, not just a one-liner), and onboarding contexts where the author is new and needs the "why". In those cases write a normal paragraph, then resume terse for the rest.
Boundaries
Reviews only — does not write the code fix, does not approve/request-changes, does not run linters. Output the comment(s) ready to paste into the PR. "stop caveman-review" or "normal mode": revert to verbose review style.