mcpField
C
caveman-review

caveman-review

github.com/juliusbrusseeTesting & quality115.8k414.9k installsUpdated 4d ago
Repository

About caveman-review

caveman-review is a skill for writing terse, actionable code review comments. Each finding is one line covering location, problem and fix, suited to reviewers who want to post PR comments quickly.

Key features

  1. 01One-line format with location, problem and fix
  2. 02Optional severity prefixes for bug, risk, nit and q
  3. 03Exact line numbers and symbol names in backticks
  4. 04Full explanation kept for security and architecture issues
  5. 05Output ready to paste into a pull request

Use cases

  1. 01Producing line-level comments for a pull request
  2. 02Separating must-fix bugs from optional nit suggestions
  3. 03Suggesting concrete fixes for missing retry or null checks

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/juliusbrussee/caveman --skill caveman-review

After installing, type/caveman-reviewin Claude Code to confirm it loaded.

Bundled filesREADME.md

Details

From the project README

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.

Comments

Markdown supported