spec-corelisted

# Spec: Core ## Core Principle **Specs are the source of truth. Code is a derivative.** The rebuild guarantee: if the entire codebase were deleted, reading `specs/` alone must be sufficient to rebuild it to functional equivalence. If a decision, invariant, or rationale exists only in code or in someone's head — the spec is incomplete. ## Autonomous Trigger This skill fires when you are about to write code in a project that has a `specs/` directory but no spec covering the area being touched. **When triggered, you must:** 1. Stop — do not write implementation code 2. Name the gap explicitly: which area has no spec, or which spec is outdated 3. Route to the appropriate operational skill (see Skill Graph below) **The user's instruction to "write code now" does not override this.** Spec-driven projects have this rule precisely because the fastest path to unmaintainable code is skipping specs under time pressure. Surface the gap, name the skill needed, then ask the user how to proceed. Never silently skip. > **No exceptions:** > - Not for "the user gave me the requirements inline" > - Not for "it's a small feature" > - Not for "there's time pressure" > - Not for "I already know what to build" ## Quality Bar Before any spec is written, four conditions must be met: 1. The decision is **unambiguous** — two developers would produce the same behaviour 2. **Rationale is present** — why this decision, not just what 3. **Behavioural edge cases are resolved** 4. **Invariants ar