fe-design

Frontend Design Skill

Ad-hoc mode — outside the engine, YOU run this loop now

One question decides which mode you are in: is a /implement-ticket run dispatching this?

The third row is an axis, not an owner. Renderer selection resolves through machinery that already exists: search_stack in corpus-grounding (scripts/decision_engine.ts), whose stack corpus carries threejs.csv among its stacks, read beside the register in design-intelligence § Register. No second frontend executor is declared, and none is needed: a renderer changes what you ground against, never who writes the UI.

Outside the engine, nothing else owns the design quality of a UI write. Reading this skill and then writing the UI from priors is the failure it exists to prevent — the loop below is not optional context, it is the work.

Skip only when the change is ui-trivial, decidable off the diff: ≤ 1 file, ≤ 5 changed lines, no new component, no new state, no new dependency, no new control role. Anything else runs the loop.

The loop

1. Audit first — run existing-ui-audit. What already exists (components, tokens, layout conventions) outranks every heuristic below. Reinventing an existing component is the #1 failure mode. Control roles. For every control you add, look up its role in the control_roles of agent-config ui:audit (re-run it when the artifact is older than your last UI edit): use the canonical implementation and the siblings' box metrics. Role missing or tied → ask before inventing a control kind; a native control beside an existing primitive needs a stated native_control_reason.
2. Brief — seven keys before any code. Five are the ones the engine gates (REQUIRED_BRIEF_KEYS): layout, components, states, microcopy, a11y. states means all five of empty, loading, error, success, disabled — a brief missing one is unfinished, not concise.