← ClaudeAtlas

frontendlisted

Build UI that holds up — component and state boundaries, design tokens, responsive and theme behaviour, and the accessibility gate. Auto-triggers on: "build a component", "add a page", "style this", "make it responsive", "dark mode", "the layout breaks", "frontend", "this UI"
Univers42/claude-deal-with-the-devil · ★ 3 · Web & Frontend · score 69
Install: claude install-skill Univers42/claude-deal-with-the-devil
# Frontend UI is where "it works on my machine" hides best: it renders on your screen, in your theme, with your data, at your width. Correctness here means it holds at every width, in both themes, with no data and with too much, and for someone not using a mouse. Depth lives in `reference.md` (tokens, layout, state) and `a11y.md` (the gate). Read them when you reach that step, not before. ## 1. Look before you add - `.claude/tools/facts.sh` for the framework, the test runner and the lint setup. Do not introduce a second styling approach, state library or component kit — that is a fork in the codebase (`rules/minimalism-ladder.md` rung 4). - Find the nearest existing component and mirror its structure, naming and file layout. The codebase's convention beats your preference. - `.claude/tools/dupes.sh` — a third copy of the same button is an extraction (`rules/library-first.md`). ## 2. Draw the boundaries first - **State lives at the lowest common owner** of everything that reads it. Lifting everything to the top is how a page re-renders on every keystroke. - **Server state is not UI state.** Cache, loading and error belong to a data layer, not to twelve `useState` calls. - **Derive during render; do not sync with an effect.** Most `useEffect` that sets state is a computed value in disguise (`rules/refactor-typescript.md`). - **Presentational components take data and callbacks**, and fetch nothing. They are the ones that stay testable. ## 3. Tokens, never