6.1 Web Prototypes

Generate a single-page web prototype and understand viewport handling

A web prototype in Open Design is a single self-contained HTML document: styles inlined, scripts bundled, no CDN calls, no build step. You write a prompt, the agent selects a prototype skill, and the daemon streams the artifact into the sandboxed preview. One file comes out the other side. That's the mental model to hold --- self-contained HTML from prompt to export.

Prototype is the first chip on the home composer for a reason: it is the default creation type, and since v0.20.0 it heads a stable, product-owned list of ten --- Prototype, Slide deck, Image, Document, HyperFrames, Website clone, Video, Audio, Live artifact, and WebGL --- that installed plugins can no longer mutate. Prototype expands its own sub-filter row (All, Landing/marketing, Dashboards, Mobile app, Wireframe, Apps), so the common web cases never leave the home surface. Underneath, the repo bundles 164 skill directories as of v0.21.1, including prototype-family skills such as web-prototype, saas-landing, pricing-page, docs-page, blog-post, and email-marketing. Each carries its own SKILL.md frontmatter that declares its mode, preview type, and required brand tokens.

The default viewport is responsive web at high fidelity. You can explicitly target a narrower breakpoint by naming it in your prompt: "mobile viewport", "1440px desktop", "tablet landscape". If you don't specify, the skill targets the widest responsive canvas.

A concrete web prototype walkthrough

Here's a generation prompt for a SaaS landing page:

Build a modern SaaS landing page with a dark hero section,
gradient headline, three feature cards below, and a
'Get Early Access' CTA button. Use the Vercel design system.

That prompt is enough. The agent resolves it to the saas-landing skill (or web-prototype if no better match exists), loads the Vercel DESIGN.md brand contract, and starts streaming HTML into the preview.

Build a modern SaaS landing page with a dark hero section,
gradient headline, three feature cards below, and a
'Get Early Access' CTA button. Use the Vercel design system.

When the prototype names a real thing

One quiet v0.21.1 change matters more than its release-note length suggests: real-referent imagery. When a prototype names a specific person, product, artwork, event, or place, Open Design now searches for and uses the actual referent instead of substituting a generic stand-in, and it keeps natural proportions while doing it. A hero requesting a "photo of the Sydney Opera House" receives the actual architectural landmark instead of an approximate generic structure. For pitch-and-review work this is the difference between a prototype that reads as real and one that reads as placeholder.

The flip side is review discipline: because the imagery is now literally correct, factual errors in imagery survive into stakeholder hands. If your prototype names a real product you have no rights to, name a fictional one instead --- the same mechanism that finds the real referent will happily find that, too.

6.2 Mobile App Prototypes

Generate a multi-screen mobile prototype with device framing

Mobile prototypes differ from web prototypes in two key areas: they render inside a device frame, and they support multi-screen flows. The agent builds every screen of a flow inside one self-contained HTML document, switching between screens using integrated navigation controls rather than multiple external files. The device frame itself --- an iPhone 15 Pro or Pixel 8 Pro SVG --- sits in skills/mobile-app/assets/frames/ and wraps the canvas without being regenerated on each run.

The mobile-app and mobile-onboarding skills (documented at the v0.9.0 snapshot) include pixel-accurate frames for iPhone 15 Pro (black and white) and Pixel 8 Pro (obsidian and porcelain), and those frames remain the defaults in the current build. The frame is a shared asset the skill reuses across all mobile artifacts; the agent doesn't redraw it on each generation, which keeps file size in check.

Generating a multi-screen mobile flow

Build a 3-screen mobile onboarding flow using the Notion
brand system: welcome screen, permissions request screen,
and first-task detail screen. Include a working bottom-sheet
navigation component. Frame in iPhone 15 Pro.

Build a 3-screen mobile onboarding flow using the Notion
brand system: welcome screen, permissions request screen,
and first-task detail screen. Include a working bottom-sheet
navigation component. Frame in iPhone 15 Pro.

skills/mobile-app/
├── SKILL.md
├── example.html
├── assets/
│   ├── frames/
│   │   ├── iphone-15-pro-black.svg
│   │   ├── iphone-15-pro-white.svg
│   │   ├── pixel-8-pro-obsidian.svg
│   │   └── pixel-8-pro-porcelain.svg
│   └── template.html
└── references/
    └── mobile-ui-patterns.md

