feat(skills): import Spec-Driven Development (SDD) suite

- 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

skills/review/SKILL.md

@@ -0,0 +1,88 @@
+---
+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]
+```