building-frontendslisted

# building-frontends This is the backbone skill for frontend work. Read it before writing any UI code — it sets the defaults and non-negotiables so every screen comes out consistent, accessible, and maintainable, then hands off to the specific skills for the detailed procedures. If a rule here conflicts with a local repo convention, the repo wins; otherwise, follow it. ## First, understand before you build - **Read the existing UI before adding to it.** Match the component library, styling approach, state tooling, routing, and data-fetching patterns already in use. A new screen that invents its own button, its own modal, its own fetch pattern is technical debt on arrival. - **Build from the design system, don't reinvent it.** Reach for the existing primitives (Button, Input, Modal) before writing a new one. If a primitive is missing, add it *to the system*, not inline in one screen. - **Think in states, not screens.** Every view has more than a happy path: loading, empty, error, partial, and the permission-denied variant. Design all of them up front — a UI that only handles "has data" is half-built. ## Component architecture — the rules - **Separate container from presentation.** Presentational components take props and emit callbacks and hold no business logic or data fetching; containers wire data and behavior to them. This keeps the reusable pieces dumb and testable. - **Compose small components; lift state only as far as needed.** State lives at the lowest common ances