Design Directions

---
name: design-directions
description: When Atlas design routing finds a structural commitment, sketch three different directions in text before code, including the status quo, and let the owner choose one.
when_to_use: Use only when pnpm design:route returns directions=yes and no owner selection exists for this structure.
effort: max
---

# Design directions before implementation

Generate alternatives before code: models return to one frontend default, and
parallel alternatives beat serial iteration (Dow et al., TOCHI 2010). Generic
redirection such as “cleaner” replaces one default with another; only a concrete
specification changes the structure.

One `reviewer` reviews the built direction when the route says `review=yes`.
This skill cheaply creates the alternatives before that review when the route
identifies a structural choice.

## Ownership

The coordinating session sketches the directions, never the builder
(`design-guardian` or an implementer). A builder who authors the options biases
them toward the one they want to implement and turns the rest into straw men. If
the coordinator will also build, it says so. The human owner chooses, the builder
implements, and the `reviewer` never sketches.

## A direction is structural, not a palette

Atlas already fixes dark-only and tokens-on-ramps; since 2026-09-08 gradients,
glow, glass and further hues are open, so a direction may spend them, but a
direction is still a structure, not a coat of effects. Do not copy example colours, fonts, or assets from reference documents.

Directions differ on at least one axis:

| Axis | Structural difference |
|---|---|
| Hierarchy | what the eye reaches first |
| Layout and density | grouping, rows, and spatial ownership |
| Interaction model | modal, inline, popover, or in-place action |
| Motion information | which state change moves and what that movement explains |

Different values inside the same shape are adjustments, not directions.

## When

Run only when `pnpm design:route` returns `directions=yes`: a new surface,
information architecture, primary interaction model, or primary attention
model. Do not invoke it for generic “non-trivial” work, token swaps, copy edits,
spacing/layout fixes inside a selected shape, responsive repairs, or motion
tuning.

## Reuse an existing selection

If the owner has already selected a concrete direction in this session, record
that selection and proceed with its implementation. Reopen selection only when
the requested structure or a material constraint changes; identify that change
before requesting a decision. An implementation request without a selected
structural direction still follows the rules below.

## Rules for a new selection

Apply this section only when a new owner selection is needed. The text-only
restriction covers proposed alternatives; it does not prohibit reading source
or inspecting the current baseline. An already selected direction proceeds to
"After selection" without regenerating alternatives.

1. Use text and ASCII only—no code, build, or screenshot. A built option wins by
   sunk cost.
2. Produce exactly three directions. Two is a forced binary; more turns choosing
   into the task.
3. One direction is **the status quo**. “Change nothing” must be able to win.
4. Each direction states the observation that would prove it wrong.
5. Do not propose a forbidden pattern. Request a rule change separately.
6. Build only the one selected by the human owner. Never merge directions into a
   third shape nobody chose.
7. When a spec in `docs/specs/` governs the change, each direction says which of
   its States rows and acceptance criteria it satisfies, and why it drops any.

## Output

```md
## Directions — <change>

**What this screen does now**: <one sentence>
**Diverging axes**: hierarchy / layout and density / interaction / motion

### A. Status quo
<honest current shape and what already works>
**Wins when**: …

### B. <structural name, not an adjective>
<ASCII sketch with known dimensions>
**Changes**: <axis and change>
**Cost**: <what is lost>
**Wrong if**: <observable falsifier>

### C. …

**Existing measurements**: <numbers or none>
**Recommendation**: <one direction and why; the owner still chooses>
```

## After selection

1. Record the selected direction in one implementation-grade sentence.
2. Implement only that sentence and retain rejected directions as history.
3. Give the built direction to one `reviewer` only when the same route says
   `review=yes`; it reviews the chosen direction rather than selecting one.
4. Run only the route's proof packet. Every rendered result includes the
   `/design-build` §0-B render-loop packet; motion includes a real screen
   recording.

## Failure modes

| Failure | Signal |
|---|---|
| all directions are one | none differs on the four axes |
| status quo is absent | change cannot lose |
| no option has a cost | alternatives were not investigated |
| code predates directions | post-hoc justification |
| directions are merged | the screen matches no selected option |