caveman-review

Name: caveman-review
Author: JuliusBrussee

257kinstalls5.2kforks

How to install caveman-review?

juliusbrussee/caveman/caveman-review

$npx -y skills add JuliusBrussee/caveman --skill caveman-review

Installs into the current project.

Summary

Ultra-compressed code review comments. Cuts noise from PR feedback while preserving the actionable signal. Each comment is one line: location, problem, fix. Use when user says "review this PR", "code review", "review the diff", "/review", or invokes /caveman-review. Auto-triggers

Files · 1

View on GitHub

SKILL.md

1	Write code review comments terse and actionable. One line per finding. Location, problem, fix. No throat-clearing.
2
3	## Rules
4
5	Format: `L<line>: <problem>. <fix>.` — or `<file>:L<line>: ...` when reviewing multi-file diffs.
6
7	Severity prefix (optional, when mixed):
8	- `🔴 bug:` — broken behavior, will cause incident
9	- `🟡 risk:` — works but fragile (race, missing null check, swallowed error)
10	- `🔵 nit:` — style, naming, micro-optim. Author can ignore
11	- `❓ q:` — genuine question, not a suggestion
12
13	Drop:
14	- "I noticed that...", "It seems like...", "You might want to consider..."
15	- "This is just a suggestion but..." — use `nit:` instead
16	- "Great work!", "Looks good overall but..." — say it once at the top, not per comment
17	- Restating what the line does — the reviewer can read the diff
18	- Hedging ("perhaps", "maybe", "I think") — if unsure use `q:`
19
20	Keep:
21	- Exact line numbers
22	- Exact symbol/function/variable names in backticks
23	- Concrete fix, not "consider refactoring this"
24	- The why if the fix isn't obvious from the problem statement
25
26	## Examples
27
28	❌ "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."
29
30	✅ `L42: 🔴 bug: user can be null after .find(). Add guard before .email.`
31
32	❌ "It looks like this function is doing a lot of things and might benefit from being broken up into smaller functions for readability."
33
34	✅ `L88-140: 🔵 nit: 50-line fn does 4 things. Extract validate/normalize/persist.`
35
36	❌ "Have you considered what happens if the API returns a 429? I think we should probably handle that case."
37
38	✅ `L23: 🟡 risk: no retry on 429. Wrap in withBackoff(3).`
39
40	## Auto-Clarity
41
42	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.
43
44	## Boundaries
45
46	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.

People who liked this also viewed

6 picks

Type

caveman-review

257kinstalls5.2kforks

View on GitHub

How to install caveman-review?

juliusbrussee/caveman/caveman-review

$npx -y skills add JuliusBrussee/caveman --skill caveman-review

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	Write code review comments terse and actionable. One line per finding. Location, problem, fix. No throat-clearing.
2
3	## Rules
4
5	Format: `L<line>: <problem>. <fix>.` — or `<file>:L<line>: ...` when reviewing multi-file diffs.
6
7	Severity prefix (optional, when mixed):
8	- `🔴 bug:` — broken behavior, will cause incident
9	- `🟡 risk:` — works but fragile (race, missing null check, swallowed error)
10	- `🔵 nit:` — style, naming, micro-optim. Author can ignore
11	- `❓ q:` — genuine question, not a suggestion
12
13	Drop:
14	- "I noticed that...", "It seems like...", "You might want to consider..."
15	- "This is just a suggestion but..." — use `nit:` instead
16	- "Great work!", "Looks good overall but..." — say it once at the top, not per comment
17	- Restating what the line does — the reviewer can read the diff
18	- Hedging ("perhaps", "maybe", "I think") — if unsure use `q:`
19
20	Keep:
21	- Exact line numbers
22	- Exact symbol/function/variable names in backticks
23	- Concrete fix, not "consider refactoring this"
24	- The why if the fix isn't obvious from the problem statement
25
26	## Examples
27
28	❌ "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."
29
30	✅ `L42: 🔴 bug: user can be null after .find(). Add guard before .email.`
31
32	❌ "It looks like this function is doing a lot of things and might benefit from being broken up into smaller functions for readability."
33
34	✅ `L88-140: 🔵 nit: 50-line fn does 4 things. Extract validate/normalize/persist.`
35
36	❌ "Have you considered what happens if the API returns a 429? I think we should probably handle that case."
37
38	✅ `L23: 🟡 risk: no retry on 429. Wrap in withBackoff(3).`
39
40	## Auto-Clarity
41
42	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.
43
44	## Boundaries
45
46	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.

People who liked this also viewed

6 picks

Type