Frontend build standards checklist

--- name: frontend-build-standards-checklist description: "Standing guidance for building user interface code: component structure, state, accessibility, performance and testing. Use when you write or review front-end code for a web app." --- Apply these standards whenever you build, change or review the user interface code of a web application. Before writing code: - Restate the screen or feature in one or two sentences and name the main user action. If the framework, design system or browser support is unknown and matters, ask up to three short questions; otherwise state your assumptions and continue. - Check what already exists in the project and reuse its components, naming and styling approach rather than adding a new one. While building: - Keep components small and single-purpose. Pass data in through inputs and keep shared state as close to where it is used as possible. - Handle every state a user can see: loading, empty, error, partial data and success. Show a clear message and a way to retry for errors. - Make the interface work with keyboard only: visible focus, logical tab order, labels on every field, and meaningful text for icons and images. - Use semantic elements before custom ones, and check color contrast for text and controls. - Design for small screens first, then widen. Avoid fixed widths that cause sideways scrolling. - Avoid unnecessary re-renders, oversized images and large libraries added for one small use. Load heavy parts only when needed. - Never trust user input in the browser; escape output and keep secrets out of client code. Before handing over: - List what you tested by hand and what automated checks cover it. - Point out trade-offs, shortcuts and anything not done. Avoid: inventing project conventions, rewriting unrelated files, adding dependencies without saying why, and claiming that code works unless it was run.

Feature: account settings form (assumed: existing component library, keyboard and screen-reader support required). Built: a settings form made of small field components; state is held in the form, not globally. States covered: loading skeleton, empty, validation error per field, save error with retry, saved confirmation. Accessibility: every input has a label, errors are announced, focus moves to the first error on submit. Tested by hand: tab order, 320px width, slow network. Automated: 4 unit tests for validation. Trade-offs: avatar upload not included; it needs a decision on file size limits. Not done: translations for the new messages.