Features in isolation are easy to follow. Workflows under deadline pressure are where the gaps show. This chapter runs four end-to-end cases, each with a concrete goal, the agent and skills that drove it, the exact steps, the output, and the failure that appeared mid-run. The mental model is goal to shipped: state the goal, pick your tools, run the loop, export, and do a retrospective. Use these cases as templates. The arc doesn't change; only the artifacts and the failure modes do.

All four cases run against Open Design v0.9.0 (released June 2, 2026). Feature availability, plugin behavior, and render characteristics are tied to that snapshot---treat later versions as potentially different.

Before the individual cases, here is a summary of all four at a glance.

Each case follows the same five-beat structure: Goal, Setup, Steps, Output, Retrospective. The retrospective is where the real learning is.

13.1 Case 1: Stakeholder Review Package

A product designer ships a branded pitch deck plus a clickable mobile prototype for a feature stakeholder review. The goal is two artifacts from one session: a 12-slide PPTX the PM can present and an HTML prototype the team can click through on any device. This is the highest-volume entry point for design teams adopting Open Design.

Goal

Deliver a stakeholder review package by end of day: a 12-slide deck in the Swiss International style using the team's house DESIGN.md, exported to PPTX; and a 4-screen mobile prototype for the feature under review, exported as self-contained HTML.

Setup

Agent: Claude Code, connected via od mcp install claude-code. Brand system: the team's house DESIGN.md (authored per Chapter 05). Skills invoked: the deck skill and the mobile-prototype skill. Export targets: PPTX (deck) and HTML (prototype).

Steps

Build a 12-slide stakeholder review deck using our DESIGN.md brand system:
  Slide 1: Title (problem statement)
  Slide 2: Why it matters
  Slides 3-5: Three wireframe mockups of the feature
  Slide 6: Interactive prototype preview (note)
  Slides 7-8: Roadmap and dependencies
  Slide 9: Resource ask
  Slide 10: Risks and mitigations
  Slide 11: Success metrics
  Slide 12: Q&A placeholder
Use the Swiss International deck template. Export to PPTX.

Build a 4-screen mobile prototype flow for the feature using the DESIGN.md brand:
  Screen 1: Entry point (empty state)
  Screen 2: First use (onboarding step)
  Screen 3: Main interaction
  Screen 4: Success state
Include a working bottom-sheet component and a floating action button. Make it clickable.

Output

A 12-slide PPTX with brand-compliant colors, type, and wireframe slide layouts; a 4-screen clickable HTML prototype openable from any file attachment without a local server. Total generation time: roughly 12 minutes including two iteration passes, order of magnitude only.

Retrospective

What went wrong: The "Swiss International" template's fixed layout cropped the wireframe mockup images on slides 3–5. A correction prompt asking for a full-bleed image layout on those slides fixed it. This is a common first-pass failure with structured deck templates---the template's layout constraints and the prompt's content spec can conflict.

Rule extracted: Generate the deck first and iterate to lock its layout; then generate the prototype. Running them concurrently produces cross-artifact inconsistency that's slower to resolve than sequential passes.

13.2 Case 2: Legacy App Brand Refresh

A design engineer runs the code-refresh-to-brand-spec scenario plugin across the component directory of a legacy React app. The goal is to replace hardcoded color and spacing values with DESIGN.md tokens and produce a reviewable diff, without manually touching every file. This is the case that changes minds in engineering orgs.

Goal

Bring the src/components directory of a two-year-old React application into compliance with a new house DESIGN.md brand contract: replace hardcoded hex values, normalize spacing to the design token grid, and output a git diff the team can review before merging.

Setup

Agent: Claude Code. Plugin: code-refresh-to-brand-spec (official scenario plugin, as of June 2026). Brand contract: house DESIGN.md authored per Chapter 05. Critical precondition: the codebase must be in a clean git state before the plugin runs. The plugin writes directly to source files---an uncommitted worktree is a disaster waiting to happen.

Steps

$ git checkout -b brand-refresh/design-tokens

