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)
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
1---2name: frontend-foundations3description: Use on any frontend delivery to hold the surface-specific quality floor that `engineering-craft` doesn't cover — intentional visual hierarchy over template defaults, accessible-by-default markup, design tokens instead of hardcoded values, reusable components matching the repo, and compositor-friendly motion. Invoke whenever the change touches UI (a component, screen, page, or style), as the always-on companion to the deeper `frontend-design`, `frontend-component`, `frontend-a11y`, and `frontend-responsive` packs. For "make the UI production-grade", "don't ship a generic template", "is this accessible?".4---56# Frontend foundations — the UI quality floor78The frontend companion to `engineering-craft`. Craft holds the *code* bar (structure,9errors, tests); this holds the *surface* bar — the things that separate a real product UI10from a working-but-generic one. It is a floor and a lens, not the full treatment: for11depth, invoke the deep packs it points to. Apply it on any change that touches UI, and12confirm it in `self-review`.1314Composes with `minimalism` the same way craft does: this is never a licence to add15chrome or animation the ticket didn't ask for — it's the quality bar for whatever UI you16*are* building.1718## The floor (hold all of these on UI work)19201. **Hierarchy over template defaults.** The surface should look intentional — clear21 scale/weight contrast so the eye lands on the right thing first, not uniform cards in a22 uniform grid. If it looks like an unmodified starter template, it isn't done. Depth →23 `frontend-design`.242. **Accessible by default, not as a retrofit.** Semantic elements (`button`, `nav`,25 `main`, `label`) before `div` soup; every interactive element reachable and operable by26 keyboard with a visible focus state; images/icons have text alternatives; colour is27 never the only signal. Depth → `frontend-a11y`.283. **Tokens, not magic values.** Use the repo's design tokens / theme variables for29 colour, spacing, type, and radius. Do not hardcode hex codes or `px` font sizes when a30 token exists — that's the frontend form of the DRY rule.314. **Reusable components, the repo's way.** Build a component that composes and takes32 props for its variants/states — but match the existing component conventions and do33 NOT introduce a new UI framework or styling system. Reuse the repo's primitives before34 adding one. Depth → `frontend-component`.355. **Every meaningful state is designed.** Handle and style loading, empty, and error36 states, plus hover / focus / active / disabled — not just the happy, populated view. A37 missing empty or error state is an unfinished component.386. **Motion clarifies, on the compositor.** Animate `transform` / `opacity` (and39 `clip-path`/`filter` sparingly), not layout-bound properties (`width`, `top`,40 `margin`, `font-size`). Respect `prefers-reduced-motion`. Motion should explain a41 change, never decorate for its own sake.427. **Responsive and overflow-safe.** Verify the real breakpoints (e.g. 320 / 768 / 1024 /43 1440); no horizontal overflow, touch targets large enough to hit. Depth →44 `frontend-responsive`.4546## How it composes4748- **With `engineering-craft`:** craft covers the component's *code* (small units, honest49 props, error handling, tests); this covers how the rendered surface *looks and behaves*.50 Both apply to a UI change.51- **With the deep frontend packs:** this is the always-present checklist; `frontend-design`52 / `frontend-a11y` / `frontend-component` / `frontend-responsive` are the depth you invoke53 when the ticket centres on that dimension. Don't duplicate them — defer to them.54- **With `minimalism`:** the floor is about *quality*, not *quantity*. Meet the bar with55 the least markup and the fewest dependencies that clear it.5657## Marker5859When you make a non-obvious surface call — chose a token scale, added an empty/error60state, picked a motion approach, made an a11y tradeoff — note it in one line via61`request_decision` at `log_only` or in your `record-evidence` notes, so the choice is62visible and the skill's application is auditable. One line, real calls only.
tmj-90