---
id: daily-caveman-review
name: "caveman-review"
url: https://skills.yangsir.net/skill/daily-caveman-review
author: juliusbrussee
domain: ai-code-generation-quality
tags: ["code-review", "quality-assurance", "testing", "automation", "devops"]
install_count: 96000
rating: 4.70 (3 reviews)
github: https://github.com/juliusbrussee/caveman
---

# caveman-review

> 生成简洁可执行的代码审查评论，一行一个发现，包含位置、问题和修复方案

**Stats**: 96,000 installs · 4.7/5 (3 reviews)

## Before / After 对比

### 代码审查效率

**Before**:

手动编写代码审查评论，组织语言说明问题，担心语气过于生硬，一个PR需要30-45分钟完成审查

**After**:

自动生成标准化的简洁评论，直接指出行号、问题和修复方案，10分钟完成完整审查

| Metric | Before | After | Change |
|---|---|---|---|
| 审查时间 | 40分钟 | 10分钟 | -75% |

## Readme

# caveman-review

Write code review comments terse and actionable. One line per finding. Location, problem, fix. No throat-clearing.

## Rules

**Format:** `L<line>: <problem>. <fix>.` — or `<file>:L<line>: ...` when reviewing multi-file diffs.

**Severity prefix (optional, when mixed):**

- `🔴 bug:` — broken behavior, will cause incident

- `🟡 risk:` — works but fragile (race, missing null check, swallowed error)

- `🔵 nit:` — style, naming, micro-optim. Author can ignore

- `❓ q:` — genuine question, not a suggestion

**Drop:**

- "I noticed that...", "It seems like...", "You might want to consider..."

- "This is just a suggestion but..." — use `nit:` instead

- "Great work!", "Looks good overall but..." — say it once at the top, not per comment

- Restating what the line does — the reviewer can read the diff

- Hedging ("perhaps", "maybe", "I think") — if unsure use `q:`

**Keep:**

- Exact line numbers

- Exact symbol/function/variable names in backticks

- Concrete fix, not "consider refactoring this"

- The *why* if the fix isn't obvious from the problem statement

## Examples

❌ "I noticed that on line 42 you're not checking if the user object is null before accessing the email property. This could potentially cause a crash if the user is not found in the database. You might want to add a null check here."

✅ `L42: 🔴 bug: user can be null after .find(). Add guard before .email.`

❌ "It looks like this function is doing a lot of things and might benefit from being broken up into smaller functions for readability."

✅ `L88-140: 🔵 nit: 50-line fn does 4 things. Extract validate/normalize/persist.`

❌ "Have you considered what happens if the API returns a 429? I think we should probably handle that case."

✅ `L23: 🟡 risk: no retry on 429. Wrap in withBackoff(3).`

## Auto-Clarity

Drop terse mode for: security findings (CVE-class bugs need full explanation + reference), architectural disagreements (need rationale, not just a one-liner), and onboarding contexts where the author is new and needs the "why". In those cases write a normal paragraph, then resume terse for the rest.

## Boundaries

Reviews only — does not write the code fix, does not approve/request-changes, does not run linters. Output the comment(s) ready to paste into the PR. "stop caveman-review" or "normal mode": revert to verbose review style.
Weekly Installs13.6KRepository[juliusbrussee/caveman](https://github.com/juliusbrussee/caveman)GitHub Stars24.5KFirst Seen5 days agoSecurity Audits[Gen Agent Trust HubPass](/juliusbrussee/caveman/caveman-review/security/agent-trust-hub)[SocketPass](/juliusbrussee/caveman/caveman-review/security/socket)[SnykWarn](/juliusbrussee/caveman/caveman-review/security/snyk)Installed oncursor10.5Kgithub-copilot10.2Kopencode9.0Kcodex8.8Kcline8.5Kantigravity8.5K

---
*Source: https://skills.yangsir.net/skill/daily-caveman-review*
*Markdown mirror: https://skills.yangsir.net/api/skill/daily-caveman-review/markdown*