Ultra-compressed code review comments: location, problem, fix on one line each.
Format: L<line>: <problem>. <fix>. with optional severity prefix ( 🔴 bug: , 🟡 risk: , 🔵 nit: , ❓ q: ) for mixed findings Strips filler language ("I noticed", "you might want", "great work") and restates—keeps exact line numbers, symbol names, concrete fixes, and the why when non-obvious Auto-triggers on "review this PR", "code review", "/review", or /caveman-review ; outputs comments ready to paste into pull requests Reverts to verbose style on request; escalates security findings, architectural disagreements, and onboarding contexts to full explanations
Similar popular skills
Related neighbors and high-traction skills in the same topics — useful to compare before installing.
This skill is a prompt engineering template designed to make code review comments more concise and actionable. It contains no executable code, network operations, or sensitive data access.
Declared targets from SKILL.md / docs. Unmarked agents are not listed — the skill may still install via the CLI.
Claude CodeNot declared
CursorNot declared
CodexNot declared
GitHub CopilotNot declared
WindsurfNot declared
Gemini CLINot declared
ClineNot declared
OpenCodeNot declared
Repository health
Stars104.3K
LicenseLICENSE
Default branchmain
Open issues62
Status
Active
Package contents
Files included with this skill beyond the listing page.
skill mdSKILL.md2,567 B
docsREADME.md1,210 B
docsSUMMARY.md164 B
History
First seen on skills.sh
First recorded snapshot · 342,200 installs
SKILL.md
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."
❌ "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.
