Caveman Review
Coding426.6K installs
What it does
Compressed code review - one line per finding with location, problem and fix. Use for /caveman-review, "review this PR", or "review the diff".
Install
npx skills add https://github.com/juliusbrussee/caveman --skill caveman-reviewWebsite
www.skills.sh/juliusbrussee/caveman/caveman-reviewDetails
From the skillβs SKILL.md or README, by its authors. View the original
Write code review comments terse and actionable. One line per finding. Location, problem, fix. No throat-clearing.
Rules
Format: L: . . β or :L: ... 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.
More Coding skills
See allCoding
Scan a codebase for deepening opportunities, present them as a visual HTML report, then grill through whichever one you pick.
1.2M installsnpx skills add https://github.com/mattpocock/skills --skill improve-codebase-architectureCoding
React and Next.js performance optimization guidelines from Vercel Engineering. This skill should be used when writing, reviewing, or refactoring React/Next.js code to ensure optimal performance patterns. Triggers on tasks involving React components, Next.js pages, dataβ¦
881K installsnpx skills add https://github.com/vercel-labs/agent-skills --skill vercel-react-best-practicesCoding
Review the changes since a fixed point (commit, branch, tag, or merge-base) along two axes: Standards (does the code follow this repo's documented coding standards?) and Spec (does the code match what the originating issue/spec asked for?). Runs both reviews in parallelβ¦
866.7K installsnpx skills add https://github.com/mattpocock/skills --skill code-reviewCoding
Use when you need to resolve an in-progress git merge/rebase conflict.
551.2K installsnpx skills add https://github.com/mattpocock/skills --skill resolving-merge-conflicts
Skills are shared by members and not reviewed by us. Read a skillβs code before you install it.