skills.rest
derrik-fleming
derrik-flemingCOMMUNITY
Explore all skills by this author →
GitHub

caveman-review

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

Updated Jul 23, 2025
Search Tags:#code review#feedback#pull request#diff#severity#terse#review comments
One-click install
npx skills add https://github.com/derrik-fleming/dotfiles --skill caveman-review-derrik-fleming
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: caveman-review
Source: https://github.com/derrik-fleming/dotfiles/tree/main/private_dot_agents/skills/caveman-review
Command: npx skills add https://github.com/derrik-fleming/dotfiles --skill caveman-review-derrik-fleming

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Pull request feedback often drowns in hedging, filler phrases, and restated code, making reviewers slow to write and authors slow to act. This Skill compresses every review finding into a single actionable line so feedback stays dense and readable. ## Core Features & Use Cases - One-line findings: Each comment follows the format 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 severity 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 receives paste-ready comments like auth.py:L42: 🔴 bug: user can be null after .find(). Add guard before .email. ## Quick Start Ask the AI 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 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, restated code, and per-comment praise to keep feedback dense.

How to categorize severity in pull request review comments?▼

Prefix each finding with a severity tag: 🔴 bug for broken behavior, 🟡 risk for fragile code like missing null checks, 🔵 nit for style issues, and ❓ q for genuine questions. Use prefixes only when severities are mixed in one review.

When should code review feedback not be terse?▼

Terse one-liners are wrong for security findings needing CVE-class explanation, architectural disagreements requiring rationale, and reviews for new team members who need the reasoning. Write a normal paragraph for those, then resume terse style.

Does this review style write the code fixes or approve PRs?▼

No. It only outputs review comments ready to paste into the pull request. It does not write code fixes, approve or request changes, or run linters; those remain the reviewer's and author's responsibilities.

What phrases should be removed from PR review comments?▼

Remove openers like "I noticed that", hedges like "perhaps" or "you might want to consider", per-comment praise, and restatements of what the code does. Replace uncertainty with a question tag and vague suggestions with concrete fixes.

Related Skills

Explore More Software Engineering Skills→
bossjonesbossjones
1

fetch-diff

Fetch GitHub pull request diffs with line numbers and file filtering.

Community
Advanced
real-casereal-case

pr-review

Reviews GitHub pull request diffs and posts inline comments with a summary review.

Community
Intermediate
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