skills.rest
CliffVale
CliffValeCOMMUNITY
Explore all skills by this author →
GitHub

caveman-review

Generates terse one-line code review comments with severity prefixes for pull request diffs.

1|Updated Aug 24, 2026
Search Tags:#code review#feedback#pull request#github#diff#severity#review comments
One-click install
npx skills add https://github.com/CliffVale/opencode-free-setup --skill caveman-review-cliffvale
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: caveman-review
Source: https://github.com/CliffVale/opencode-free-setup/tree/main/skills/caveman-review
Command: npx skills add https://github.com/CliffVale/opencode-free-setup --skill caveman-review-cliffvale

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Pull request feedback is often buried in verbose, hedged prose that obscures the actionable point. This Skill compresses code review comments into single lines containing the location, problem, and fix, so reviewers communicate faster and authors act immediately. ## Core Features & Use Cases - One-line comment format: Every finding follows the pattern L<line>: <problem>. <fix>. with exact line numbers and symbol names in backticks. - Severity prefixes: Optional emoji tags distinguish bugs (🔴), risks (🟡), nits (🔵), and genuine questions (❓) when feedback is mixed. - Auto-clarity fallback: Security findings, architectural disagreements, and onboarding contexts automatically revert to full explanatory paragraphs. - Use Case: A reviewer pastes a multi-file diff and asks for a review; the Skill outputs paste-ready comments like api/users.go:L42: 🔴 bug: user can be nil after Find(). Add guard before .Email. ## Quick Start Review this pull request diff and give me terse one-line comments with severity tags for each finding.

Frequently Asked Questions about caveman-review

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

FAQPage Schema
How do I write shorter code review comments?▼

Use a fixed one-line format: line number, the problem, and the concrete fix, such as `L42: user can be null after .find(). Add guard before .email.` Drop hedging phrases like "I noticed" or "you might want to consider" and restating what the code does.

How to categorize code review feedback by severity?▼

Prefix each comment with a severity tag: 🔴 bug for broken behavior, 🟡 risk for fragile code like missing null checks or swallowed errors, 🔵 nit for style issues the author can ignore, and ❓ q for genuine questions rather than disguised suggestions.

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

Security findings, architectural disagreements, and reviews for new team members need full explanations with rationale and references. Terse one-liners work for routine bugs, risks, and style nits where the fix is obvious from the problem statement.

Does this review style write the code fixes for me?▼

No. It only outputs review comments ready to paste into a pull request. It does not write the fix, approve or request changes on the PR, or run linters against the code.

What makes a code review comment actionable?▼

Actionable comments include the exact line number, the specific symbol or function name in backticks, and a concrete fix rather than vague advice like "consider refactoring." Include the reasoning only when the fix is not obvious from the problem.

Related Skills

Explore More Software Engineering Skills→
DDTullyDDTully

caveman-review

Generate one-line code review findings with location, problem, and fix.

Community
Intermediate
jhlee0409jhlee0409
7

afc:pr-comment

Post severity-categorized review comments to GitHub Pull Requests.

Community
Advanced
Open-PawsOpen-Paws
3

code-review

Automate layered code review for pull requests in CI pipelines.

Official
Advanced
stacklokstacklok
2.0k

pr-inline-review

Submit inline review comments and code suggestions to GitHub Pull Requests via gh CLI.

Official
Intermediate