Prototype UI

Build an isolated, realistic prototype without silently integrating it into production. Choose the mode from the user's intent:

Variant mode: the user wants alternatives, directions, or a comparison.
Core Flow mode: the user wants key screens, a clickable journey, or an engineering handoff. Load FLOW.md and follow it.

Variant Mode

Clarify the component, context, required behavior, and the axis on which alternatives should differ. If scope is broad, choose or state a bounded comparison surface.
Inspect the stack, tokens, product personality, surrounding layout, and accessibility conventions. In a standalone context, use restrained defaults.
Build a small set of defensible variants—usually three, or the number requested. Name each direction and vary meaningful structure, density, interaction, personality, or motion rather than only color/copy.
Use an isolated project route/page or standalone HTML harness. Load PICKER.md for the picker contract. Preserve its required integration behavior, controls, selection state, keyboard access, and one-variant-at-a-time comparison, but adapt equivalent markup/styles where the host framework or accessibility conventions require it.
Give variants realistic context, content, states, and working interactions. Respect reduced motion and existing design tokens. Switching variants should remain immediate.
Run the harness and verify every variant and picker control. Check the console and inspect representative screenshots when browser tooling is available.
Present each direction's axis, best use, and cost, then stop for the user's choice.

Only after the user selects a variant, promote that variant using project conventions. Remove the prototype surface unless the user asks to retain it. If the user requests another round, keep the harness and diverge around their feedback without treating it as final selection.