review

Name: review
Author: JuliusBrussee

446installs81forks

How to install review?

juliusbrussee/cavekit/review

$npx -y skills add JuliusBrussee/cavekit --skill review

Installs into the current project.

Summary

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);

Files · 1

View on GitHub

SKILL.md

1	# review — refute the spec before build
2
3	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.
4
5	An LLM cannot self-correct on its own judgment — left alone it drifts or
6	degrades. Review fixes that the only way that works: a separate skeptic
7	anchored to an external oracle — the code, §R, the test suite, the docs.
8	"Looks good" is not a review. A refutation attempt is.
9
10	## WHEN TO REVIEW
11
12	- Before `/build` on a high-blast-radius change (shared module, auth, data, money, public API).
13	- Spec touched §I or §V that other code depends on.
14	- Right-sizing says the cost of a wrong build > the cost of one review pass.
15
16	Skip for a trivial, reversible, well-understood change. Adversarial review on a
17	typo hallucinates flaws & wastes the budget — the self-critique paradox is real.
18
19	## PHASE 0 — CAPTURE
20
21	Read the spec: §G §C §I §R §V §T. Hold the whole thing. You review the spec,
22	not your memory of the conversation.
23
24	## PHASE 1 — CONSTRUCT THE SENIOR
25
26	Build a reviewer with real authority, not a generic critic:
27	- Codebase — grep/read the modules this spec touches. What patterns, what invariants already hold?
28	- §R — what did research establish? A spec decision that contradicts §R is a finding.
29	- Live — for any best-practice claim you are unsure of, fetch it. An out-of-date assumption is a flaw.
30
31	A reviewer with no evidence is just an opinion. Earn the authority first.
32
33	## PHASE 2 — REFUTE
34
35	Attack the spec on these axes. For each, try to find the case where it breaks:
36	- Goal vs reality — does §G solve the actual problem, or a proxy?
37	- Missing invariant — what can go wrong that no §V catches? (most findings live here)
38	- Interface drift — does §I match what callers already expect? (cite the caller, file:line)
39	- Constraint conflict — do two §C bullets contradict? does one fight §R?
40	- Unowned edge — the input, ordering, failure, or concurrency case no §T covers.
41	- Altitude — §T too vague to act on, or so granular it is just typing?
42
43	## PHASE 3 — CLASSIFY
44
45	Each finding: `evidence → claim → severity`.
46	- BLOCK — build on this spec ships a real defect. Must fix first.
47	- HARDEN — add/sharpen a §V so the build cannot regress it.
48	- NOTE — worth knowing, not blocking.
49
50	No evidence? Down-rank to NOTE & tag `[unverified]`. ⊥ inflate a hunch to BLOCK.
51
52	## PHASE 4 — HARDEN §V & GATE
53
54	- Each HARDEN finding → a draft §V line (testable, cites the §I/behavior it guards). Hand to spec to write.
55	- End on an explicit gate:
56
57	```
58	## review verdict
59	BLOCK: 1 — §I.api shape ≠ caller src/client.ts:40. fix §I before build.
60	HARDEN: 2 — drafted V8 (idempotent refund), V9 (tx around dual write).
61	NOTE: 1 — §T4 vague, split before /build.
62	gate: NO-GO until BLOCK cleared. then /build §T after spec writes V8,V9.
63	```
64
65	GO or NO-GO, never a shrug. Review is the checkpoint that stops a confident wrong build.
66
67	## BOUNDARIES
68
69	- ⊥ write SPEC.md. Draft §V & hand to spec.
70	- ⊥ pass a finding with no evidence as fact. Flag `[unverified]`.
71	- ⊥ review trivia. Right-size or skip.
72	- ⊥ rewrite the user's intent. You harden the spec, you do not replace its goal.

People who liked this also viewed

6 picks

Type

review

446installs81forks

View on GitHub

How to install review?

juliusbrussee/cavekit/review

$npx -y skills add JuliusBrussee/cavekit --skill review

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# review — refute the spec before build
2
3	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.
4
5	An LLM cannot self-correct on its own judgment — left alone it drifts or
6	degrades. Review fixes that the only way that works: a separate skeptic
7	anchored to an external oracle — the code, §R, the test suite, the docs.
8	"Looks good" is not a review. A refutation attempt is.
9
10	## WHEN TO REVIEW
11
12	- Before `/build` on a high-blast-radius change (shared module, auth, data, money, public API).
13	- Spec touched §I or §V that other code depends on.
14	- Right-sizing says the cost of a wrong build > the cost of one review pass.
15
16	Skip for a trivial, reversible, well-understood change. Adversarial review on a
17	typo hallucinates flaws & wastes the budget — the self-critique paradox is real.
18
19	## PHASE 0 — CAPTURE
20
21	Read the spec: §G §C §I §R §V §T. Hold the whole thing. You review the spec,
22	not your memory of the conversation.
23
24	## PHASE 1 — CONSTRUCT THE SENIOR
25
26	Build a reviewer with real authority, not a generic critic:
27	- Codebase — grep/read the modules this spec touches. What patterns, what invariants already hold?
28	- §R — what did research establish? A spec decision that contradicts §R is a finding.
29	- Live — for any best-practice claim you are unsure of, fetch it. An out-of-date assumption is a flaw.
30
31	A reviewer with no evidence is just an opinion. Earn the authority first.
32
33	## PHASE 2 — REFUTE
34
35	Attack the spec on these axes. For each, try to find the case where it breaks:
36	- Goal vs reality — does §G solve the actual problem, or a proxy?
37	- Missing invariant — what can go wrong that no §V catches? (most findings live here)
38	- Interface drift — does §I match what callers already expect? (cite the caller, file:line)
39	- Constraint conflict — do two §C bullets contradict? does one fight §R?
40	- Unowned edge — the input, ordering, failure, or concurrency case no §T covers.
41	- Altitude — §T too vague to act on, or so granular it is just typing?
42
43	## PHASE 3 — CLASSIFY
44
45	Each finding: `evidence → claim → severity`.
46	- BLOCK — build on this spec ships a real defect. Must fix first.
47	- HARDEN — add/sharpen a §V so the build cannot regress it.
48	- NOTE — worth knowing, not blocking.
49
50	No evidence? Down-rank to NOTE & tag `[unverified]`. ⊥ inflate a hunch to BLOCK.
51
52	## PHASE 4 — HARDEN §V & GATE
53
54	- Each HARDEN finding → a draft §V line (testable, cites the §I/behavior it guards). Hand to spec to write.
55	- End on an explicit gate:
56
57	```
58	## review verdict
59	BLOCK: 1 — §I.api shape ≠ caller src/client.ts:40. fix §I before build.
60	HARDEN: 2 — drafted V8 (idempotent refund), V9 (tx around dual write).
61	NOTE: 1 — §T4 vague, split before /build.
62	gate: NO-GO until BLOCK cleared. then /build §T after spec writes V8,V9.
63	```
64
65	GO or NO-GO, never a shrug. Review is the checkpoint that stops a confident wrong build.
66
67	## BOUNDARIES
68
69	- ⊥ write SPEC.md. Draft §V & hand to spec.
70	- ⊥ pass a finding with no evidence as fact. Flag `[unverified]`.
71	- ⊥ review trivia. Right-size or skip.
72	- ⊥ rewrite the user's intent. You harden the spec, you do not replace its goal.

People who liked this also viewed

6 picks

Type