ls-design-contractlisted

# L.S.Design Contract Produce and maintain the single source of truth every other skill in this suite consumes: `design/DESIGN.md`, `design/design.json`, `design/tokens.css`, and `design/preview.html` inside the target project. One design decision, written once, obeyed everywhere. ## Decision order Resolve conflicts in this order: explicit user and repository requirements; product, platform, and established brand truth; accessibility, usability, and functional correctness; the guidance of an already-approved design contract; aesthetic defaults and anti-pattern warnings. An invariant is mandatory, a contextual default is a starting point, and an anti-pattern warning is a diagnostic signal rather than a ban. ## When to run - Before any new interface build where the project has no approved `design/DESIGN.md`. - When asked to update, extend, or correct a drift in an existing contract. - Before opening the design studio, so the studio has tokens to work from. - **Not** for audit-only or review-only tasks. Those route to `ls-design-redesign` or `ls-design-review`, which may recommend a contract but never create one. ## Working method 1. **Discover state.** Check whether `design/DESIGN.md` exists. If it does, read it in full before changing anything — an update preserves approved decisions unless the user asks for a change. Inspect the repository for real content, existing tokens, brand assets, fonts, supported locales, and target devices. Never invent evidence for a premise.