AGENT SKILL

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

  1. Get the diff. Run git diff <base>...HEAD if reviewing a branch, or git diff --cached if reviewing staged changes. If the user passed a specific PR number, use gh pr diff <n>.

  2. 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.

  3. 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.
  4. Write the findings. One per real issue. Do not pad. Do not duplicate.

  5. 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 🔴 critical for 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

04 同仓库更多 Skills

Wizarck
Wizarck/ai-playbook

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.

★ 6
Wizarck
Wizarck/ai-playbook

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.

★ 6
Wizarck
Wizarck/ai-playbook

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.

代码审查
★ 6
Wizarck
Wizarck/ai-playbook

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.

★ 6
Wizarck
Wizarck/ai-playbook

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.

★ 6
Wizarck
Wizarck/ai-playbook

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.

★ 6