---

name: direction-picker description: Resolves the visual direction at the plan stage from the brief and design system, without asking the user. od: scenario: general mode: planning

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.