--- name: design-build description: "In-repo design lane. Dispatches design-builder agents over design-backlog rows whose briefs conform to an existing page scaffold, then integrates as single writer — wire the prototype entry point, record provenance-at-birth, flip the boards — with a human sign-off checkpoint on the rendered screenshot and an optional fused reconstruction. Usage: /design-build [--and-reconstruct] [--auto-accept]" argument-hint: " [--and-reconstruct] [--auto-accept]" --- > **Specialization:** Read `CLAUDE.md` first and bind every `<…>` placeholder and every "per `CLAUDE.md`" reference from it (design-backlog board path, design-prompts board path, prototype location + entry point + file pattern + route/step resolver, sidecar convention, lane-routing rule, screen registry path, concurrency cap). This file hard-codes no project value. If a needed value is missing from `CLAUDE.md`, STOP-and-ask. See `SPECIALIZE.md`. You are the **orchestrator** for the in-repo design lane. You dispatch `design-builder` agents over design-backlog rows and you are the **single writer** (Law 3) of everything shared: the prototype entry point + route resolver, the screen registry, the design-backlog and design-prompts boards, and the memory trio. Agents write only their own new files and return reports. ## When to use — and when NOT to - **Use** for `☐ Needs Design` rows that pass the lane-routing rule (per `CLAUDE.md`): scaffold-conforming, reference screens exist, no exploratory iteration requested, not a new module's first screens. - **Do NOT use** for console-lane work (novel patterns, new-module visual language, "show me directions") — promote those rows to the design tool per the design-prompts board's how-to, and ingest the delivery with `/promote-design`. - This command replaces the console round-trip **only** for rows where the console adds no design capability — the model is the same on both sides; the console's value is interactive human canvas iteration, which these rows don't need. ## 1. Resolve targets Parse `$ARGUMENTS`: - One or more backlog row ids (`DB-…`-style, per the board's ID scheme) → those rows. - A module code → all `☐ Needs Design` rows of that module. - `next` → the first `☐` Must-have row (fall back to the first `☐` row). - `must-have` → all `☐` Must-have rows. Read the design-backlog board + design-prompts board (paths per `CLAUDE.md`). For each target verify: status is `☐ Needs Design`, and a brief block exists on the design-prompts board — if the brief is missing, fire the **`design-prompt-authoring`** skill to author it first (it is the successive output of every row; a missing brief is a pipeline bug to fix, not to work around). ## 2. Lane-route (pre-dispatch filter) Apply the lane-routing rule (per `CLAUDE.md`) yourself before dispatching; drop console-lane rows from the batch and say so in the summary (with the promote path). The agent re-checks and may still return `Rerouted` — trust its judgment over your pre-filter. ## 3. Claim Flip each dispatched row's design-backlog status to `◐ In Design (in-repo)` and sync the design-prompts index. You are the only writer of the boards. ## 4. Dispatch (parallel, capped per `CLAUDE.md`) One `design-builder` per row, concurrently (cap per `CLAUDE.md`; default 8). Prototype screen files are independent new files, so no seed gate applies — but keep rows of the **same module** in the same batch so the agents' vocabulary inventories stay consistent. Pass each agent: the row id, its full brief block **including the Global preamble**, the reference-screen paths, **the journey splice packet**, and `CLAUDE.md`'s path. Assemble the packet before dispatch: when the row originated from a `/journey-audit` GAP, lift the from→to edges + continuity-ledger excerpt from that audit's report file (in the approval inbox); otherwise derive it from the row's workflow (`_WORKFLOW.md` step chain) — the upstream screen's source + the CTA that leads in, the downstream route + its context key. A row with no journey at all (a true standalone, e.g. a settings console) dispatches without a packet — but say so explicitly; silence is not a decision. Retry a failure ≤2 times (Law 11), then file it in the approval inbox and continue. ## 5. Checkpoint — human sign-off on the render (the designer-sign-off gate, preserved) Collect reports. For each `Done`, present the sign-off screenshot (`docs/APPROVAL_INBOX/…`) + the sidecar summary + the vocabulary-check line to the human, batched. Law 1's phase-1 gate is *designer sign-off* — moving design in-repo does not remove the human from the loop, it moves them **on** the loop (approve renders, not courier zips). - `--auto-accept` (or the equivalent `CLAUDE.md` policy) may skip the interactive pause **only** for rows whose report shows a fully green render-evidence + vocabulary line; anything amber still stops. - A rejected render goes back to the agent with the human's notes (≤2 retries, then approval inbox). ## 6. Integrate (single writer — this is where provenance-at-birth lands) For each accepted report, in this order: 1. **Wire the prototype**: apply the report's *Proposed wiring* lines — the entry-point include and the route/step-resolver entries — **and the Splice inbound repoint** (the upstream screen's CTA now targets the new route; if that upstream source belongs to a **built `✅`** screen, the repoint is drift by definition — route it through `design-sync` instead of editing directly, and say so). Refresh the provenance hash of any prototype source you touched. Re-render the entry point once per batch to confirm every new route resolves (a broken resolver is a batch blocker, not a per-row note). 2. **Screen registry**: add the `☐` row (route, name, archetype, module) with the provenance note `born=in-repo · brief= · hash=<…> · `. Because provenance is recorded at birth, this screen **never needs a drift-triage pass** unless a human later edits its prototype source — `design-sync`'s scope shrinks accordingly. 3. **Boards**: design-backlog row → `✅ Designed (in-repo, )`; design-prompts index synced; keep the brief block for provenance. 4. **Memory trio**: `PROGRESS.md` activity line; graduate Insights/Lessons; a stable lesson about the lane itself → `CLAUDE.md` hard rule. ## 6b. Continuity delta check (the feedback half of the journey pairing) A screen that satisfies its own invariants can still leave the journey broken — the splice has two ends and both were just edited. So, per affected journey (from the splice packets), before calling the batch done: - **Re-run the Phase-0 edge ledger** (the `journey-continuity-audit` skill) scoped to that journey's screens — cheap, mechanical, grep-based. Prove: the GAP's inbound edge flipped from `DEAD-END/missing` to `OK` (destination exists, context key carried), the new screen's outbound edge is `OK`, and **zero new dead/legacy/wrong edges** appeared anywhere in the journey. - For a large batch (3+ screens on one journey) or any amber result, **re-dispatch `journey-auditor`** scoped to that journey instead — the full trace, not just the ledger. - Record the verdict per gap: `GAP-nn closed by · splice verified` — or reopen it. **Boards stay flipped only on green**; an amber delta check reverts the row to `◐` with the finding. ## 7. Optional fused reconstruction (`--and-reconstruct`) When passed (or when the calling sweep needs the screen now), immediately run the project's reconstruction command over the new `☐` rows — same session, prototype sources still warm. Hand each `screen-reconstructor` the sidecar path alongside the route (its completeness checklist). This is the fused design→reconstruct path: one screen's design intelligence, paid once; the fidelity gate is unchanged. ## 8. Report Summarize: rows designed / rerouted / blocked; wiring applied; registry + board deltas; sign-off decisions; reconstruction results if fused; anything filed to the approval inbox.