direction-picker

# Direction picker Converging work needs one committed visual direction before the build starts. This atom owns that moment in the `plan` stage: decide the direction, state it in one line, and lock onto it. Resolve the direction from what you already have, in this order: 1. An active design system — its DESIGN.md palette, typography, spacing, and component rules **are** the direction. Bind its tokens and stop here. 2. A brand spec, reference URL, or screenshot the user supplied — parse that source directly. 3. Otherwise, infer the best-matching direction yourself from the brief's domain, audience, and tone, then bind its visual tokens. If the runtime provides only an index of direction ids and names, run `"$OD_NODE_BIN" "$OD_BIN" tools directions --id <id>` to retrieve the full specification — never infer colors or fonts from the name alone. **Do not ask the user to choose a visual direction.** Not as a question-form, not as a markdown list of options, not as a "which of these feels right?" follow-up. The direction is yours to resolve; asking spends the user's turn on a decision they hired the agent to make. ## Convergence The atom completes when the plan states the chosen direction. The agent's next turn must build against that direction — backtracking forces a fresh devloop iteration of the plan stage. ## Anti-patterns the prompt fragment forbids - Asking the user to pick, compare, or confirm a visual direction. - Locking the user into a single direction with cosmetic alternates (a stated direction must be a defensible standalone bet). - Inferring palette or typography from a direction's name instead of resolving its specification.