# Compressed Code Review

Reviews a diff with one line per finding: location, problem and fix.

- Repository: https://github.com/JuliusBrussee/caveman (116680 stars)
- Category: Git and review
- License: Apache-2.0
- Last updated: 2026-11-01
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add JuliusBrussee/caveman --skill caveman-review -g -a claude-code -y`
Codex: `npx skills add JuliusBrussee/caveman --skill caveman-review -g -a codex -y`
Cursor: `npx skills add JuliusBrussee/caveman --skill caveman-review -g -a cursor -y`
Gemini CLI: `npx skills add JuliusBrussee/caveman --skill caveman-review -g -a gemini-cli -y`
Claude Code plugin marketplace: `/plugin marketplace add JuliusBrussee/caveman`

## Description

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

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

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

The rest: https://github.com/JuliusBrussee/caveman/blob/HEAD/skills/caveman-review/SKILL.md