# The loop

> One orchestrator, focused specialists, one approved plan, and an independent design review.

`dx-design` keeps a design run coherent from the first request to the reviewed
result. It clarifies the intent once, then carries the same context through every
specialist, subagent, builder, and reviewer. No stage starts the interview again or
silently changes the brief.

## What grounds the run

Two sources guide every decision. The [catalogue](/standards/catalog) is the
shared rulebook: the orchestrator filters it to the standards that apply to this
product, audience, surface, and phase. [`DESIGN.md`](/harness/skills#the-design-language)
holds the decisions that make this product itself, including its essence, colour,
type, motion, voice, guardrails, and standing overrides.

The two files do different jobs. `DESIGN.md` adds product context; it never copies
or replaces catalogue rules. Existing code remains the authority for implemented
components and tokens.

## How `dx-design` orchestrates the work

For a broad improvement, `dx-design` captures the surface and brings in only the
specialists the request needs. Copy, pattern, polish, motion, and flow can run as
propose-only subagents. Each receives the same intent, `DESIGN.md` context, and
in-scope standards, then returns focused, ranked findings to the orchestrator. None
of them edits the product.

The orchestrator combines those findings into one plan, asks for approval once,
and hands the accepted work to `dx-design-execute`. A specialist can also run on
its own when you already know which dimension needs attention; it still proposes
changes rather than making them.

## From intent to review

The diagram shows the shared run after routing. A new page usually includes several
directions to choose from. An existing page may enter with accepted findings from
the specialists. In both cases, `dx-design-execute` is the only skill in the run
that changes product code.

1. **Intent**: one shared contract
   - The orchestrator writes the purpose, audience, page type, and done-criteria into one contract. It loads the product's DESIGN.md and filters the control catalogue so every later stage receives the same context.
   - **You:** Describe the outcome and what done looks like.
2. **Diverge**: directions or findings
   - For new work, dx-design-execute renders 2–3 different directions. For a broader improvement, dx-design can instead run the relevant specialists as propose-only subagents and collect their ranked findings.
   - **You:** Pick a direction or accept the findings you want built.
3. **Plan** (human approval): before code changes
   - The orchestrator combines the chosen direction, accepted specialist findings, components, states, in-scope standards, and any requested waivers into one plan. Nothing changes until you approve it.
   - **You:** Approve the plan, or send it back.
4. **Implement**: one skill edits
   - dx-design-execute is the only skill that edits the product. It builds the approved plan with the product's components and tokens; any drift from that plan is a defect.
   - **You:** Nothing. The approved plan speaks for you.
5. **Design review**: fresh eyes, new evidence
   - A separate dx-design-review agent checks the build against the contract, approved plan, DESIGN.md, relevant standards, and screenshots. Findings return to the builder, and the same reviewer re-checks each fix from new evidence.
   - **You:** Decide only if an unresolved finding may remain open.
6. **Rule proposal**: real gaps improve the catalogue
   - If the run exposes a real defect that no control covers, the orchestrator can start a rule proposal. The catalogue changes only through review and approval; the run never edits the rulebook to make a finding disappear.
   - **You:** Review a proposal only when the work uncovered a genuine gap.

## How design review closes the loop

Whoever started the run launches `dx-design-review` after implementation. The reviewer is a
separate, fresh-context agent. It receives the original intent, approved plan,
screenshots, component inventory, the relevant standards, and any standing
overrides from `DESIGN.md`.

The reviewer reports findings but never edits the product. The builder addresses
them, then the same reviewer checks new screenshots and marks each finding resolved,
partial, or unresolved. The builder's explanation is not evidence.

## Where you decide

The run stops once before implementation for plan approval. You see the proposed
structure, content, states, standards, and any requested waivers before code changes.
An explicit request to build a specific plan or chosen direction already counts as
approval.

Agents can report a deviation but cannot approve one. You decide whether to grant a
permitted waiver at plan approval. After design review, the person who approved the
plan also decides whether an unresolved finding may remain open.