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 is the
shared rulebook: the orchestrator filters it to the standards that apply to this
product, audience, surface, and phase. DESIGN.md
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.
01Intent
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.
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.