caveman-review

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

3|Updated Apr 8, 2025
One-click install
npx skills add https://github.com/ZanzyTHEbar/dragonarchy --skill caveman-review-zanzythebar
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: caveman-review
Source: https://github.com/ZanzyTHEbar/dragonarchy/tree/main/packages/opencode/.config/opencode/skills/caveman-review
Command: npx skills add https://github.com/ZanzyTHEbar/dragonarchy --skill caveman-review-zanzythebar

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Pull request feedback is often buried under hedging, filler phrases, and restated code, forcing authors to dig for the actionable point. This Skill compresses every review comment into a single line containing the location, the problem, and the concrete fix. ## Core Features & Use Cases - One-line findings: Each comment follows the format L<line>: <problem>. <fix>. with optional file prefix for multi-file diffs. - Severity prefixes: Classifies findings as bug, risk, nit, or question so authors can triage feedback at a glance. - Noise filtering: Strips hedging, praise padding, and restatements while keeping exact line numbers, symbol names, and concrete fixes. - Auto-clarity mode: Expands to full paragraphs for security findings, architectural disagreements, and onboarding contexts where rationale matters. - Use Case: Paste a pull request diff and receive paste-ready review comments like L42: bug: user can be null after .find(). Add guard before .email. ## Quick Start Ask the assistant to review this pull request diff using caveman-review and output one-line comments ready to paste into the PR.

Frequently Asked Questions about caveman-review

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

FAQPage Schema
How do I write concise code review comments?

Use a one-line format of location, problem, and fix, such as `L42: user can be null after .find(). Add guard before .email.` Drop hedging phrases and restatements of the code, and keep exact line numbers and symbol names.

How to categorize severity in pull request feedback?

Prefix each finding with a severity label: bug for broken behavior, risk for fragile code like missing null checks or swallowed errors, nit for style issues, and q for genuine questions. This lets authors triage feedback quickly.

When should code review comments be detailed instead of terse?

Use full paragraphs for security findings that need CVE-class explanation, architectural disagreements requiring rationale, and onboarding contexts where a new author needs the reasoning. Resume terse one-liners for everything else.

Does this review style write the code fixes for me?

No. The output is limited to review comments ready to paste into a pull request. It does not write the fix, approve or request changes, or run linters; it only describes the concrete fix the author should apply.

What phrases should be removed from PR review comments?

Remove openers like I noticed that or you might want to consider, hedging words like perhaps and maybe, per-comment praise, and restatements of what the code does. Replace suggestions with a concrete fix or a nit prefix.