/design

user-invocable: false
description: Route a design GitHub issue through the UI Taste Harness — investigate → architect → implement → critique loop → user-feedback loop → close — accumulating FORGE:DESIGN_* annotations and driving the design:* label state machine to design:shipped.
argument-hint: <issue-number> | <brief-name>
install: internal

<!-- SPDX-FileCopyrightText: Copyright (c) RapierCraft Studios --> <!-- SPDX-License-Identifier: AGPL-3.0-or-later -->

/design — the design pipeline (the `/work-on` analog for design)

**Input**: $ARGUMENTS — a design issue number, or a seed brief name (`cadence` | `tender` | `slipstream` | `voltage` | `plume`) which is opened as a design issue first.

This is the **spine of the UI Taste Harness** (milestone #13, issue #888). Just as a code task is a GitHub issue routed `investigate → build → review → close` by [`/work-on`](work-on.md) — accumulating `FORGE:*` annotations, closed at the end — a **design task is a GitHub issue routed through this design pipeline**, accumulating `FORGE:DESIGN_*` annotations and closed when the design ships and passes its gates. It is a parallel track on the same "GitHub as a knowledge graph" model, not a new paradigm.

**It IS arm A of the ABC benchmark (#878).** Running a brief through `/design` produces the arm-A output; the benchmark rig (`/design-bench`) feeds briefs in and screenshots the result, so this command is what makes the benchmark runnable end to end.

**Agent model policy**: `model: "claude-opus-4-6"` — Opus is the validated generation model. Benchmark #878 (90% A-vs-B pairwise win-rate with Opus vs 54% with Sonnet) confirms a tier-level quality difference. Both arm A and arm B MUST use the same model to keep the benchmark valid (see [design-bench](design-bench.md)).

**No application runtime.** ForgeDock is a set of command specs. `/design` *sequences* the already-built stage specs — it does not reimplement them. The only executable helper in the chain is the deterministic linter `scripts/design-system-lint.mjs` (#884).

---

Universal Stage Dispatcher

<!-- This is the single source of truth for design:* transitions, mirroring /work-on's Universal Phase Dispatcher. -->

| Stage | design:* label | Terminal? | Reads | Produces | Spec it sequences | |-------|----------------|-----------|-------|----------|-------------------| | 1. design-investigate | `design:investigating` | No | the brief | `FORGE:DESIGN_CONTEXT` | corpus #880 (grammar) + memory #887 (what to diverge from) | | 2. design-architect | `design:architecting` | No | `FORGE:DESIGN_CONTEXT` | `FORGE:DESIGN_RATIONALE` → `FORGE:DESIGN_CANDIDATES` → `FORGE:DESIGN_SPEC` | rationale #886, divergent generation #883, effects #885, schema #881 | | 3. design-implement | `design:generating` | No | `FORGE:DESIGN_SPEC` | the generated page (artifact) | — (generate from the committed spec) | | 4. design-critique | `design:critiquing` | No | the render + `FORGE:DESIGN_SPEC` | `FORGE:CRITIQUE` (per pass) | render→critique loop #882 (lint #884 floor + perf #875 + a11y) | | 4.5. user-feedback | `design:awaiting-feedback` | No | `FORGE:CRITIQUE` + user input | `FORGE:USER_FEEDBACK` (per round) | this spec (#1044); bypassed in automated/benchmark runs | | 5. design-close | `design:shipped` / `design:rejected` | **Yes** | `FORGE:USER_FEEDBACK` (latest) or `FORGE:CRITIQUE` | `FORGE:DESIGN_SHIPPED` | scorecard + write outcome to memory #887 |

**Continuation rule** (mirrors `/work-on`): after any stage completes, if the issue is not at a terminal label (`design:shipped` or `design:rejected`), proceed to the next stage immediately. No intermediate stage is terminal. `design:awaiting-feedback` is **non-terminal** — it resolves to Stage 5 when `FORGE:USER_FEEDBACK.satisfied == "yes"` or when no user is present (automated runs bypass Stage 4.5 entirely).

---

Stage 1 — design-investigate (`design:investigating`)

Parse the brief into message / audience / single objection. Pull the relevant grammar from the [reference corpus](../docs/design/reference-corpus.md) (#880) and query [design-memory](../docs/design/design-memory.md) (#887) for the recent signature moves / archetypes / palettes to **diverge** from. Post `FORGE:DESIGN_CONTEXT`.

Stage 2 — design-architect (`design:architecting`)

Run the [design-architect rationale](../docs/design/design-architect-rationale.md) (#886): the 7-element diary → `FORGE:DESIGN_RATIONALE`. Then [divergent generation](../docs/design/divergent-generation.md) (#883): commit one archetype, diverge into N directions, independent taste-judge selects → `FORGE:DESIGN_CANDIDATES`. The winning direction + the [effects-appropriateness](../docs/design/effects-appropriateness.md) (#885) `effects_plan` are committed into `FORGE:DESIGN_SPEC` ([schema](../docs/design/design-spec-schema.md), #881).

Stage 3 — design-implement (`design:generating`)

Generate the page from the committed `FORGE:DESIGN_SPEC`. The spec is the contract — no taste decisions are re-rolled here; generation realizes the committed intent.

Foundation CSS injection <!-- Added: forge#1048 -->

Before generating the page, inject the archetype's pre-built CSS foundation as the starting stylesheet. Foundation files live in `docs/design/foundations/` and are keyed by `meta.archetype` from `FORGE:DESIGN_SPEC`:

| `meta.archetype` | Foundation file | |---|---| | `editorial-typographic` | `docs/design/foundations/editorial.css` | | `technical-dense` | `docs/design/foundations/technical.css` | | `minimal-luxury` | `docs/design/foundations/minimal-luxury.css` | | `bold-brutalist` | `docs/design/foundations/brutalist.css` | | `warm-photographic` | `docs/design/foundations/warm-photo.css` |

**Injection pattern**: read the foundation file content and include it in the generation prompt as the starting `<style>` block. Instruct the generator to: 1. Use the foundation's component classes (`.btn`, `.card`, `.badge`, `.input`, `.reveal`) where applicable — do NOT replac