Caveman Review

by juliusbrussee2e08b9177c07No licenseListed Oct 8, 2026Updated Oct 8, 2026

Compressed code review - one line per finding with location, problem and fix. Use for /caveman-review, "review this PR", or "review the diff".

Instructions onlySoftware Development
AI-generated overview

Formats code review findings as terse one-line comments with location, problem and fix.

What it does
Provides a compressed style for writing code review comments, one line per finding in the form location, problem, fix. It defines optional severity prefixes for bugs, risks, nits and questions, lists phrases to drop and details to keep, and gives before/after examples. It also specifies when to abandon terse mode, such as security findings, architectural disagreements and onboarding contexts.
When to use it
Use it when reviewing a pull request or diff and you want short, actionable comments ready to paste. It suits reviewers who want to avoid hedging and restated code. It is not for writing the fix, approving changes or running linters.
Requirements
No tools, packages or credentials; it is instructions only and ships no scripts.

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.

Source and attribution

Source:juliusbrussee/cavemaninskills/caveman-reviewat commit2e08b91

License: No license

Content belongs to its original authors. SourceWeft indexes it from a public repository.

Report or request removal