An agent skill that reviews a pull request like a trusted staff+ engineer — thorough across eight pillars, ruthless about signal, and always ends in an explicit merge call.
AI code review has a noise problem: ask a model to "review this PR" and you get a wall of pedantic
nitpicks, invented edge cases, and reflexive "add a test for this" comments — the stuff a real staff
engineer would never bring to a review. code-crit is built against a stricter law: never
manufacture a finding to look diligent, and never go quiet on a real observation. Uncertainty isn't
suppressed — it's surfaced as a question, because "I can't verify this is non-null — is that
guaranteed?" is exactly the comment a good reviewer leaves.
- A verdict — ✅ Approve, 💬 Comment, or ⛔ Request changes. No hedging.
- A scorecard — eight pillars, each scored 1–100, plus a holistic overall merge-confidence score.
- Findings by severity — Blocking → Important → Questions → Nits, impact-first, each with a file:line, a certainty tag, and a concrete fix.
- What's good — a real reviewer acknowledges solid work, briefly, without flattery.
That verdict is the point. A pile of comments with no call is just noise; a verdict with a scorecard behind it is a decision you can act on.
| Pillar | What it checks |
|---|---|
| Correctness | Does it do what it claims, without bugs or logic errors? |
| Maintainability | Clear structure, modularity, sound design — easy to change later. |
| Readability | Legible, consistently styled, commented only where the why isn't obvious. |
| Efficiency | No needless performance or resource cost introduced. |
| Security | Real, reachable vulnerabilities — not generic hardening advice. |
| Edge cases & error handling | Failure modes, boundaries, and errors handled appropriately. |
| Testability | Covered appropriately for this project's test culture — never a reflexive demand. |
| Standards compliance | Judged against the repo's OWN conventions first; the user's global standards only fill the gaps on their own projects. |
Each pillar runs as its own specialist subagent in parallel, scored independently against the same rubric — so the overall verdict is built from eight defensible judgments, not one model's single pass.
0. Locate the PR → gh pr view/diff, or fall back to a branch diff if there's no PR
1. Build a calibration profile → stakes, test culture, whose conventions govern (repo's own > user's global)
2. Launch the pillar panel → one subagent per applicable pillar, in parallel
3. Synthesize → dedupe, cut noise, keep doubt, rank by severity
4. Present the report → verdict + scorecard, then findings by severity
5. Post to the PR → same report, as a new PR comment
6. Follow up → fix the blockers, address the comments, or ship it
The calibration step is what keeps the bar honest: a work repo gets judged on its own conventions
(its CLAUDE.md/AGENTS.md, lint config, existing patterns), and only where a personal project is
silent does it fall back to the user's own documented standards. The repo's own bar always wins.
npx skills add dannyjpwilliams/code-critThen trigger it by asking to "crit this PR", "code review this", "review my code", "staff review", "is this ready to merge", or any request for a thorough review before merging.
examples/ contains a small illustrative sample PR and a full example review —
the scorecard, the findings by severity, and the verdict — so you can see the exact shape of the
output before running it on your own PR.
The single biggest failure mode of AI code review is dishonesty in both directions: fabricating
issues to look thorough, or staying quiet to seem easygoing. code-crit treats both as failures.
Genuine uncertainty gets its own severity lane (questions) instead of being dropped or dressed up as
a confident bug claim, and pedantry a linter already owns never makes it into the report at all. The
result is a review that says less, but everything it says is worth reading.
MIT © Danny Williams