# Design Prototype

> Interactive design prototype workflow for clickable flows, mockups, demos, app screens, stateful UI, form validation, loading/error/success feedback, keyboard behavior, and design handoff prototypes.

- Skill: `maybemonad/design-prototype` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add maybemonad/design-prototype`
- Raw SKILL.md: https://api.skillmd.com/api/skills/maybemonad/design-prototype/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Productivity
- Author: MaybeMonad (https://skillmd.com/u/maybemonad)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/maybemonad/design-prototype

---


# Design Prototype

Use this skill when the artifact needs to behave, not just look right. A
prototype tests flow, state, feedback, and interaction quality before or during
implementation.

## Workflow

1. Map the flow:
   - Entry point, screens, states, transitions, success path, failure path,
     backtracking, empty state, and exit state.
   - Completion criterion: every primary action has a destination or visible
     result.
2. Set fidelity and frame:
   - Mid-fi for flow validation, hi-fi for visual validation, production slice
     for codebase implementation.
   - Pick the target frame: desktop app, web page, dashboard, mobile screen,
     tablet, deck interaction, or embedded widget.
   - Completion criterion: fidelity matches the decision being tested.
3. Ground the prototype:
   - Use `design-source-map` outputs, existing components, real tokens, and
     real-looking sample data.
   - If no system exists, use `design-direction` first.
   - Completion criterion: the prototype does not rely on generic placeholder
     visuals or lorem ipsum when real content is needed.
4. Build statefully:
   - Navigation, form values, validation errors, dirty/pristine states,
     selections, filters, modal/popover open state, disabled states, loading,
     success, and failure feedback.
   - Fake network behavior with controlled local state when backend work is out
     of scope.
   - Completion criterion: important interactions are wired, not implied by
     static screens.
5. Make interactions accessible:
   - Semantic controls, visible focus, keyboard navigation, Escape behavior for
     dismissible layers, labels, hit targets, reduced motion, and status
     announcements where relevant.
   - Completion criterion: keyboard use reaches the same flow as pointer use.
6. Verify in runtime:
   - Run the local preview or app, exercise the flow, inspect console errors,
     check desktop and mobile sizes when relevant, and capture screenshots if
     visual fit matters.
   - Completion criterion: every claimed behavior was tried or is explicitly
     marked unverified.

## Output Shape

- Prototype scope: real behavior, fake behavior, and out-of-scope behavior.
- Flow map: screens, states, and transitions.
- How to view: file path, route, or local URL.
- Verification: commands, browser paths, and remaining caveats.
- Decisions for user: visual or interaction calls needing signoff.

## Rules

- A prototype with dead primary controls is not complete.
- Do not create separate v1/v2/v3 files for small variants; use one artifact
  with tabs, toggles, a canvas, or a tweak panel when comparison matters.
- Do not wire real payments, emails, production mutations, auth changes, or
  migrations unless explicitly requested.
- If the prototype sits inside a real app, follow existing component and route
  patterns instead of creating an isolated aesthetic island.

## Credit

Inspired by
[Trystan-SA/claude-design-system-prompt](https://github.com/Trystan-SA/claude-design-system-prompt)
(MIT), adapted around runtime-verifiable Codex prototypes.