extracting-design-mdlisted

# Extracting DESIGN.md Turns the design system a codebase *actually uses* into a DESIGN.md the tooling can enforce. Output format matters as much as analysis quality: a freeform writeup can be excellent and still unenforceable — only the spec format (YAML frontmatter tokens + prose sections + `## Decisions`) plugs into the generator, the lint gates, and `designing-consistently`. The hard part is not finding the values. It is writing them down without canonizing drift. A drifted app disagrees with itself, and only two things can settle a disagreement: the owner, and the code at the surfaces the owner points to. Counts cannot. A value with 984 uses and nothing behind it is 984 surfaces of spread, not a decision. So a first extraction from a drifted app comes out **mostly `[provisional]`, and that is the correct output** — the pull toward making it look decided is the failure this skill exists to stop. ## Workflow Copy this checklist and tick items off: ``` Extraction progress: - [ ] 1. Inventory sources and rank them - [ ] 2. Harvest and cluster values - [ ] 3. Drift report - [ ] 4. Elect tokens from the reference surfaces - [ ] 5. Backfill Decisions (Global + modules) - [ ] 6. Write DESIGN.md → generate → lint - [ ] 7. Migration plan + hand-off ``` **1. Inventory and rank.** List every source that could speak for the design: token definitions in stylesheets and theme layers, the build's style config, the classes and inline styles components actually use, the repo's agen