UI Rules

Project-wide UI rulebook generator. Pairs with <cwd>/.plans/DESIGN.md to guide every later UI build.

Inputs and outputs

• Required input: <cwd>/.plans/DESIGN.md — must contain design tokens and prose covering palette, fonts, density, shape, and mood. Validate the file's contents; do not assume a specific upstream schema.
• Required input: discovery interview with the user — see DISCOVERY.md.
• Output: <cwd>/.plans/UI-RULES.md — frontmatter plus 7 content sections (see Workflow §3).

Core rules

1. DESIGN.md must exist first. If <cwd>/.plans/DESIGN.md is missing, stop and tell the user a DESIGN.md must exist at <cwd>/.plans/DESIGN.md first. Do not invent design tokens.
2. Never overwrite silently. If <cwd>/.plans/UI-RULES.md already exists, read it, summarise its contents, and ask the user: update in place, version-bump, or abort.
3. Anti-slop is non-negotiable. Apply every rule in ANTI-SLOP.md. The bans are absolute; the reflex-font list is absolute. No exceptions for "this case is different".
4. Tailor, don't templatise. Project rules must reference DESIGN.md's actual tokens (colours, fonts, density). Generic "use OKLCH" advice is useless without naming the project's specific palette decisions.
5. No code in UI-RULES.md output. The artefact is prose rules — not CSS, not components. Implementation is a separate skill's job. (Companion files in this skill may use CSS as illustration; the output file must not.)
6. No fabricated references. Don't cite fonts, packages, or APIs you can't verify exist.