Interactive prototype
Local-first, open-source alternative to Anthropic's Claude Design. MIT-licensed, BYO agent CLI — Claude Code, Kimi, Codex, or any SDK-compatible model. Composable skills · three edit paths · designs as plain HTML/JSX/CSS folders · run locally, no cloud round-trip. Generate banners, thumbnails, websites, animations, design systems.
npx -y skills add aiatelie/ai-atelie --skill interactive-prototypeAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 7 stars7 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Build 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. Reach for this whenever the design has flows, multi-screen states, or many-option situations.
SKILL.md
6.9 KB, as published. Nobody here has run it
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/[email protected]/umd/react.development.js" integrity="sha384-hD6/rw4ppMLGNu3tX5cjIb+uRZ7UkRJ6BPkLpg4hAu/6onKUg4lLsHAs9EBPT82L" crossorigin="anonymous"></script>
<script src="https://unpkg.com/[email protected]/umd/react-dom.development.js" integrity="sha384-u6aeetuaXnQ38mYT8rp6sbXaQe3NL9t+IBXmnYxwkUI2Hw4bsp2Wvmx4yRQF1uAm" crossorigin="anonymous"></script>
<script src="https://unpkg.com/@babel/[email protected]/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">.
| Starter | Use it for |
|---|---|
ios_frame.jsx | Mobile prototype with iOS status bar, home indicator, keyboard. |
android_frame.jsx | Mobile prototype with Android status bar, navigation bar. |
macos_window.jsx | Desktop window chrome — title bar, traffic-light buttons. |
browser_window.jsx | Web app inside a browser frame — URL bar, tabs. |
design_canvas.jsx (DesignCanvas) | Laying out 2+ static screens side-by-side for comparison. |
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
- Confirm the brief. Use
mcp__ask-user__ask_userif anything's vague: how many screens, which device frame, what states matter. - 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. - Show the user something fast. Drop in a placeholder version of the first screen with assumptions visible (annotations, a
// TODOcomment block at the top), let them react before going deep on every screen. - Build the React components per screen. Keep each screen in its own component file (
HomeScreen.jsx,ProductDetail.jsx, etc.), shared primitives in aPrimitives.jsx. Wire navigation via state. - Add tweaks. A couple of
make-tweakableknobs by default (color, copy, layout variant) so the user can riff without re-prompting. See skills/make-tweakable/SKILL.md. - 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.jsxonly 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.alertfor 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.