UI: reuse, do not invent

Read ../rule-maker/rules/design.md (the installed sibling skill) and CONTRACT.md. This is a permission/selection skill, not a designer or another implementation workflow. The normal rules-readiness gate, grilling, plan review and implementation approval remain in force.

1. Establish the surface and decision

Identify the task, framework versions, affected area/brand/platform, designated project sources, existing changes and applicable rules. Backend-only work skips this skill unless it changes UI contracts. A missing DESIGN.md filename is not a blocker when an equally authoritative source exists. The mere presence of that file, a catalogue or a familiar class is not selection/approval.

For a new substantive UI task, confirm the exact source and selected component/pattern IDs, variants and states. Reuse explicit owner choices or a still-valid same-task decision. Ask once when unresolved, batching consequential gaps through grilling. Do not ask again on every control or unchanged resume.

2. Select a permitted mode

Pick behaviour-only, reuse, blocked or plain-by-instruction exactly as the shared rule-maker rules/design.md defines them; CONTRACT.md lists what each permits and forbids. For each new or changed element, search the design kit (if any) and the existing code, and record the element you mirror as file:line, tag, classes and the wrapper it needs (python -X utf8 -I scripts/class_rules.py <project-root> <class>... lists every rule for a class, marking the ones that need context). No new CSS in any mode. No new plain-HTML controls without the user's explicit instruction. A blocked element waits for the user's answer to the exact question in design.md rule 4; offer only matching existing same-tag elements, never a plain-HTML recommendation, new CSS or another tag's classes. Any plain-by-instruction exception must meet design.md rule 4, not a blanket yes. Independent logic and tests can continue.

Use KIT.md for kit-audit, kit-setup, kit-check and LIVE-KIT.md for code-backed discovery. For manual designer changes, run scripts/design_drift.py --root <project>; reconcile its findings as LIVE-KIT.md explains. Setup can audit/propose the development-only kit route inside the application and a DESIGN.md shaped by templates/DESIGN.md; it cannot create application presentation, install tools or approve new components. Designer changes are external inputs to reconcile, not permission for this agent to write CSS. Older mode names map as CONTRACT.md says.

3. Prepare the existing plan/report

Keep one compact selection record in PLAN/STATUS: mode, area, authority, stable item/story IDs, component and example sources, variants/states, selected pattern, preview access and remaining design/release limits. No duplicate component inventory or new folder per selection. Use EXAMPLES.md.