The SKILL.md frontmatter declares this skill as mode prototype with preview type html:

---
name: mobile-app
description: Multi-screen mobile UI prototype with device framing
mode: prototype
preview: html
entry: index.html
example_prompt: "Build a 3-screen onboarding flow with welcome,
  permissions, and first-task screens. Frame in iPhone 15 Pro."
design_system:
  required:
    - color
    - typography
    - spacing
---

OD Next: purpose-built mobile structure (0.21.1)

The 0.21.1 release ("Community First: No Login Required") systematically overhauled mobile prototype architecture alongside visual presentation. Generated phone layouts now receive purpose-built component structures for standard mobile screens: calendars, statistics summaries, settings rows, top application bars, and bottom navigation render as distinct components instead of improvised generic elements. Images maintain natural aspect ratios without distortion, while confirmation dialogs function as genuine modal views. Consequently, foundational screens such as settings and navigation headers achieve shipping-grade fidelity on the initial pass, focusing iteration cycles on custom product screens.

6.3 Adding Interactivity and State

How interactivity lives inside self-contained HTML

Generated prototypes aren't static mockups. Buttons navigate, tabs switch, modals open, and forms validate --- all inside the same self-contained HTML file, client-side, with no backend. The streaming artifact parser renders interactive HTML as the model generates it, and the sandbox preserves that interactivity in the preview. This distinction matters: what you see in the sandbox is what you get when you export.

Interactivity in generated artifacts uses vanilla JavaScript or a lightweight framework inlined into the HTML. Buttons have event listeners, tabs manage aria-selected state, modals show and hide on click. The key point is that this is client-side state --- it lives in memory and resets on page reload. Open Design doesn't provide a persistence layer for prototype state.

Static mockup vs interactive prototype

The difference shows up clearly in how you prompt. A static mockup prompt doesn't ask for behaviors; an interactive prototype prompt names them explicitly.

Build a settings page with three tabs:
Profile, Notifications, and Security.

Build a settings page with three tabs:
Profile, Notifications, and Security.
Each tab click should show its panel and
hide the others. Default to the Profile tab.

The same principle applies to modals, bottom-sheets, accordions, and forms. Name the interaction: "clicking the card opens a detail modal", "the accordion expands on click", "the form validates email format on blur". Vague prompts produce vague prototypes.

State persistence within a run

Within a single preview session, client-side state persists as long as the iframe isn't reloaded. Navigating between screens in a multi-screen flow preserves tab state and form input values. Clicking Export and opening the resulting HTML file starts fresh --- no state is serialized into the export.

6.4 Live Dashboards

Generate a dashboard with tweakable parameters and real data sources

Dashboard prototypes are the highest-fidelity artifact in the prototype family: KPI cards, charts, data tables, sidebar navigation, and adjustable filters, all in one self-contained HTML file. You supply the data --- pasted as CSV rows, as a JSON array, or as a local endpoint URL --- and the skill renders it. No external BI platform required.

The dashboard skill supports CSV paste, JSON array, and local endpoint data sources. Dashboards are also a first-class home-surface path now: Prototype's sub-filter row includes Dashboards, so a dashboard start doesn't depend on the agent inferring your intent from prose alone. The "tweakable parameters panel" --- a sidebar control for adjusting chart ranges, metric toggles, and filters without re-prompting --- is referenced in earlier documentation but its implementation status should still be verified in your build. The fallback is re-prompting: "Change the date range to Q1 2026" triggers a targeted regeneration that preserves the rest of the dashboard layout.

Generating a live sales dashboard

Build a live sales dashboard with adjustable date-range
filter and four KPI cards (Revenue, Conversion Rate,
Customer Acquisition Cost, Churn). Include a revenue-over-time
line chart and a top-products table. Use the Stripe design system.

Build a live sales dashboard with adjustable date-range
filter and four KPI cards (Revenue, Conversion Rate,
Customer Acquisition Cost, Churn). Include a revenue-over-time
line chart and a top-products table. Use the Stripe design system.

