frontend-ui-engineeringlisted

# Frontend UI Engineering Decide **how to structure a UI unit before writing it**, so the choices audits would catch late (accessibility, i18n, bundle cost, missing states) are made up front. Frontend counterpart to [`codebase-design`](../codebase-design/SKILL.md): a component is a **deep module** — a lot of behaviour behind a small prop surface. This skill decides; `tdd`/`build` implement; the audit skills verify. Framework-agnostic. ## 1. Classify the unit | Kind | Emphasis | |------|----------| | Design-system primitive (Button, Input) | prop API, variants via props, tokens, a11y contract | | Composite component | composition, state placement, required states | | Page / route | data-fetching boundary, layout, loading/error at the route | | Refactor of existing UI | shrink prop surface, extract states, remove magic values | ## 2. Decision pass — state each choice before coding 1. **Boundary & prop API.** Smallest surface that serves callers. Prefer **composition** (`children`/slots) over configuration. A growing set of boolean flags (`isPrimary`, `isSmall`, `isLoading`…) is a smell — three booleans is eight states, most untested; reach for a `variant`/`size` union or composition. 2. **Where state lives.** The lowest owner that still works: local → lifted → server state → URL. No derived state stored twice; compute from source. 3. **Data & async.** Decide the fetch boundary (route/loader vs. inside the component) and who owns caching. Keep rendering components separate