caveman--caveman-review

Generates one-line code review comments with location, severity, problem, and fix.

Updated Dec 3, 2025
One-click install
npx skills add https://github.com/hhenrichsen/dots --skill caveman-caveman-review-hhenrichsen
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: caveman--caveman-review
Source: https://github.com/hhenrichsen/dots/tree/main/dot_skills/caveman/caveman-review
Command: npx skills add https://github.com/hhenrichsen/dots --skill caveman-caveman-review-hhenrichsen

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Code review comments often bury the actual finding under hedging, filler phrases, and restatements of the diff, slowing down both reviewers and PR authors. This Skill produces terse, actionable review comments that state the location, problem, and concrete fix in a single line. ## Core Features & Use Cases - Compressed comment format: Outputs findings as L<line>: <severity> <problem>. <fix>. with optional severity emoji (bug, risk, nit, question). - Anti-hedging rules: Strips phrases like "I noticed that..." and "you might want to consider" while keeping exact line numbers, backticked symbols, and concrete fixes. - Auto-clarity mode: Switches to full paragraphs for CVE-class security findings, architectural disagreements, and onboarding contexts, then resumes terse output. - Use Case: Paste a pull request diff and ask for a review; receive paste-ready one-line comments like L42: bug: user can be null after .find(). Add guard before .email. ## Quick Start Ask the AI to review this PR diff using caveman-review and output one-line findings with severity, problem, and fix.

Frequently Asked Questions about caveman--caveman-review

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I write concise code review comments on a pull request?▼

Use a one-line format stating the line number, severity, problem, and fix, such as `L42: bug: user can be null after .find(). Add guard before .email.` Drop hedging phrases and restatements of the diff so each comment is immediately actionable.

How to categorize severity in code review feedback?▼

Classify findings into four levels: bug for broken behavior that will cause incidents, risk for fragile code like races or missing null checks, nit for style issues the author can ignore, and question for genuine inquiries rather than disguised suggestions.

When should code review comments be detailed instead of terse?▼

Write full paragraphs for CVE-class security findings that need explanation and references, architectural disagreements requiring rationale, and onboarding contexts where a new author needs the reasoning. Resume one-line comments for routine findings.

Does this code review approach approve or request changes on PRs?▼

No, it only generates review comments ready to paste into the pull request. It does not approve, request changes, write code fixes, or run linters; those decisions remain with the human reviewer.

What are the limitations of one-line code review comments?▼

Terse comments lack context for complex security vulnerabilities, design disagreements, and junior developers who need explanations. The format works best for mechanical findings like null checks, missing retries, and function-length issues.