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/grill/SKILL.md

@@ -0,0 +1,83 @@
+---
+name: grill
+description: >
+  Calibrated interrogation to stress-test a fuzzy plan, design, or architecture before writing a spec or code.
+  Asks one question at a time with recommended answers to extract concrete goals (§G) and constraints (§C).
+  Use when asked to "grill me", "stress-test this", "challenge my plan", or before authoring a spec.
+concerns: [system-one-balance]
+---
+
+# Grill — Calibrated Plan Stress-Testing
+
+Drags ambiguity into concrete goals (§G) and constraints (§C) *before* execution begins. A bad assumption caught here costs one question; caught later, it costs an architectural refactor.
+
+---
+
+## Phase 0: Setup and Protocols
+
+1. **Interrogation Invariants**:
+   - **One Question at a Time**: Never ask multiple questions in a single turn. Ask one question, provide a recommended answer, and wait.
+   - **Recommend an Answer**: Always provide a concrete default so the user can reply with "yes" or choose an alternative.
+   - **Inspect Context First**: If an answer can be found in files, code, docs, or git history, inspect them directly instead of asking the user.
+   - **Propose, Don't Decide**: Challenge tradeoffs and surface hidden edge cases, but leave final product choices to the user.
+
+---
+
+## Phase 1: Ingest and Check
+
+1. Determine user knowledge and desired pressure level from context:
+   - **Knowledge Level**:
+     - *New*: Explain missing frames briefly (2 sentences); focus on first principles and goals.
+     - *Working*: Challenge standard tradeoffs, alternatives, and validation criteria.
+     - *Expert*: Probe failure modes, boundary limits, migration costs, and reversibility.
+   - **Pressure Level**:
+     - *Light*: Clarify goals, scope, and missing definitions.
+     - *Standard*: Challenge assumptions, resource bottlenecks, and execution paths.
+     - *Hard*: Probe edge cases, adverse incentives, failure modes, and rollback mechanisms.
+
+---
+
+## Phase 2: Processing (Core Logic)
+
+Climb the Question Ladder in sequence. Stop as soon as the plan is clear; do not ask every rung by reflex:
+1. **Goal (§G)**: What must the code or feature accomplish in one single, unambiguous sentence?
+2. **Done Criteria (§C / §V)**: What observable signal (test, metric, terminal output) proves this works?
+3. **Boundaries (§C)**: What is explicitly *out of scope* for this change?
+4. **Non-Negotiables (§C)**: What architectural patterns, libraries, or constraints are strictly required or forbidden?
+5. **Surfaces (§I)**: What external membranes (API endpoints, CLI flags, DB tables, schemas) will be modified?
+6. **Failure Modes (§V)**: What is the primary edge case or input that breaks the happy path?
+7. **Unknowns (`?`)**: What do we not yet know? (Park unresolved items as `?` bullets; do not guess them).
+
+### Question Format
+```text
+Question: ...
+Recommended answer: ...
+Why it matters: [1 sentence rationale]
+```
+
+---
+
+## Phase 3: The System One Balance Pass
+
+- **Augment, Don't Handcuff**:
+  - Stop grilling immediately once the goal and boundaries are defined.
+  - Never interrogate the user on routine file edits, typo fixes, or straightforward tasks.
+  - Accept the user's recommended answer or override without debate.
+
+---
+
+## Phase 4: Output Execution & Verification
+
+Stop grilling when **all** of the following hold:
+- §G is one line, one reading, zero "or maybe".
+- §C covers every non-negotiable stated or implied.
+- Every blocking unknown is answered or parked as an explicit `?`.
+
+Emit the structured handoff block to pass to the **spec** or **build** workflow:
+```markdown
+## Grill Handoff
+- **§G**: [One-line goal]
+- **§C**: [Constraints and non-negotiables]
+- **§I**: [Surfaces touched]
+- **Parked Unknowns (`?`)**: [Items deferred to research]
+```