vasily
5a19e1cd9d
- Add grill: calibrated plan stress-testing before speccing - Add spec: sole mutator of SPEC.md with format specification - Add caveman: token-compression dialect for invariants and tasks - Add review: adversarial pre-implementation refutation of spec - Add build: single-threaded plan-to-execute loop with external oracles - Add check: read-only drift detector comparing code vs invariants - Add backprop: bug-to-spec feedback loop binding regression tests - Add deepen: complexity reduction and interface shrinking pass - Format all skills to 5-phase Skill Architect anatomy with System One balance - Synchronize symlinks across OpenCode, Codex, and Claude Code
89 lines
3.3 KiB
Markdown
89 lines
3.3 KiB
Markdown
---
|
|
name: review
|
|
description: >
|
|
Adversarial pre-implementation review of SPEC.md. Attempts to refute the spec before code is written,
|
|
grounding findings in codebase evidence, §R research, and current best practices.
|
|
Use when asked to "review spec", "red-team spec", "is this plan sound", or before high-blast-radius builds.
|
|
concerns: [system-one-balance]
|
|
---
|
|
|
|
# Review — Refute the Spec Before Build
|
|
|
|
Every finding cites evidence — `file:line` or an authoritative source. No evidence → label `[unverified]`. A defect you cannot prove is a note, not a blocker.
|
|
|
|
---
|
|
|
|
## Phase 0: Setup and Protocols
|
|
|
|
1. Review governing invariants:
|
|
- Review the *spec*, not conversational memory.
|
|
- An LLM cannot self-correct reliably on vibes alone; the reviewer must anchor to external oracles (code, tests, §R).
|
|
- Skip review for trivial, reversible edits; right-size review effort to blast radius.
|
|
|
|
---
|
|
|
|
## Phase 1: Ingest and Check
|
|
|
|
1. **Capture the Spec**:
|
|
- Ingest all active sections of `SPEC.md`: §G, §C, §I, §R, §V, §T, §B.
|
|
2. **Construct the Reviewer Profile**:
|
|
- Inspect the codebase modules touched by the spec to verify existing patterns and constraints.
|
|
- Check §R research findings: any spec assertion contradicting §R is an immediate finding.
|
|
- For unverified best-practice assumptions, verify them before citing.
|
|
|
|
---
|
|
|
|
## Phase 2: Processing (Core Logic)
|
|
|
|
### Step 1: Adversarial Refutation
|
|
Attempt to refute the spec along these axes:
|
|
- **Goal vs. Reality**: Does §G address the actual requirement or a proxy?
|
|
- **Missing Invariants**: What failure mode exists that no §V catches?
|
|
- **Interface Drift**: Does §I match what existing callers in the codebase expect? Cite caller `file:line`.
|
|
- **Constraint Conflicts**: Do two bullets in §C contradict each other or violate §R?
|
|
- **Unowned Edges**: What concurrency, ordering, or failure scenario has no assigned §T?
|
|
- **Altitude Check**: Are tasks in §T too vague to verify, or overly granular?
|
|
|
|
### Step 2: Classify Findings
|
|
Assign findings to three explicit categories:
|
|
- **BLOCK**: High risk of shipping a real defect. Must be resolved before building.
|
|
- **HARDEN**: Add or sharpen a §V invariant so build cannot regress it.
|
|
- **NOTE**: Worth noting for future consideration; non-blocking.
|
|
|
|
*Any claim lacking codebase or documentation evidence is down-ranked to NOTE and tagged `[unverified]`.*
|
|
|
|
### Step 3: Draft §V Amendments
|
|
- Translate each HARDEN finding into a testable §V draft line citing the interface or behavior guarded.
|
|
|
|
---
|
|
|
|
## Phase 3: The System One Balance Pass
|
|
|
|
- **Augment, Don't Handcuff**:
|
|
- Never review trivia or low-risk tasks (typos, minor styling, internal helper adjustments).
|
|
- Never fabricate synthetic BLOCK findings to look thorough; if the spec holds, issue an immediate GO verdict.
|
|
- Review hardens the spec; it does NOT alter user intent or product direction.
|
|
|
|
---
|
|
|
|
## Phase 4: Output Execution & Verification
|
|
|
|
Emit the review verdict and go/no-go gate:
|
|
|
|
```markdown
|
|
## Review Verdict
|
|
|
|
### BLOCK (must resolve before build)
|
|
- [B1] Finding — evidence (file:line or doc citation) — remedy.
|
|
|
|
### HARDEN (drafted §V invariants)
|
|
- [H1] Draft V<N>: <testable invariant guarding behavior>
|
|
|
|
### NOTE
|
|
- [N1] Finding [unverified] — suggestion.
|
|
|
|
### Gate
|
|
- **Verdict**: [GO | NO-GO]
|
|
- **Next Step**: [If NO-GO: resolve BLOCKs via spec; If GO: proceed to /build]
|
|
```
|