/direct

name: direct
description: Set a redesign direction for an existing website. Analyzes the user's intent, picks a palette and visual direction, and writes the target spec (PRODUCT.md, DESIGN.md, DESIGN.json) plus a reasoning trace at stardust/direction.md. Use when the user asks to redesign a site, refresh the design, set a new design direction, define a redesign target, or invokes /stardust:direct.
license: Apache-2.0

stardust:direct

Resolve the user's freeform redesign intent into a complete **target specification**: project-root `PRODUCT.md` and `DESIGN.md` (impeccable format), a `DESIGN.json` sidecar with the divergence audit trail, and a `stardust/direction.md` with the full reasoning trace.

`direct` produces the spec against which `prototype` and `migrate` operate. It never writes prototypes or migrates pages — those are downstream sub-commands.

Inputs

• `<phrase>` — optional positional. The user's freeform intent

("make it better", "more Linear less Salesforce", "feel more premium on a small screen"). If omitted, ask the user for one.

• `--re-direct` — optional. Replace the current direction with a new

one. Triggers stale-flagging on prototyped / approved / migrated pages per `skills/stardust/reference/state-machine.md`. Default behaviour without the flag is additive: if a direction already exists, the agent asks before replacing.

• `--rebrand` — optional. Force rebrand mode (full divergence-seed

roll, no Mode A inheritance). Without it the default is brand-faithful whenever the captured signal is `signal-strong` (§ Mode-detection precedence).

• `--prep` — optional. Run in **migrate-prep mode**: confirm the

type catalog, finalize the module catalog, capture color reservations and brand-level metadata defaults, re-evaluate direction against the wider crawl. See § Prep mode below. Typically invoked via the `prepare-migration` orchestrator.

• `--add-variant <name>` — optional. Add a new variant against

the existing direction without re-running intent reasoning or mode detection. Writes `DESIGN-<name>.{md,json}` at the project root and appends a per-variant section to `stardust/direction.md`; existing prototypes are **not** stale-flagged. See § Add-variant mode below.

Setup

1. Run the master skill's setup (`skills/stardust/SKILL.md` § Setup) — hard impeccable dep check, context loader, state read. 2. Verify `stardust/state.json` exists and contains at least one `extracted` page. If not, stop and recommend `$stardust extract <url>` first. 3. Read `stardust/current/_brand-extraction.json`. If absent, stop — extract did not complete brand-surface extraction; re-run extract. 3b. **Cross-site brand inputs** (when present). `state.json.designSource` (design-donor mode: Mode A pins bind to the donor's derived system) and `_brand-extraction.json.origins[]` (sibling-property evidence: widens what can be amplified, not what is pinned). Read `reference/cross-site-brand-inputs.md` for the pin and evidence rules; surface the active mode in the plan. 4. Read `stardust/direction.md` if present. If a prior direction exists and `--re-direct` was not passed, ask whether the user wants to refine the existing direction or replace it. 5. **Validate provenance** (prep mode only). When `--prep` is active, run the provenance validation per `reference/prep-mode.md` before typing or module detection. 6. **Classify the captured brand signal.** Read `_brand-extraction.json` and stamp one of:

• `signal-strong` — palette has ≥ 3 distinct colors (after

near-duplicate clustering and excluding pure black/white if they are the only entries) **AND** at least one captured type family is named in `type.headingFamily.name` or `type.bodyFamily.name`. This is the common case for any extracted commercial site.

• `signal-thin` — palette has 2 colors OR no captured type family

OR `type.scaleAudit.kind === "ad-hoc"` with fewer than 3 distinct heading sizes. The brand exists but cannot fully anchor a refresh.

• `signal-absent` — palette has 1 color or 0, or

`_brand-extraction.json._provenance.notes` flags the extraction as failed / login-walled / iframe-dominated. The classification feeds the Mode-detection precedence in Phase 2. Surface the classification in the plan when it would change the default mode.

Procedure

Phase 1 — Reasoning

Run the full intent-reasoning procedure from `skills/stardust/reference/intent-reasoning.md`. Steps 1-6: restate the phrase in dimensional vocabulary, identify movement, identify gaps, ask **at most two** clarifying questions, map to an impeccable command sequence, show the plan to the user.

Worked examples in `skills/stardust/reference/intent-examples.md` calibrate the style. Hard ceiling on questions: two per turn, no exceptions.

**Hands-off mode** (per `skills/stardust/SKILL.md` § Hands-off mode, `state.json.handsOff: true`): ask nothing and wait for nothing. Derive every answer the questions would have collected from the captured evidence — density and ia-fidelity from their documented defaults and trigger conditions, audience and register from the captured surface — and record each as a named assumption in `direction.md` § Movements (e.g. `density: balanced (hands-off default — multi-audience floor fired)`). The plan is still written; execution proceeds without the confirmation gate. Question budgets and gates below that say "ask the user" resolve the same way: derive, stamp the assumption, proceed.

Density tuning (one-shot, only when unmoved)

When the user's phrase does **not** move the `density` axis (per `reference/intent-dimensions.md` § 4), and the resolved register is `brand`, ask one short follow-up — count it within the two-question ceiling:

> Density tuning — (a) airy (NYT-Opinion-tier breathing, ~96px > section padding), (b) balanced (calm but compact, ~64–72px), > (c) packed (data-dense, ~40–48px). D