Frontend foundations

Frontend foundations — the UI quality floor

The frontend companion to engineering-craft. Craft holds the code bar (structure, errors, tests); this holds the surface bar — the things that separate a real product UI from a working-but-generic one. It is a floor and a lens, not the full treatment: for depth, invoke the deep packs it points to. Apply it on any change that touches UI, and confirm it in self-review.

Composes with minimalism the same way craft does: this is never a licence to add chrome or animation the ticket didn't ask for — it's the quality bar for whatever UI you are building.

The floor (hold all of these on UI work)

1. Hierarchy over template defaults. The surface should look intentional — clear scale/weight contrast so the eye lands on the right thing first, not uniform cards in a uniform grid. If it looks like an unmodified starter template, it isn't done. Depth → frontend-design.
2. Accessible by default, not as a retrofit. Semantic elements (button, nav, main, label) before div soup; every interactive element reachable and operable by keyboard with a visible focus state; images/icons have text alternatives; colour is never the only signal. Depth → frontend-a11y.
3. Tokens, not magic values. Use the repo's design tokens / theme variables for colour, spacing, type, and radius. Do not hardcode hex codes or px font sizes when a token exists — that's the frontend form of the DRY rule.
4. Reusable components, the repo's way. Build a component that composes and takes props for its variants/states — but match the existing component conventions and do NOT introduce a new UI framework or styling system. Reuse the repo's primitives before adding one. Depth → frontend-component.
5. Every meaningful state is designed. Handle and style loading, empty, and error states, plus hover / focus / active / disabled — not just the happy, populated view. A missing empty or error state is an unfinished component.
6. Motion clarifies, on the compositor. Animate transform / opacity (and clip-path/filter sparingly), not layout-bound properties (width, top, margin, font-size). Respect prefers-reduced-motion. Motion should explain a change, never decorate for its own sake.
7. Responsive and overflow-safe. Verify the real breakpoints (e.g. 320 / 768 / 1024 / 1440); no horizontal overflow, touch targets large enough to hit. Depth → frontend-responsive.

How it composes

• With engineering-craft: craft covers the component's code (small units, honest props, error handling, tests); this covers how the rendered surface looks and behaves. Both apply to a UI change.
• With the deep frontend packs: this is the always-present checklist; frontend-design / frontend-a11y / frontend-component / frontend-responsive are the depth you invoke when the ticket centres on that dimension. Don't duplicate them — defer to them.
• With minimalism: the floor is about quality, not quantity. Meet the bar with the least markup and the fewest dependencies that clear it.

Marker

When you make a non-obvious surface call — chose a token scale, added an empty/error state, picked a motion approach, made an a11y tradeoff — note it in one line via request_decision at log_only or in your record-evidence notes, so the choice is visible and the skill's application is auditable. One line, real calls only.