close-spec

# Close Spec A spec is a **build plan** while you're building and a **rationale record** once you've shipped. Closing flips it from one to the other. The plan was a ladder of slices and predictions; the record is the layer of meaning the code can't hold — why this exists, what it must never break, what you tried that failed. The code is the single source of truth for *how*; the closed spec is the source of truth for *why*, and a map into the code. Do not summarize the implementation. Anyone can read the code. If a paragraph restates what a function does, cut it and point at the function instead. ## Workflow 1. **Confirm it shipped.** The feature is merged or working in-tree and its tests/screenshot gates are green. If slices remain unverified, it isn't done — finish or [review](../review/SKILL.md) first. 2. **Diff plan against reality.** Read the spec's README and slices, then read what actually landed. Note every place the build diverged from the plan: dropped slices, renamed seams, a mechanic that turned out different, an assumption that broke. The divergences are the most valuable thing to record — they're exactly what a future reader would otherwise re-derive. 3. **Move it.** `specs/<feature>/` → `specs/done/<feature>/` (use `git mv`). Single-file specs: `specs/<feature>.md` → `specs/done/<feature>.md`. 4. **Rewrite the README as a record**, not a plan. Keep: - **Overview & purpose** — what shipped and the problem it solves, in present ...