caveman-review

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

2|Updated Mar 7, 2025
One-click install
npx skills add https://github.com/AbdelrhmanUZaki/KnowledgeNuggets --skill caveman-review-abdelrhmanuzaki
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: caveman-review
Source: https://github.com/AbdelrhmanUZaki/KnowledgeNuggets/tree/main/2-setup/shared/gemini/config/skills/caveman-review
Command: npx skills add https://github.com/AbdelrhmanUZaki/KnowledgeNuggets --skill caveman-review-abdelrhmanuzaki

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Pull request feedback is often buried in verbose, hedged commentary that obscures the actual issue. This Skill compresses code review comments into single actionable lines, cutting noise while preserving the location, problem, and fix. ## 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: Classifies findings as bug, risk, nit, or question using emoji prefixes so authors can triage feedback at a glance. - Auto-Clarity Mode: Automatically switches to full explanations for security findings, architectural disagreements, and onboarding contexts where rationale matters. - Use Case: When asked to review a multi-file pull request diff, the Skill outputs paste-ready comments like auth.py:L42: bug: user can be null after .find(). Add guard before .email. instead of paragraph-long suggestions. ## Quick Start Ask the AI to review this pull request diff using caveman-review and output one-line comments 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 concise code review comments for a pull request?▼

Use the format `L<line>: <problem>. <fix>.` with exact line numbers and symbol names in backticks. Drop hedging phrases like "you might want to consider" and state the concrete fix directly, one finding per line.

How to categorize code review feedback by severity?▼

Prefix each comment with a severity marker: bug for broken behavior, risk for fragile code like missing null checks, nit for style issues, and q for genuine questions. This lets authors triage feedback without reading every comment fully.

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 self-evident.

Does this code review approach write the fixes automatically?▼

No, it only outputs review comments ready to paste into the PR. It does not write code fixes, approve or request changes, or run linters; the author implements the suggested fixes themselves.

What phrases should be removed from code review feedback?▼

Remove throat-clearing like "I noticed that", hedging like "perhaps" or "maybe", per-comment praise, and restatements of what the code does. Replace uncertainty with a question prefix and keep only the location, problem, and fix.