Refresh the src/components directory of this React app to match our DESIGN.md brand contract:
  1. Replace all hardcoded colors with tokens from DESIGN.md
  2. Standardize spacing using our type scale and spacing grid
  3. Update component shadows, borders, and border-radius to match the brand
  4. Audit for remaining color, spacing, or type violations
  5. Produce a change report: files modified, tokens applied, remaining violations
  6. Leave the diff readable for manual review in git

$ git diff src/components/

Output

A modified src/components directory with brand-token-compliant colors and spacing; a structured change report listing files touched, tokens applied, and violations remaining; a clean git diff ready for PR review. On the test codebase (42 components), the plugin resolved the large majority of color replacements in the first pass; complex CSS-in-JS components with multi-purpose color values required a follow-up iteration.

Retrospective

What went wrong: The plugin misidentified semantic intent on three CSS-in-JS components that used one color value for both a background and a border. It replaced both with the brand's primary action color---correct for the background, wrong for the border. The change report flagged these as "ambiguous token mappings." I missed the flag on the first read and caught the errors in the diff.

Rule extracted: Read the change report before the diff, not after. It tells you which components have ambiguous mappings. Don't merge a brand-refresh PR without the diff review gate---that is the safety contract for this plugin.

13.3 Case 3: Figma to Component Library

A product team migrates a Figma design file to a Next.js component library using the Figma migration scenario plugin. The goal is a first-pass set of TypeScript components that preserve the Figma structure, not a production-ready merge. This case is a strong first pass, not a full automation---set expectations accordingly.

Goal

Take a Figma file with 20 frames and a component library, and produce a Next.js src/components directory with one .tsx file per component, a shared index.ts export. The Stripe brand system bundled with Open Design is used in this case as a structural reference only---for its type scale and spacing rhythm---to illustrate how a bundled DESIGN.md file can inform layout patterns. The output components are neutral and do not reproduce Stripe's visual identity or trade dress. See the trademark notice above and the warning below; use your own brand contract for any production work. (See also section 5.1.)

Setup

Agent: Cursor, connected via od mcp install cursor. Plugin: figma-migration scenario plugin (official, as of June 2026). Brand reference: Open Design's bundled Stripe DESIGN.md file, used to provide structural values (type scale, spacing rhythm) for illustration only---not for production and not to reproduce Stripe's protected visual identity. Input: Figma file exported as a shareable link or Figma JSON export. (Figma and the Figma logo are trademarks of Figma, Inc., used here for identification only.)

Steps

Migrate this Figma file to a Next.js component library:
  1. Parse the Figma file and extract all frames and components
  2. Generate a reusable Next.js functional component for each
  3. Preserve auto-layout and constraint structure where possible
  4. Export each component as a TypeScript .tsx file
  5. Generate an index.ts that exports all components
  6. Apply the structural type scale and spacing values from the bundled Stripe DESIGN.md
     file as layout reference only. Do not reproduce Stripe's visual identity or branding.
  7. Output as a structured src/components directory

Output

A src/components directory with TypeScript components for 17 of the 20 Figma frames; 3 complex auto-layout components required manual post-processing. The index.ts export was complete and correct. The components are structurally neutral---they apply spacing and type scale values from the bundled DESIGN.md reference and do not depict or reproduce Stripe's visual identity. They were structurally sound as a first pass and required roughly 2 hours of manual work to reach PR readiness on a 20-component scope---treating the migration as "strong first draft, not merge-ready" is the right frame.

Retrospective

What went wrong: A component using overlapping layers to simulate a z-index stacking effect did not survive migration. The plugin parsed the frame structure correctly but generated flat HTML that lost the layering. Manual fix: CSS position: relative and z-index. This is a known friction point---design-tool layering semantics and CSS stacking contexts are not equivalent. Simple migrations (buttons, cards, inputs, type specimens) were accurate and fast.

Rule extracted: Use the Figma migration plugin as a first-pass accelerator, not a production pipeline. Budget 20–30% of the output for manual cleanup, concentrated on complex interactions and overlapping layers. The accelerator value is real; the "100% automatic" expectation is not.

13.4 Case 4: Motion and Image Campaign

