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.

As of June 2026, Open Design ships around 15 prototype-family skills including web-prototype, saas-landing, pricing-page, docs-page, blog-post, and email-marketing (out of 100+ skills total as of June 2026). 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.

6.2 Mobile App Prototypes

Generate a multi-screen mobile prototype with device framing

Mobile prototypes differ from web prototypes in two ways: 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 via navigation controls, not separate 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.

As of June 2026, the mobile-app and mobile-onboarding skills include pixel-accurate frames for iPhone 15 Pro (black and white) and Pixel 8 Pro (obsidian and porcelain). 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
---

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.

As of June 2026, the dashboard skill supports CSV paste, JSON array, and local endpoint data sources. The "tweakable parameters panel" --- a sidebar control for adjusting chart ranges, metric toggles, and filters without re-prompting --- is referenced in v0.9.0 documentation but its implementation status in the current release should be verified. 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. This is a preview and communication artifact --- it's not wired to a live database. If you need the chart to reflect updated numbers, you re-prompt with new data, not re-query an 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 first generation rarely produces a finished prototype. It produces a starting layout. Quality comes from the iterate step of the generate, preview, iterate, export loop --- not the generate step. This section shows how to move a static layout to a fully interactive prototype in a sequence of targeted follow-up prompts, and how to know when to stop iterating 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."

When self-contained HTML reaches its limits

Self-contained HTML is a preview convenience, not a production pattern. At some point a prototype becomes large enough that a real build pipeline --- component library, routing, state management --- produces better results than a single inlined file. That point is usually when you're building a multi-page application with shared state between routes, or when a developer needs to ship the artifact as a real product.

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.