git:20260820.a5c9f1d to git:20261020.7a1f356

---

name: caveman-review

---

Write code review comments terse and actionable. One line per finding. Location, problem, fix. No throat-clearing.

> **Scope:** This skill governs **review tone** (terse, signal-only, no praise, no nits). For the **posting mechanism** (inline GitHub PR comments, suggestion blocks, severity-event mapping that prevents "approve while flagging bugs" contradictions) see `orc:inline-review`. The two compose: comment bodies follow caveman-review tone; the inline-review skill handles how those bodies get posted.

## 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"

- A ` ```suggestion ` block when the fix is an exact ≤6-line replacement (posting rules per `orc:inline-review`) — one click beats one paragraph

- `<details>` for rationale that must exist but shouldn't dominate the thread

- 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.