About interactive-prototype
interactive-prototype is a skill for building clickable prototypes that behave like real apps. It specifies React-based structure and working interactions, while keeping backend, networking, and production persistence out of scope.
Key features
- 01React local-state structure
- 02Working navigation and controls
- 03Happy-path form validation
- 04Animated screen transitions
- 05Loading and empty states
- 06Persist selected state in localStorage
Use cases
- 01Demonstrating a multi-step app flow
- 02Testing screen transitions and form behavior
- 03Showing a realistic product interaction
Install
Copy the command and run it in a terminal.
npx skills add https:/After installing, type/interactive-prototypein Claude Code to confirm it loaded.
Details
From the project READMELoaded when the user asks for a working, clickable prototype — something that behaves like a real app rather than a static mockup.
Output location
Write all output files to ./opendesign/mockups/<task-slug>/. Derive the slug from the feature name (e.g. checkout-flow, settings-panel).
Role framing
The output is a prototype that feels like a real product, not a storyboard. State transitions work. Forms validate. Buttons route to something. If an interaction is visible in the UI, it actually happens.
It is still a prototype. Cut corners on backend, real persistence, and edge cases. Fake data is fine. Real logic for the happy path is required.
Stack and structure
- React with
useStateanduseEffectfor local state and effects. Keep state colocated. No global store unless the prototype genuinely needs one. - Split the prototype into small, readable components. Files over ~400 lines get broken up.
- Inline JSX via Babel is fine for a single-file prototype. For anything multi-screen, split into per-screen component files and compose them.
- Wrap the prototype in an appropriate device or window frame — phone bezel, browser chrome, desktop window — so it reads as a product, not a web page.
Required interaction surface
- Hover states on every interactive element.
- Click and tap handlers that route to the next state. No dead controls.
- Form validation on the happy path: buttons disabled until inputs are valid, visible error states when they are not.
- Animated transitions between states and screens. Short, purposeful, not decorative.
- Multi-step flows work end to end. The user can walk the intended happy path without hitting a dead end.
- Loading and empty states where the real product would have them. Do not skip straight to populated views.
Realism rules
- Realistic fake data. No lorem ipsum. No "John Doe." Names, copy, numbers, and timestamps fit the product's world.
- Mobile frames: hit targets minimum 44px.
- Persist critical state — current screen, active tab, demo playback position — in
localStorageso a refresh during iteration does not lose the user's place.
What to leave out
- Real authentication, real network calls, real persistence beyond
localStorage. - Production-grade accessibility audits. Basic semantics and focus management are enough.
- Every possible edge case. Pick the paths the user wants to demonstrate and make those watertight.