Design Direction

Activation: the developer requests visual direction for a UI. Skip this stage for work with no interface. Input is approved product scope, existing UI/brand evidence, constraints, and any validated prototype.

Inspect the actual product and visual context. Ask only unresolved choices that materially change the direction. Use visual-taste for context-fit and anti-generic critique. Write docs/design.md with Status: Draft and concrete decisions: visual concept and rationale; typography roles and scale; palette with semantic roles and values; spacing/grid; density; component shape and states; hierarchy; responsive behavior; interaction and motion purpose, including reduced motion; accessibility targets and known constraints. Distinguish existing tokens from proposed values. Include project-specific anti-patterns, not blanket style bans.

For redesigns, preserve product flows, labels, form fields, brand assets and other approved behavior unless the developer changes their owner documents. Present the draft for approval and stop before frontend implementation. frontend-engineering applies the direction; ui-review evaluates built UI against it. A conflict with docs/product.md must be resolved with the developer, not hidden in styling.

Done when a frontend implementer can make consistent choices without inventing the visual system. The output is a decision document, not code.

Sources: Taste Skill's design read, and Impeccable's shape and document references; no Impeccable engine dependency.