skillZs
★ LIVE SKILL TAGS ★
>>> LIVE SKILLS INDEX <<<
* OPEN SOURCE *
NO LOGIN, NO TRACKING
※ REAL INSTALL DATA ※
← back to all skills
manalkaff/opendesign97 installs

interactive-prototype

Use when the user asks for a working, clickable prototype — something that behaves like a real app rather than a static mockup. React + useState/useEffect, realistic fake data, working state transitions.

How do I install this agent skill?

npx skills add https://github.com/manalkaff/opendesign --skill interactive-prototype
view source ↗

Is this agent skill safe to install?

  • Gen Agent Trust Hubpass

    The skill provides instructions for generating interactive React prototypes, specifying implementation details like component structure, state management via localStorage, and a designated output directory. No security risks or malicious patterns were identified.

  • Socketpass

    No alerts

  • Snykpass

    Risk: LOW · No issues

What does this agent skill do?

Loaded 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 useState and useEffect for 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 localStorage so 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.

Add the canonical catalog link to the repository README so users can inspect current installs and available audits. The publishing guide covers the complete discovery path.

<a href="https://skillzs.dev/skills/manalkaff/opendesign/interactive-prototype">View interactive-prototype on skillZs</a>