Skill

caveman-review

Generates terse, actionable code review comments in 'L<line>: <problem>. <fix>.' format. Cuts noise from PR feedback, preserves signal. Auto-triggers on pull requests.

code-quality

Install

npx claudepluginhub juliusbrussee/caveman --plugin caveman

Tool Access

This skill uses the workspace's default tool permissions.

SKILL.md

Similar Skills

cache-components

Guides Next.js Cache Components and Partial Prerendering (PPR) with cacheComponents enabled. Implements 'use cache', cacheLife(), cacheTag(), revalidateTag(), static/dynamic optimization, and cache debugging.

cache-components

138.8k

claude-opus-4-5-migration

2 files

Migrates code, prompts, and API calls from Claude Sonnet 4.0/4.5 or Opus 4.1 to Opus 4.5, updating model strings on Anthropic, AWS, GCP, Azure platforms.

claude-opus-4-5-migration

83.2k

bmad-help

Analyzes BMad project state from catalog CSV, configs, artifacts, and query to recommend next skills or answer questions. Useful for help requests, 'what next', or starting BMad.

bmad-pro-skills

43.8k

Stats

Stars8617

Forks375

Last CommitApr 9, 2026

Actions

View Source View Plugin View on GitHub View README

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.