Replace the revenue chart data with this CSV:
month,revenue
Jan,45000
Feb,52000
Mar,68000
Apr,71000
May,89000

Dashboard data as self-contained HTML

The generated dashboard inlines its data directly in the HTML, typically as a JavaScript constant. As a preview and communication artifact, it operates independently of live database connections. Updating charts to reflect new numbers requires re-prompting the agent with a fresh data payload rather than polling an external endpoint.

// Data inlined in the generated dashboard artifact
const dashboardData = [
  { month: 'Jan', revenue: 45000, customers: 320 },
  { month: 'Feb', revenue: 52000, customers: 380 },
  { month: 'Mar', revenue: 68000, customers: 450 }
];
// Chart rendered via D3 or Chart.js inlined in the same file
// No external API calls; fully self-contained

6.5 From Mockup to Interactive Prototype

Iterating a static layout into a clickable prototype

The initial generation run provides an operational baseline layout. Refinement and quality emerge during the iterate phase of the generate, preview, iterate, export cycle. This section walks through advancing a static wireframe into a responsive interactive prototype through targeted follow-up prompts, establishing clear criteria for when to conclude iteration and export.

The iterate sequence

Targeted iteration prompts are more reliable than broad ones. "Fix the pricing section" is vague --- the agent might change layout, typography, and copy all at once. "Set the Starter plan price to $29/month and make the Enterprise tier say 'Contact us'" changes exactly two values.

Iteration patterns that work

These patterns produce reliable iterations:

# Structural change: name the section and the change
"In the navigation, change the CTA button label from
'Get Started' to 'Request Demo' and change its background
to the brand primary color."

# Layout correction: name what is wrong
"The three feature cards stack vertically on a 1440px
viewport. Arrange them in a 3-column grid."

# Interactivity addition: describe the behavior fully
"Add a modal to the 'View Details' button on each product card.
The modal should show the full product description and a
'Buy Now' CTA. Close on Escape or clicking the overlay."

Locking scope with Plan mode

Before the iterate sequence starts, one mode choice can save you three of those iterations. Plan mode --- "Creates an editable plan document first, then hands off to Design after you review it" --- converts your multi-screen brief into a real, editable plan document: screens, content, interactions, all correctable in text before anything is generated. For a five-screen onboarding flow, fixing "screen 3 should be permissions, not profile" in the plan costs ten seconds; discovering it in the generated prototype costs a regeneration. Review the plan, edit it, approve it, and Design builds against what you actually wrote.

Editing without a prompt: Manual Edit

Not every fix deserves a prompt. Since 0.17.0, Manual Edit gives the workspace canvas direct manipulation: click an element and it gets selection handles; drag to move, pull to resize, edit text in place. An inspector panel opens beside the canvas with the full parameter set --- Text, Text color (expressed as oklch(...)), Background, Opacity, Font, Font size, Weight, Line height, Letter spacing, Radius, Border, Width, Height, Padding and Margin per side, and the flex controls Direction, Distribution, Gap, and Align --- with Undo, Redo, Delete, Cancel, and Save along the bottom. The preview toolbar's Comment / Mark / Edit checkboxes switch the canvas between annotating and editing, and canvas-preserving undo/redo means a bad drag never flashes the whole preview through a reload.

For review rounds, the third checkbox earns its place: Comment mode turns the cursor into an annotation tool, so a stakeholder note pins to the exact element it criticizes instead of living as prose in a chat thread.

When self-contained HTML reaches its limits

Self-contained HTML provides immediate preview convenience rather than a long-term production architecture. Once a prototype expands to include multi-route state management and complex application logic, transitioning to a dedicated build pipeline yields superior maintainability.

For those cases, use the code-refresh plugin (covered in section 9.4) to refactor a generated prototype into a proper Next.js or React component tree. The prototype gets you the design approved; the plugin gets you the code production-ready.

Prototype troubleshooting

The four-beat loop in prototype work

The prototype workflow is the generate, preview, iterate, export loop in its most visible form. Generate produces the first layout. Preview surfaces what's wrong. Iterate targets each problem precisely. Export verifies the shippable file. Don't skip the export verification step --- the preview and the exported file can diverge on external asset handling, as noted in the troubleshooting table above.