Interactive prototype

A clickable, hi-fi prototype of a product or flow — not a wireframe, not a static mock. The user can navigate, toggle states, and feel the interaction. Use this whenever the design has flows, multi-screen states, or many-option situations.

When to use this skill

• The user asks for "an app", "a flow", "a multi-step thing", "let me see it working", "let me click around".
• The design has stateful behavior (toggles, modals, multi-screen navigation, form validation flows).
• There are 3+ screens that connect.
• The user needs to demo interactions to a stakeholder.

When this skill does NOT apply

• Single static surface (a banner, a poster, a thumbnail, a single-screen marketing page) → that's purely visual; use the existing DesignCanvas with one or more <DCArtboard> instead.
• Comparing variations of one element side-by-side → also DesignCanvas, multiple <DCArtboard> children in a single <DCSection>.
• Timeline-based motion (the page advances on a clock, elements enter/exit on a schedule) → that's animated-video, not this skill.

Build with React + Babel (inline JSX)

The project's iframe loads React + ReactDOM + Babel-Standalone from CDN at the top of index.html. Use these exact script tags with pinned versions and integrity hashes — newer minor versions sometimes break the inline-JSX flow without notice:

<script src="https://unpkg.com/react@18.3.1/umd/react.development.js" integrity="sha384-hD6/rw4ppMLGNu3tX5cjIb+uRZ7UkRJ6BPkLpg4hAu/6onKUg4lLsHAs9EBPT82L" crossorigin="anonymous"></script>
<script src="https://unpkg.com/react-dom@18.3.1/umd/react-dom.development.js" integrity="sha384-u6aeetuaXnQ38mYT8rp6sbXaQe3NL9t+IBXmnYxwkUI2Hw4bsp2Wvmx4yRQF1uAm" crossorigin="anonymous"></script>
<script src="https://unpkg.com/@babel/standalone@7.29.0/babel.min.js" integrity="sha384-m08KidiNqLdpJqLq95G/LEi8Qvjl/xUYll3QILypMoQ65QorJ9Lvtp2RXYGBFj1y" crossorigin="anonymous"></script>

Don't add type="module" on script imports. Babel-standalone doesn't transpile module imports cleanly in this CDN setup; the iframe will silently fail to mount.

Style-object naming. Never declare const styles = { ... }. Multiple components in the same file (or multiple <script type="text/babel"> blocks sharing the iframe window) will collide on the styles global. Always namespace: const terminalStyles = { ... }, const composerStyles = { ... }.

Cross-file scope. Each <script type="text/babel"> block is its own scope. Components defined in one block aren't visible to the next without going through window. At the bottom of every component-defining block, write:

Object.assign(window, { Terminal, Line, Spacer /* every component declared here */ });

The next block can then read them off window directly: const { Terminal, Line, Spacer } = window;.

Starter components to drop in

The host's MCP starters server exposes these via mcp__starters__copy_starter. Each is a single .jsx file that drops into the project; reference it from the iframe's <head> with <script type="text/babel" src="<name>.jsx">.

The DesignCanvas wrapper is already present in fresh projects (see skills/frontend-design/SKILL.md and the project's index.html). Add additional <DCArtboard> children to the existing <DCSection> to lay multiple flows side-by-side.

Build process

1. Confirm the brief. Use mcp__ask-user__ask_user if anything's vague: how many screens, which device frame, what states matter.
2. Look for prior art in the project before generating from scratch — existing components, uploaded screenshots, anything in uploads/. Designs are stronger when they riff on something concrete.
3. Show the user something fast. Drop in a placeholder version of the first screen with assumptions visible (annotations, a // TODO comment block at the top), let them react before going deep on every screen.
4. Build the React components per screen. Keep each screen in its own component file (HomeScreen.jsx, ProductDetail.jsx, etc.), shared primitives in a Primitives.jsx. Wire navigation via state.
5. Add tweaks. A couple of make-tweakable knobs by default (color, copy, layout variant) so the user can riff without re-prompting. See skills/make-tweakable/SKILL.md.
6. Iterate. The user is using the running prototype — every change should be visible in <5 seconds.

Defaults

• Center the prototype in the viewport (mobile frame) or fill the viewport with reasonable margins (desktop / browser frame).
• No "title" screen — the prototype IS the artifact; there's no need for a launcher slide.
• Simple animation: CSS transitions or React state. Reach for animations.jsx only when motion is the design (timeline-based, choreographed entries, hero animations) — see animated-video.
• Real-feeling content: avoid lorem ipsum. If real content isn't available, use plausible-but-fake (names from popular open datasets, real product types, real-shaped numbers).

Anti-patterns

• Wireframe-grade detail. If the prototype is meant to demonstrate interaction, every screen has to be believable. A wireframe with grey blocks where photos go, "lorem ipsum" headlines, and unbranded buttons fails as a prototype the user can react to.
• Modal-everywhere navigation. Pressing a "next" button shouldn't always pop a modal that hides the previous screen. Use real screen transitions (slide left/right for horizontal flows, slide up for modals/sheets, fade for overlays).
• State that resets on navigation. If the user clicks "Back", their form data should still be there. Use a single shared state object at the root component, not per-screen useState.
• window.alert for confirmations or feedback. It feels like a developer artifact, not a designed product. Build the confirm/feedback UI inline.
• Inline event handlers wired to nothing — every button should do something visible, even if it's just toggling a piece of mock state. A non-functional button breaks the illusion the prototype is trying to create.