Skip to main content

caveman-review

Compressed code review - one line per finding with location, problem and fix. Use for /caveman-review, "review this PR", or "review the diff".

Datos de origen

Repositorio
kimtth/craft-zen-token-optimizer
Última actividad en el origen
7 de septiembre de 2026 a las 09:39
Idioma detectado de SKILL.md
inglés
Estrellas
1
Forks
0

Opciones de instalación

De forma predeterminada está seleccionado el prompt que primero revisa el origen. Puedes cambiar a un comando directo o descargar una copia local.

Revisa los archivos de origen

Lee SKILL.md y los archivos complementarios que muestra SkillsMP antes de decidir si quieres instalarlo.

Explorador de archivos
3 archivos

Mostrando SKILL.md

SKILL.md
Instrucciones de origen · Vista previa de solo lectura
name
caveman-review
description
Compressed code review - one line per finding with location, problem and fix. Use for /caveman-review, "review this PR", or "review the diff".
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.
Ver en GitHub