Design That Ships: Design as a Contract, Not a Deliverable

Most AI design tools end at the moment the picture looks good. You type a brief, a beautiful artifact streams in, you export it — and then it dies in a folder. The hard part, turning that design into shipped, verified product code that still matches the design, is left entirely to you.

I built OpenPlanr's design phase on the opposite stance: a design is only valuable if it survives all the way to production. So in the pipeline, design isn't a destination — it's the first governed phase of a delivery process that runs PO → DEV → Ship, with a mandatory human checkpoint between planning and building.

This post walks through the three design surfaces, shows exactly how I run the full flow, and explains why a pipeline-integrated design phase beats a standalone studio for anyone whose real goal is shipped software.

Design as a contract

When the design phase finishes, the headline output isn't the pretty HTML. It's a 10-section design-spec.md — a machine-readable contract covering color, typography, spacing, components (with every state), navigation, iconography, motion, overrides, a screen inventory, and open questions.

That spec is load-bearing. Downstream:

• the planning agent decomposes it into UI and backend tasks,
• the frontend agent builds against it,
• the QA agent verifies the build matches it, and
• a design-fidelity gate flags any screen that drifts off the approved palette.

The artifact is a throwaway proof. The contract is the deliverable, and the contract is enforced through to ship.

  /design ──► design-spec.md ─┬─► /plan ─► UI + backend tasks ─► /ship ─► built code
  (or PNG mockups)            │                                     │
                              └───────────────── verified against ◄─┘
                                          (QA + design-fidelity gate)

The three design surfaces

1. /design — generate one artifact and the spec, before decomposition

This is the front door. I pick a format and a source; it produces an interactive artifact and authors the design-spec.md that the rest of the pipeline consumes.

/planr-pipeline:design billing --format walkthrough --from describe

Three formats, one shared core:

--from can be spec (an existing functional spec), png (mockups), or describe (a brief). Supply --format and --from together and it runs fully non-interactive — CI-safe. It stops when done. It never auto-chains into planning. That's a hard rule, not an oversight.

2. /design-loop — explore variants on a live comparison board

When I don't yet know the direction, this is the divergent-exploration mode. It generates N variants in parallel, serves them on a localhost comparison board, and lets me be the chooser.

/planr-pipeline:design-loop billing --provider auto --count 4

On the board I can:

• rate each variant,
• pin exact regions with intent (fix / improve / question) — pins are content-anchored to the real coordinates,
• remix — compose a new variant from "layout of A, colors of B",
• A/B diff two versions side by side,
• iterate — the board reloads in place as new variants come in.

Critically, it confirms cost before any spend, works with or without an image-gen API key (a vector/SVG path is first-class, not a fallback), and writes a per-project taste profile — font, color, layout, and aesthetic preferences, with confidence that decays over time so stale tastes fade. The pipeline learns what I like across projects.

3. /design-review — pin-fix an existing design, then sync the spec

Once a design exists, this turns it into a live review canvas. I pin "fix THIS" on a specific screen; the loop regenerates only that screen — surgically, behind a lint gate that holds at 0 errors (off-grid spacing and sub-AA contrast are hard failures).

/planr-pipeline:design-review billing

The part nothing else does: when I approve, it writes the changes back into the contract — updating only the design-spec.md sections that actually changed, bumping the iteration counter, and appending a lineage record to the run manifest. The design and its spec never drift apart.

The full flow, end to end

Here's a complete worked example — from blank idea to shipped, design-verified code.

# 0. Install (one time) — planr-pipeline is a Claude Code plugin
/plugin marketplace add openplanr/marketplace
/plugin install planr-pipeline@openplanr
 
# 1. DESIGN — generate the artifact + design-spec.md
/planr-pipeline:design billing --format walkthrough --from describe
#   → .../design/finalized.html    (the interactive proof)
#   → .../design/design-spec.md     (the 10-section contract)
 
# 2. (optional) EXPLORE — if you want to choose between directions first
/planr-pipeline:design-loop billing --provider auto --count 4
#   → live board: rate, pin, remix, approve → taste profile updated
 
# 3. REVIEW — pin specific screens, regenerate, sync the contract
/planr-pipeline:design-review billing
#   → pinned screens regenerated (lint 0 errors)
#   → design-spec.md + manifest synced
 
#  ── human checkpoint: review the design + spec ──
 
# 4. PLAN (PO phase) — decompose into stories + UI/backend tasks
/planr-pipeline:plan billing
#   → User Stories + tasks, each UI task bound to the design-spec
 
#  ── human checkpoint: review the decomposition ──
 
# 5. SHIP (DEV phase) — build, QA against the spec, infra, docs
/planr-pipeline:ship billing
#   → frontend + backend code per task
#   → QA verifies the build matches design-spec.md
#   → design-fidelity gate flags any off-palette drift

Notice the two human checkpoints. The pipeline refuses to auto-chain design → plan → ship. You inspect the design before it's planned, and the plan before it's built. That gate is where expensive mistakes get caught cheaply — and it's enforced at the tool layer, not just suggested in a prompt.

Why a pipeline-integrated design phase wins

Here's the honest, architecture-level comparison. There are broadly two ways to put AI into design.

Category A — the standalone design studio. Brief in, artifact out, export, done. Optimized for breadth of output in one sitting: lots of templates, brand kits, media formats.

Category B — design as a governed phase of a delivery pipeline (what I built). Optimized for how much of the design survives to production.

The difference only matters if your goal is shipped software — but if it is, it's decisive:

The structural point: in a standalone studio, the deliverable is the file, and the file is where responsibility ends. In a pipeline, the deliverable is verified product code, and the design is the contract that guarantees it.

Everything that makes design trustworthy across phases lives on the pipeline side: a no-auto-chain rule with human checkpoints, spec write-back so design and intent never diverge, lint and fidelity gates, persistent taste memory, and a recorded manifest of every change. A studio can make a more elaborate picture faster. It can't tell you whether what you shipped matches what you approved.

So which wins? For producing a one-off asset — a landing concept, a brand exploration — a studio is great, and the two approaches are genuinely complementary (you can even feed studio exports into the design phase as a starting point). But for the thing that actually matters — getting an approved design all the way into shipped, verified code — a pipeline-integrated design phase wins, because it's the only one of the two that has a DEV phase and a ship phase at all.

Try it

/plugin marketplace add openplanr/marketplace
/plugin install planr-pipeline@openplanr
/planr-pipeline:design your-feature --format walkthrough --from describe

Design it. Review it. Plan it. Ship it — and let the pipeline prove the shipped result matches what you approved.

Links

• OpenPlanr · npm · GitHub
• planr-pipeline · GitHub