caveman-review
Use when the user wants a pull-request review delivered as one-line comments with severity emoji, line references, and direct fix suggestions instead of paragraphs.
- License 许可
- MIT
- 最近更新
- 2026-11-09
- Stars
- ★ 6
- Forks
- 1
01 前言 Front Matter
- name
- caveman-review
- license
- MIT
- metadata
- { "author": "ai-playbook (ported from JuliusBrussee/caveman, MIT)", "version": "1.0" }
- description
- Use when the user wants a pull-request review delivered as one-line comments with severity emoji, line references, and direct fix suggestions instead of paragraphs.
03 SKILL.md 正文
caveman-review — one-line PR review
Review a diff or a small set of files and emit one finding per line, in a fixed shape.
When to fire
User intent triggers (any of):
- "/caveman-review"
- "review this PR", "review the diff", "review my changes"
- "what's wrong with this code", "give me a one-line review"
Output contract
One finding per line, no preamble, no summary at the end. Exact shape:
<path>:<line>: <severity> <category>: <problem>. <fix>.
<severity>∈🔴 critical|🟠 high|🟡 medium|🟢 low|💬 nit.<category>∈bug|security|perf|correctness|style|test|doc.<problem>≤ 50 chars, caveman voice (drop articles, fragments OK).<fix>≤ 50 chars, imperative voice.- Sort: severity descending, then path, then line.
- If nothing is wrong: emit the single line
LGTM. No issues found.
Steps
-
Get the diff. Run
git diff <base>...HEADif reviewing a branch, orgit diff --cachedif reviewing staged changes. If the user passed a specific PR number, usegh pr diff <n>. -
Refuse if too large. If the diff exceeds ~400 lines or touches more than 5 files, emit
OUT_OF_SCOPE: diff too large (<lines>L, <files>F), split first.and stop. -
Walk every changed line. For each line, ask:
- Does this introduce a bug?
- Does this open a security hole (injection, missing auth check, leaked secret)?
- Does this regress performance (N+1 query, unbounded loop, sync I/O in hot path)?
- Is correctness obvious (off-by-one, missing null guard, wrong comparison)?
- Is the test coverage adequate for the change?
- Are docs out of date with the change?
- Style nits ONLY if they break the project's existing style.
-
Write the findings. One per real issue. Do not pad. Do not duplicate.
-
Output. Just the lines. No "Here's my review:". No "Hope this helps." No closing remark.
Trust boundary
- Do not invent issues to look thorough. Empty result is acceptable; emit
LGTM. No issues found. - Do not post the review to GitHub. The skill drafts; the user posts.
- Do not mark
🔴 criticalfor style or nit issues. Reserve that severity for actual production-breaking risks.
Examples
scripts/caveman/toggle.py:42: 🔴 critical bug: race on flag write. Use temp+rename.
scripts/caveman/cli.py:88: 🟠 high security: shell=True with user input. Use list args.
scripts/caveman/mcp_shrink.py:120: 🟡 medium correctness: silent ignore of error. Log and raise.
tests/test_caveman_toggle.py:30: 🟢 low test: only happy path covered. Add schema-fail case.
docs/runbooks/caveman-toggle.md:55: 💬 nit doc: stale path reference. Update to new location.
See also
- skills/caveman/SKILL.md — base caveman ruleset.
- skills/caveman/agents/cavecrew-reviewer.md — subagent version for batched review.
04 同仓库更多 Skills
sweep
Use when the user wants to find code that has quietly stopped being used — types /sweep, asks for a "dead code sweep", "repo entropy", "what can we delete", "orphan files", "unused code", or asks to review a sweep ledger. Adjudicates candidates a deterministic scanner already produced; it never deletes anything and never re-derives findings from raw source. Pairs with ponytail, which gates what gets written rather than what rots.
ponytail
Use when the user wants the laziest solution that actually works — types /ponytail, says "be lazy", "lazy mode", "simplest solution", "minimal solution", "yagni", "do less", or "shortest path", or complains about over-engineering, bloat, boilerplate, or unnecessary dependencies. Supports intensity levels lite, full, ultra (default). Pairs with caveman, which compresses prose, not code.
ponytail-review
Use when the user wants a code review focused exclusively on over-engineering — says "review for over-engineering", "what can we delete", "is this over-engineered", "simplify review", or invokes /ponytail-review. Complements correctness/security review; this one only hunts complexity in the current diff. Gated by the ponytail review_ponytail component.
ponytail-debt
Use when the user wants to harvest every `ponytail:` comment in the codebase into a tracked debt ledger — says "ponytail debt", "/ponytail-debt", "what did ponytail defer", "list the shortcuts", "ponytail ledger", or "what did we mark to do later". One-shot report, changes nothing. Gated by the ponytail debt_ponytail component.
ponytail-audit
Use when the user wants a whole-repo audit for over-engineering — says "audit this codebase", "audit for over-engineering", "what can I delete from this repo", "find bloat", or invokes /ponytail-audit. Like ponytail-review but scans the entire tree, not a diff. One-shot report, applies no fixes. Gated by the ponytail audit_ponytail component.
openspec-propose
Propose a new change with all artifacts generated in one step. Use when the user wants to quickly describe what they want to build and get a complete proposal with design, specs, and tasks ready for implementation.