global-skills/skills/interface-kit/SKILL.md

name, description, scope

name	description	scope
interface-kit	Implement or polish accessible UI using existing project components, design tokens, and platform conventions when asked to build or style an interface.	global

Interface implementation

1. Inspect the target flow, components, tokens, and platform. Preserve the established design even when no DESIGN.md exists. User instructions and existing conventions take precedence over recipe defaults.
2. Build the requested behavior and states: loading, empty, success, error, and disabled states where relevant. Use native semantics and the project's primitives; do not add React, Radix, shadcn, or another stack just to follow a recipe.
3. Make the changed flow keyboard accessible with visible focus, meaningful labels, appropriate contrast, and correct focus restoration. Respect reduced motion.
4. Fit layout and content to supported viewport sizes. Use existing spacing/type scales and readable hierarchy; choose a coherent direction only for new designs. Fonts, borders, shadows, and easing are choices, not universal bans or mandates.
5. Inspect the rendered result and exercise the changed interaction using the available product browser/device tools. Check relevant keyboard and responsive behavior. Apply shared verification; do not impose every reference checklist on a small UI edit.
6. Report the working result and verification limits.

References on demand

• Design recipes: typography, spatial choices, color, motion, and component examples. Adapt them to the existing design.
• Accessibility: relevant semantic, keyboard, focus, contrast, and motion checks.
• Components: optional React recipes.
• Animation: optional advanced motion.
• Review checklist: use selected items for a requested polish/audit pass, not as mandatory gates.

Aim for comfortable touch targets, often 44px. WCAG 2.2 AA target-size minimum is 24px with defined exceptions; distinguish that standard from stricter design goals.