mcpField
C
caveman-review

caveman-review

github.com/karnonsonTesting & quality148 installsUpdated 19w ago
Repository

About caveman-review

A skill for developers who want concise, actionable code review comments ready to paste into a PR. It focuses each finding on location, problem, and fix, with labels for bugs, risks, nits, and questions.

Key features

  1. 01Keep each finding to one line
  2. 02State location and a concrete fix
  3. 03Label bugs, risks, nits, and questions
  4. 04Allow fuller explanations for security and architecture
  5. 05Produce review comments without changing code

Use cases

  1. 01Turn review findings into PR comments
  2. 02Flag missing null checks or error handling
  3. 03Give a specific fix for fragile logic
  4. 04Switch to normal review style when needed

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/karnonson/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