review
Adversarial senior review of the spec before any code is written. Constructs a skeptical reviewer whose authority comes from the codebase, §R research, and live best-practice — then tries to REFUTE the spec, not rubber-stamp it. Every finding cites evidence (file:line or source); unverifiable ones are flagged. Survivors harden §V; the run ends in an explicit go / no-go gate. Triggers before building anything high-blast-radius, when the user says "review the spec", "red-team this", "is this plan sound", "senior review", or invokes /ck:review.
- Installs
- 791
- Last 24h
- —
- Trending rank
- —
- Security
- Not audited
Install
Works with every agent the skills CLI supports.
npx skills add https://github.com/juliusbrussee/cavekit --skill review- 01
Install
Run the command in your project. The CLI asks which agents to install for.
- 02
Describe the task
Ask your agent for something this skill covers. It loads review automatically when relevant.
- 03
Review the result
The agent follows the SKILL.md steps, scripts and references bundled with the skill.
SKILL.md
The instructions your agent reads when the skill is triggered.
review — refute the spec before build
Every finding cites evidence — file:line or a source. No evidence → flag [unverified]. Default to refuted: a flaw you cannot prove is a flaw you note, not one you wave through.
An LLM cannot self-correct on its own judgment — left alone it drifts or degrades. Review fixes that the only way that works: a separate skeptic anchored to an external oracle — the code, §R, the test suite, the docs. "Looks good" is not a review. A refutation attempt is.
WHEN TO REVIEW
- Before
/buildon a high-blast-radius change (shared module, auth, data, money, public API). - Spec touched §I or §V that other code depends on.
- Right-sizing says the cost of a wrong build > the cost of one review pass.
Skip for a trivial, reversible, well-understood change. Adversarial review on a typo hallucinates flaws & wastes the budget — the self-critique paradox is real.
PHASE 0 — CAPTURE
Read the spec: §G §C §I §R §V §T. Hold the whole thing. You review the spec, not your memory of the conversation.
PHASE 1 — CONSTRUCT THE SENIOR
Build a reviewer with real authority, not a generic critic:
- Codebase — grep/read the modules this spec touches. What patterns, what invariants already hold?
- §R — what did research establish? A spec decision that contradicts §R is a finding.
- Live — for any best-practice claim you are unsure of, fetch it. An out-of-date assumption is a flaw.
A reviewer with no evidence is just an opinion. Earn the authority first.
PHASE 2 — REFUTE
Attack the spec on these axes. For each, try to find the case where it breaks:
- Goal vs reality — does §G solve the actual problem, or a proxy?
- Missing invariant — what can go wrong that no §V catches? (most findings live here)
- Interface drift — does §I match what callers already expect? (cite the caller, file:line)
- Constraint conflict — do two §C bullets contradict? does one fight §R?
- Unowned edge — the input, ordering, failure, or concurrency case no §T covers.
- Altitude — §T too vague to act on, or so granular it is just typing?
PHASE 3 — CLASSIFY
Each finding: evidence → claim → severity.
- BLOCK — build on this spec ships a real defect. Must fix first.
- HARDEN — add/sharpen a §V so the build cannot regress it.
- NOTE — worth knowing, not blocking.
No evidence? Down-rank to NOTE & tag [unverified]. ⊥ inflate a hunch to BLOCK.
PHASE 4 — HARDEN §V & GATE
- Each HARDEN finding → a draft §V line (testable, cites the §I/behavior it guards). Hand to spec to write.
- End on an explicit gate:
## review verdict
BLOCK: 1 — §I.api shape ≠ caller src/client.ts:40. fix §I before build.
HARDEN: 2 — drafted V8 (idempotent refund), V9 (tx around dual write).
NOTE: 1 — §T4 vague, split before /build.
gate: NO-GO until BLOCK cleared. then /build §T after spec writes V8,V9.
GO or NO-GO, never a shrug. Review is the checkpoint that stops a confident wrong build.
BOUNDARIES
- ⊥ write SPEC.md. Draft §V & hand to spec.
- ⊥ pass a finding with no evidence as fact. Flag
[unverified]. - ⊥ review trivia. Right-size or skip.
- ⊥ rewrite the user's intent. You harden the spec, you do not replace its goal.
FAQ
What does the review skill do?
Adversarial senior review of the spec before any code is written. Constructs a skeptical reviewer whose authority comes from the codebase, §R research, and live best-practice — then tries to REFUTE the spec, not rubber-stamp it. Every finding cites evidence (file:line or source); unverifiable ones are flagged. Survivors harden §V; the run ends in an explicit go / no-go gate. Triggers before building anything high-blast-radius, when the user says "review the spec", "red-team this", "is this plan sound", "senior review", or invokes /ck:review.
How do I install review?
Run npx skills add https://github.com/juliusbrussee/cavekit --skill review in your project. The skills CLI detects the agents you use and copies the skill into the right folder. For Claude Code you can also place the skill folder at ~/.claude/skills/review/ (personal) or .claude/skills/review/ (project).
Which AI agents can use review?
Any agent that supports the open Agent Skills format (a folder with a SKILL.md file), including Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI, Windsurf, Cline, OpenCode and more.
Is review safe to install?
No partner security audit is available yet. Skills can run commands and scripts, so read the SKILL.md and any bundled files before installing.
Who maintains review?
It is published by juliusbrussee in juliusbrussee/cavekit. It has 791 recorded installs.
More from juliusbrussee/cavekit
caveman
juliusbrussee/cavekit
Caveman encoding for SPEC.md and spec-adjacent writes. Loaded by /spec, /build, /check. Cuts tokens 75% vs prose while staying precise. Triggers on any write to SPEC.md or when user says "caveman", "compress this", "be brief".
build
juliusbrussee/cavekit
Plan-then-execute implementation against SPEC.md. Native single-thread loop, no sub-agents. On test or build failure, auto-invokes the backprop skill before retrying — a failed verification always considers whether a new §V invariant would prevent recurrence. Triggers when the user asks to build, implement, execute the spec, or tackle a specific §T task (build §T.3, build --next, implement next task, run the build). Expects SPEC.md to exist; if not, defers to the spec skill.
spec
juliusbrussee/cavekit
Create, amend, or backprop bugs into SPEC.md at repo root. Sole mutator of the project spec. Triggers when the user asks to write a spec, start a new spec, distill a spec from existing code, add invariants, amend sections (§G, §C, §I, §V, §T, §B), or record a bug via backprop. Common phrasings: "write the spec for...", "new spec", "bug: ...", "amend §V.3", "distill spec from code", "spec this idea". Reads and follows FORMAT.md for the caveman encoding rules and pipe-table shape of §T and §B.
check
juliusbrussee/cavekit
Read-only drift detector. Diffs SPEC.md against current code and reports violations grouped by severity. Writes nothing — suggests remedies via the spec or build skills but never invokes them. Triggers when the user asks to check drift, audit the spec, verify invariants, or ask whether code still matches the spec. Phrasings: "check drift", "audit the spec", "does the code still match §V", "check invariants", "spec vs code".
backprop
juliusbrussee/cavekit
Bug → spec protocol. When a bug is found or a test fails, trace the cause, decide whether a new §V invariant would catch recurrence, append to §B. This is the one non-obvious thing SDD does that plan-then-execute doesn't. Triggers on test failure, bug report, post-mortem, or explicit user ask.
grill
juliusbrussee/cavekit
Calibrated interrogation of a fuzzy idea before it becomes a spec. Asks one question at a time, recommends an answer, and lands each answer in §G (goal) or §C (constraints) — unknowns parked as ? items, never guessed. The cheapest place to kill a bad idea is before §T exists. Triggers when the user has a vague idea, says "grill me", "stress-test this", "challenge my plan", "interview me before I spec", or invokes /ck:grill. Defers the actual write to the spec skill.
Popular code quality & workflow skills
grill-me
mattpocock/skills
A relentless interview to sharpen a plan or design.
improve-codebase-architecture
mattpocock/skills
Scan a codebase for deepening opportunities, present them as a visual HTML report, then grill through whichever one you pick.
handoff
mattpocock/skills
Compact the current conversation into a handoff document for another agent to pick up.
domain-modeling
mattpocock/skills
Build and sharpen a project's domain model. Use when discussing codebase terminology, writing or editing a GLOSSARY.md, or recording or editing an ADR.
codebase-design
mattpocock/skills
Shared vocabulary for designing deep modules. Use when the user wants to design or improve a module's interface, find deepening opportunities, decide where a seam goes, make code more testable or AI-navigable, or when another skill needs the deep-module vocabulary.
diagnosing-bugs
mattpocock/skills
Diagnosis loop for hard bugs and performance regressions. Use when the user says "diagnose"/"debug this", or reports something broken/throwing/failing/slow.