Phase 1: The Brand Contract

The pipeline spine starts with a single file: your DESIGN.md. Everything else in the pipeline reads from it. If the file is vague, every agent output will be vague. Get this right first.

A DESIGN.md is a machine-readable brand contract. It encodes color palette, typography, spacing grid, component patterns, interaction rules, voice, and reserved constraints---all as plain text that every agent CLI can read. Open Design ships 150 bundled brand systems (as of June 2026, v0.9.0), but the only one that matters for your pipeline is the one you write for your own organization.

The schema has nine sections, each with a specific role. An agent needs all nine to produce consistent output; missing sections fall back to model defaults, which is exactly what you are trying to prevent.

# DESIGN.md: Acme Design System

## 1. Brand identity
- **Name:** Acme Inc.
- **Voice:** Clear, direct, no jargon. No exclamation marks.
- **Attitude:** Trustworthy and practical.

## 2. Color palette
- **Primary:** #0B5FFF (electric blue)
- **Surface:** #0A0A0A (near-black)
- **Text:** #FFFFFF (white)
- **Border:** #333333

## 3. Typography
- **Sans-serif:** Inter
- **Font scale:** 12px, 14px, 16px, 18px, 20px, 24px, 32px
- **Line height:** 1.5 for body, 1.2 for headings

## 4. Spacing grid
- **Base unit:** 8px
- **Scale:** 4px, 8px, 12px, 16px, 24px, 32px, 48px, 64px

## 5. Component patterns
- **Buttons:** 32px height, rounded 4px corners, medium weight
- **Cards:** 1px border, 8px padding, no drop shadows
- **Forms:** labels above inputs, error states in red

## 6. Imagery
- **Style:** minimalist, high-contrast, no decorative shadows
- **Sources:** Unsplash, Pexels (attribution required)

## 7. Layout principles
- **Max width:** 1200px
- **Responsive breakpoints:** 640px, 1024px, 1280px

## 8. Interactions
- **Hover states:** 10% opacity shift
- **Focus states:** 2px outline in primary color
- **Transitions:** 150ms ease-out for all state changes

## 9. Reserved rules
- No marketing superlatives
- Contrast ratio must be >= 4.5:1 on all text

Build a single-page error state using the house DESIGN.md.
Show a 404 message with a primary CTA button and the brand voice.

$ git add DESIGN.md
$ git commit -m "feat: add Acme house DESIGN.md v1"

What Makes a Strong Brand Contract

The difference between a weak and a strong DESIGN.md is specificity at the constraint level. Vague rules produce vague output. "Use blues and grays" is not a brand contract; it is a suggestion. "Primary: #0B5FFF; background: #0A0A0A; text: #FFFFFF; no gradients; no drop shadows" is a constraint the agent can enforce on every artifact.

The voice section (Section 1) and the reserved rules section (Section 9) are the two most under-authored sections. Most teams fill in the colors and typography quickly, then leave voice as one sentence. A weak voice section means marketing copy that sounds like a different company from one artifact to the next. Spend at least as much time on voice and reserved rules as on colors---these are what make your artifacts feel like you, not like a generic AI output.

Phase 2: House Skills

The brand contract is the what; skills are the how. A skill constrains structure, output format, and artifact shape so the same prompt reliably produces consistent output across runs.

Open Design ships 100+ skills as of June 2026 (v0.9.0). Most teams need two to four house skills that are not in that catalog: the artifact shapes specific to their product. A SaaS company might need a feature-announcement skill. A consultancy might need a client-deck skill. These are the skills that encode your team's standards once and apply them on every run.

# skill: saas-landing
description: Single-page SaaS landing with hero, features, CTA
constraints:
  - hero section: headline + subheadline + primary CTA
  - feature section: three cards, icon + title + body
  - footer: privacy link, terms link, company name
  - no secondary navigation in hero
  - responsive: 640px breakpoint for mobile layout
output: single-page-html
brand: reads from DESIGN.md in project root

Use the saas-landing skill with the house DESIGN.md to build
a landing page for a team productivity tool.
Product name: Acme Workflow. Tagline: Ship faster together.

Phase 3: Two Agents via MCP

The pipeline spine is agent-agnostic by design. Wire two agents: one proprietary for depth, one open-source for independence. The Model Context Protocol (MCP) is the connection layer---the same for every agent.

As of June 2026, Open Design supports 21 agent CLIs via MCP adapters (see the agent adapter catalog). The two-agent hedge is straightforward: Claude Code gives you Anthropic's reference implementation with full streaming and surgical edit capability; OpenCode gives you an MIT-licensed fallback that survives any vendor pricing or sunset event. The pipeline spine never requires a specific agent; it requires MCP connectivity.

$ od mcp install claude-code

$ od mcp install opencode

$ od status agents

The two-agent strategy is the pipeline's insurance policy. You generate with Claude Code on a daily basis; if Anthropic changes pricing, access, or capabilities, you switch to OpenCode without touching the pipeline structure. The daemon routes to whichever agent you designate as primary; the MCP protocol is the same either way.

