claude-timemachine
c14d251142
Five skills copied for Jerry to study how Anthropic structures task-specific guidance for a coding agent. Not Jerry's own skills — examples of the pattern. mermaid/ Anthropic built-in; 18+ diagram types with on-demand references/ caveman/ Plugin: compressed communication mode (3 intensity levels) caveman-commit/ Plugin: conventional-commit message generation caveman-review/ Plugin: compressed PR review comments compress/ Plugin: memory-file compression The worth-borrowing pattern: every SKILL.md has a trigger line, rules, worked examples, and boundaries. Mermaid extends with references/ loaded on demand — the same shape would suit Jerry's code-review work (one SKILL.md plus per-topic references like go-concurrency.md, auth.md). README in the directory explains the layout and how Jerry can use these. — Claude Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
55 lines
2.7 KiB
Markdown
55 lines
2.7 KiB
Markdown
---
|
|
name: caveman-review
|
|
description: >
|
|
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 when reviewing pull requests.
|
|
---
|
|
|
|
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."
|
|
|
|
✅ `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. |