A marketing team generates a 20-second HyperFrames motion graphic plus three matching product hero images for a campaign launch. This case exercises the "one brand, many surfaces" capability from Chapter 07---the same brand token set drives the motion timing and the image color palette. It also has the longest feedback loop of the four cases, because HyperFrames renders are CPU-intensive and not instant.

Goal

Produce a campaign asset set: one 1080p MP4 motion graphic showing the product logo assembling on a grid (20 seconds, loopable), and three hero PNG images at different scenes (desk view, mobile close-up, team collaboration). All assets must use the house brand accent color and Inter typeface from the DESIGN.md.

Setup

Agent: Claude Code. Skills: HyperFrames skill for the motion graphic; image generation via gpt-image-2 configured as the image provider. (gpt-image-2 is a product name used here for identification only; OpenAI and gpt-image-2 are trademarks of OpenAI; this reference does not imply affiliation or endorsement.) Brand system: house DESIGN.md. Note: the motion graphic uses the brand accent color from DESIGN.md; the image generation prompt passes the hex value manually because image models do not parse DESIGN.md tokens directly.

Steps

Build a 20-second HyperFrames HTML animation loop of a product logo
assembling from grid lines, using brand accent color and Inter sans-serif.
The logo appears at 8s, holds at 12s, then fades to the tagline.
Make it loopable. Export to MP4 at 1080p.

Generate three hero product images for the campaign:
  Image 1: Laptop showing a software dashboard (3/4 angle, minimalist desk)
  Image 2: Hands interacting with a mobile interface (product UI on phone)
  Image 3: Flat-illustration team collaboration scene (people working together)
Brand color palette: primary green #15803D, surface white.
Style: professional, confident, no text in images.
Provider: gpt-image-2

Output

A 1080p MP4 motion graphic at 22 seconds (the render added 2 seconds to the fade-out---worth noting for timing-critical campaigns); three PNG hero images at 1792×1024 (gpt-image-2 default resolution). The brand color applied correctly in the motion graphic. One of the three images (the team collaboration scene) required a second-pass prompt to remove text elements that the model added despite the prompt instruction.

Retrospective

What went wrong: The render added 2 seconds beyond the requested duration---the fade-out easing function extended the last frame. Fix: a follow-up prompt specifying a hard cut at exactly 20 seconds and a full re-render (another 9 minutes). Image generation models do not read DESIGN.md; the "confident" mood instruction was interpreted inconsistently across the three images. Per-shot briefs produce more reliable results than batching three images in one prompt.

Rule extracted: Verify animation logic in the HyperFrames preview before triggering the MP4 render. One preview check costs seconds; one incorrect re-render costs 10 minutes. HyperFrames is a deliberate artifact type, not a rapid-fire one.

13.5 What the Cases Share

Four different goals, four different artifact types, four different failure modes---and a common structure underneath. Extracting that structure is what makes the cases templates rather than one-off stories.

The Shared Arc

Every case ran the same goal-to-shipped arc: state the goal precisely, select the agent by constraint, pick the skill or plugin, run the generate-preview-iterate-export loop, and do a retrospective that names one real failure and its fix. The arc is simple. What varies is the failure mode, and that is where the learning lives.

The recurring failure points across all four cases are worth cataloging separately:

Honest Effort Estimates

The table below gives order-of-magnitude effort estimates from these four runs. These are not benchmarks. Time depends on the agent CLI, the model, the machine, the codebase complexity, and how many iteration passes the first generation requires. Use them as a starting frame for planning, not a delivery commitment.

Which Case to Lead With

Design teams: lead with Case 1. The artifact pair---deck plus prototype---is immediately legible as valuable, and the brand consistency between them is what earns the room.

Engineering teams: lead with Case 2. A diff of 42 components updated to brand spec in 20 minutes answers the "what if it gets something wrong?" objection directly---every change is reviewable, every mistake is revertable.

Design engineers evaluating Figma handoff: lead with Case 3, but frame it as a first-pass accelerator.

Case 4 has the most differentiated artifact type, but also the longest feedback loop and the most hardware-dependent timing. Use it after establishing trust with a faster case.