The selection of Claude Code and OpenCode as the two-agent pair is a recommendation, not a requirement. The principle is: one agent with deep context-window capability and surgical edit support, and one agent with an open-source license that is not tied to any single vendor's commercial roadmap. As of June 2026, that pairing is Claude Code (Anthropic, proprietary) and OpenCode (MIT, community-maintained). If the agent market shifts---and as documented in section 11.4, it will---you substitute at the MCP layer without touching the pipeline spine.

Phase 4: Variation Workflow

A multi-agent variation step is where the two-agent wiring pays off creatively. Run the same prompt through both agents, compare outputs, and pick or blend the best parts. This is not an automated merge---it is a deliberate human decision backed by two independent agent interpretations.

The variation workflow is especially valuable for hero sections, landing page layouts, and deck visuals---any artifact where there is genuine design space to explore. Single-agent generation produces one interpretation; two agents produce a genuine choice.

# Variation run: Three hero layout options

## Setup
- DESIGN.md: Acme brand contract
- Active agents: claude-code, opencode
- Skill: saas-landing

## Prompt (identical to both agents):
Build a SaaS landing page using the Acme DESIGN.md.
Hero: headline, subheadline, primary CTA.
Three feature cards below the fold.
Brand colors from DESIGN.md. No stock images.

$ # In Open Design UI: select claude-code, run the prompt
$ # Artifact saved as artifact-claude-code-001.html

$ # In Open Design UI: switch to opencode, run same prompt
$ # Artifact saved as artifact-opencode-001.html

Phase 5: Code-Refresh Integration

The code-refresh plugin closes the loop between the artifacts you generate and the codebase you ship. Instead of manually porting design tokens from an artifact into your production code, the plugin reads your DESIGN.md and proposes a diff that aligns component tokens in your codebase to the brand contract.

As of June 2026, the code-refresh plugin is listed as alpha in the Open Design roadmap (v0.9.0). The plugin is the most powerful and the most volatile phase of the pipeline---it has the highest staleness risk as the API is not yet finalized.

$ od plugin list | grep code-refresh

$ od plugin code-refresh \
  --repo-path /path/to/acme-website \
  --design-path ./DESIGN.md \
  --scope src/components \
  --dry-run

$ od plugin code-refresh \
  --repo-path /path/to/acme-website \
  --design-path ./DESIGN.md \
  --scope src/components \
  --commit-message "refactor: align tokens to Acme DESIGN.md v1"

# DESIGN.md updated: new primary color
# Run dry-run first
$ od plugin code-refresh \
  --design-path ./DESIGN.md \
  --scope src/components \
  --dry-run

# Review diff, then apply
$ od plugin code-refresh \
  --design-path ./DESIGN.md \
  --scope src/components

# Running without --dry-run first
# skips the review step and applies all
# proposed token changes immediately.
# A vague DESIGN.md can introduce regressions.
$ od plugin code-refresh \
  --design-path ./DESIGN.md \
  --scope src/

Phase 6: Export and Review Gate

The export and review gate is the human decision point. No artifact leaves the pipeline without a person verifying it against the brand contract. The export step produces the canonical files; the review gate is your quality assertion.

Open Design's export pipeline produces HTML (inlined), PDF, PPTX, ZIP, Markdown, and MP4 from a single artifact (as of June 2026, covered in depth in section 08.3). The pipeline spine codifies which formats are canonical for which artifact types, so the review checklist is consistent across runs.

$ od export \
  --artifact-id hero-landing-v3 \
  --formats html,pdf,pptx \
  --output ./exports/hero-landing-v3

$ od approve \
  --artifact-id hero-landing-v3 \
  --reviewer @yourname
# Marks artifact as approved in the project record

$ tar -czf hero-landing-v3-approved.tar.gz ./exports/hero-landing-v3
# Copy to your team's shared storage

The Finished Pipeline

The pipeline spine is now assembled. Six phases, six outputs, two agents, one brand contract. Before you hand it to your team, document it and stress-test it with a full run.

The pipeline is worth documenting even for a team of one. The act of writing the spine down is what makes the output reproducible. Undocumented agent workflows become unrepeatable within weeks as model defaults drift, agent versions update, and the person who remembers the prompt structure leaves.

Full Pipeline Run

Run the entire pipeline end to end once before handing it to your team. Use this compound prompt to kick off a full pass:

Using DESIGN.md and the house deck skill, generate a launch deck;
variations agent: three hero options using both claude-code and
opencode; then run code-refresh on src/ui to the same tokens
and export the deck to PPTX and PDF.

The pipeline spine handles the orchestration. You review the variations at phase 4, approve the exports at phase 6.

Pipeline Phases Summary

Pipeline Reuse Checklist

Pipeline Troubleshooting

Agent-Independence Note

The pipeline spine is intentionally agent-agnostic. As documented in section 11.3, the agent market churns: Gemini CLI sunsets June 18, 2026; OpenCode has been renamed once; Codex CLI ships near-weekly releases. The spine should never have an agent name hardcoded into it. Agents are wired at the MCP layer; the pipeline documentation refers to "primary agent" and "secondary agent," not "Claude Code" or "OpenCode." When a better agent arrives, you swap the connection without rewriting the spine.