Choose a visual language using real site content. Produce rendered concepts and 05-direction.md; a palette description or moodboard alone is insufficient.
Use upstream domain guidance when the relevant UI work begins. Fetch only the needed domain and its supporting references. For motion work, follow Emil Kowalski’s upstream guidance for this stage.
Start or resume
Read 00-project.md, the brief, relevant plan/copy, and view the current wireframes. Accept equivalent inspected inputs. If the project setup or usable wireframes are missing, identify the missing input and recommend the appropriate earlier Webcraft stage; do not silently create it.
Create concepts, resume incomplete exploration, or revise the requested visual choices. If the direction is complete and no changes were supplied, ask what to reconsider. Preserve constraints and confirmed choices. If the user already supplied a visual system, demonstrate and refine its application rather than inventing competing identities.
An explicit restart may rework this stage; preserve its prior milestone through existing history or a scoped snapshot. Approval belongs to a specific revision and does not automatically carry over to substantive edits.
Explore with comparable content
Use available frontend-design guidance for aesthetic judgment, bounded by the brief and this stage. Ground choices in the audience, subject, and supplied brand. Select representative content that tests the direction: an opening section, content with realistic density, and a conversion or interaction section. Keep content comparable between alternatives.
When the direction is open, render a small set of meaningfully different concepts, usually two or three. Different font/color swaps on an otherwise identical generic layout are weak alternatives. Compare hierarchy, typography, imagery, composition, and how the direction serves the brief. Do not force alternatives when a direction is already established.
This stage owns the visual system. Respect preserve/extend/redesign/new in 00-project.md: preserve demonstrates the existing identity, extend proposes only missing roles, and redesign stays within its agreed scope. For a new system use shadcn-compatible role names without requiring shadcn. Keep an existing naming convention when reusing a system.
Use the brief’s brand colors; ask only if missing and consequential. Derive primary/primary-foreground, interaction states, focus treatment, and any needed ramps with upstream color guidance. Measure rendered contrast pairs before claiming they pass. Keep exact brand primitives where required while proposing accessible UI variants; do not mechanically assign a logo color to every action or change fixed brand values without resolving the requirement.
Define reusable typography roles, colors, section schemes, spacing, surfaces, controls, imagery, and appropriate motion. Section schemes should specify background, text, surface/foreground, border, and accent roles with readable contrast; do not claim compliance based on a palette alone. Reuse supplied logos and assets. Record the chosen font and asset availability rather than promising unavailable materials.
Create or update a viewable style-guide page/board showing type hierarchy, semantic surfaces, controls, focus/interaction states, and section schemes. Link the authoritative CSS tokens or native design variables from 05-direction.md; the record is not a second token source. Support only the theme modes in scope.
Choose purposeful motion as part of the direction, respecting any existing motion system. Consider interaction feedback and a distinctive explanatory or brand moment where they fit; do not add animation to satisfy a quota. Record the chosen moments, purpose, trigger, intended feel, timing/easing or existing token references, and reduced-motion alternative. Demonstrate representative motion in the code concept or design prototype when the tool supports it. Otherwise supply precise state/transition notes and label playback unverified; do not switch modes just to animate a concept.
Code-only
Render concepts in the existing project using a temporary comparison route or scoped variant mechanism consistent with its routing. Keep experimentation from silently changing all main pages. Reuse content and components instead of creating separate application copies. Apply available code-quality guidance and the project's package manager and scripts. Once selected, retain the chosen implementation/tokens for the design stage and preserve useful rejected previews as screenshots or existing version history.
Before browser inspection, check existing servers with hitch when available and configured ports in environment files; ask if server status is unclear. Use chrome-devtools-cli when available. Inspect concepts at wide and narrow widths; fix failures that prevent a fair comparison.
Design-only or design-then-code
Create separate editable concept boards in the chosen file, reusing wireframe content. Use the available tool skill and actual API, without overriding the chosen implementation framework. Include type/color/UI samples plus representative designed sections. Inspect their rendered appearance; keep original wireframes intact.
Select and hand off
Present concept links and a concise recommendation tied to the brief. Ask for a selection when the user has not delegated that decision; keep it pending rather than treating silence as approval. If selection was delegated, choose and explain without manufacturing user approval.
Use the direction record. Ready means a direction is selected, representative visuals are inspected, and the style decisions can be applied across pages. Update revision, input versions, actual approval, token authority, and the project ledger. Flag affected existing designs/builds if the direction changed. Finish with /webcraft-design as the next step; do not apply it across the site automatically.