Prototype
Produce a working interactive prototype — a real app the user can click through, not a static mockup.
Shape
Shapes: landing page / dashboard / form flow / tool / mini-app / multi-screen demo. Default: landing page with one CTA, single screen, in-memory state, mock inline data, desktop-first.
Structure
File layout
- Single file default. One self-contained
.html with inline <style> and <script>.
- Module split only when scope demands it: one top-level
.html + sibling .js / .css referenced by relative path. No bundler, no build step.
- Starter components from system.md § Starter Components when fit — device frames (
ios_frame.jsx / android_frame.jsx) for mobile mockups, browser_window.jsx / macos_window.jsx for desktop chrome, design_canvas.jsx for side-by-side option explorations, animations.jsx for motion work.
Screens & state (define up front)
Every prototype needs these two tables before you write code:
| Screen |
Purpose |
Primary CTA |
Reachable from |
No orphan screens. Every screen reachable from at least one other screen.
| State field |
Type |
Default |
Mutated by |
Keep state in one place — a top-level module object or a single observed store. Don't scatter let bindings across files.
Non-editable chrome
Chrome that shouldn't be selectable by adits' Edit mode (nav bars, step indicators, slide counters, overlay controls) must live in shadow DOM (preferred, used by <deck-stage>) or carry data-dm-overlay on its root. The Edit-lane selection walker skips both. Real content stays in the light DOM so the user can click-to-edit it.
Interaction rules
- Interactions are real. Buttons do something. Forms validate and submit. Toggles flip visible state. No "this would…" placeholders.
- Every surface reachable. Every screen has a path in. No dead ends. No unreachable states.
- State changes are visible. UI updates when state updates. No silent mutations.
- Feedback for every action. Click → active state / optimistic update / loading / success.
- Error states real. Triggered by a real predicate (empty required field, invalid email shape, simulated API failure). Don't pretend-fail.
- Loading states bounded. 300–1200ms with a real spinner or skeleton. Not instant (fake); not 5s (broken).
- Empty and success states designed. Empty list has a path forward. Successful submit shows confirmation, not a silent reset.
- Keyboard reachable. Sensible tab order.
Enter submits primary forms. Escape closes modals.
- No external API calls unless the user asked. Inline mocks or local JSON.
- Label screens with
data-screen-label="NN Title" (1-indexed) per system.md § Labelling slides and screens.
Requirements pass
Before writing code, resolve each:
- One-sentence purpose. Who uses this for what.
- Happy path. User lands on X → clicks Y → sees Z → ends at W.
- State model. What mutable state exists (form values, selection, auth flag, cart, …).
- Data shape. What objects the app reads/writes and their minimal fields.
- Edge paths. Empty state, loading state, error state, success state — at minimum.
Missing anything → ask.
Distill raw input
If input is "I want an app for X":
- Task → flow. Extract each user task and write it as an ordered flow.
- Flow → screens. Group steps into screens; each has a purpose + primary CTA.
- Screens → components. List the components each screen needs (forms, cards, lists, modals).
- Gap-check — missing screens, missing states (empty, loading, error, success), missing components, missing data shape.
- Ask once with a gap table.
Form-specific verification
Actually click through. Don't just read the code.
Beyond done + fork_verifier_agent:
- Happy path works end-to-end — every click and submit advances correctly.
- Every screen reachable via the app itself (not by URL edit).
- Every CTA responds — no silent buttons.
- State visible — change state via UI; confirm UI reflects the change.
- Edge states present — trigger empty, loading, error, success — each renders something designed, not a blank.
- Keyboard — tab reaches primary CTA;
Escape closes modal; Enter submits.
- Target match — desktop prototypes render at 1440×900; mobile at 390×844.
Feedback protocol
| User says |
Ask |
| "feels slow" |
Which transition — [X → Y], submit, page load? Timing is N ms. Tighten to M, or add optimistic update? |
| "confusing" |
On which screen? Primary CTA is "[label]"; next step is [action]. Rename CTA [A] or add helper line [B]? |
| "dead end" |
Which screen? Outgoing paths are [list]. Add link to [Y], or make [element] clickable? |
| "too plain" |
Motion (currently none), visuals (accent / imagery), or layout density? Pick one. |
| "doesn't look like a real app" |
Often missing chrome — header, sticky nav, loading skeleton on async? |
| "broken" |
Which action? Open devtools, share the console error. Target the specific failing path. |
Never say "I'll make it feel faster" without naming the transition and the new timing.
When not to use
- Static printable document → the matching document skill.
- Slide deck →
slide-deck.
- Real backend app needing auth, persistent storage, server logic → full-stack path, not this.
- Design system itself (components, tokens, demos) → edit the design system's assets, not a prototype.
1---2name: prototype3description: Prototype4---5# Prototype67Produce a working interactive prototype — a real app the user can click through, not a static mockup.89## Shape1011Shapes: landing page / dashboard / form flow / tool / mini-app / multi-screen demo. Default: landing page with one CTA, single screen, in-memory state, mock inline data, desktop-first.1213## Structure1415### File layout1617- **Single file default.** One self-contained `.html` with inline `<style>` and `<script>`.18- **Module split** only when scope demands it: one top-level `.html` + sibling `.js` / `.css` referenced by relative path. No bundler, no build step.19- **Starter components** from system.md § Starter Components when fit — device frames (`ios_frame.jsx` / `android_frame.jsx`) for mobile mockups, `browser_window.jsx` / `macos_window.jsx` for desktop chrome, `design_canvas.jsx` for side-by-side option explorations, `animations.jsx` for motion work.2021### Screens & state (define up front)2223Every prototype needs these two tables before you write code:2425| Screen | Purpose | Primary CTA | Reachable from |26|---|---|---|---|2728No orphan screens. Every screen reachable from at least one other screen.2930| State field | Type | Default | Mutated by |31|---|---|---|---|3233Keep state in **one place** — a top-level module object or a single observed store. Don't scatter `let` bindings across files.3435### Non-editable chrome3637Chrome that shouldn't be selectable by adits' Edit mode (nav bars, step indicators, slide counters, overlay controls) must live in **shadow DOM** (preferred, used by `<deck-stage>`) or carry `data-dm-overlay` on its root. The Edit-lane selection walker skips both. Real content stays in the light DOM so the user can click-to-edit it.3839## Interaction rules4041- **Interactions are real.** Buttons do something. Forms validate and submit. Toggles flip visible state. No "this would…" placeholders.42- **Every surface reachable.** Every screen has a path in. No dead ends. No unreachable states.43- **State changes are visible.** UI updates when state updates. No silent mutations.44- **Feedback for every action.** Click → active state / optimistic update / loading / success.45- **Error states real.** Triggered by a real predicate (empty required field, invalid email shape, simulated API failure). Don't pretend-fail.46- **Loading states bounded.** 300–1200ms with a real spinner or skeleton. Not instant (fake); not 5s (broken).47- **Empty and success states designed.** Empty list has a path forward. Successful submit shows confirmation, not a silent reset.48- **Keyboard reachable.** Sensible tab order. `Enter` submits primary forms. `Escape` closes modals.49- **No external API calls** unless the user asked. Inline mocks or local JSON.50- **Label screens with `data-screen-label="NN Title"`** (1-indexed) per system.md § Labelling slides and screens.5152## Requirements pass5354Before writing code, resolve each:5556- **One-sentence purpose.** Who uses this for what.57- **Happy path.** User lands on X → clicks Y → sees Z → ends at W.58- **State model.** What mutable state exists (form values, selection, auth flag, cart, …).59- **Data shape.** What objects the app reads/writes and their minimal fields.60- **Edge paths.** Empty state, loading state, error state, success state — at minimum.6162Missing anything → ask.6364## Distill raw input6566If input is "I want an app for X":67681. **Task → flow.** Extract each user task and write it as an ordered flow.692. **Flow → screens.** Group steps into screens; each has a purpose + primary CTA.703. **Screens → components.** List the components each screen needs (forms, cards, lists, modals).714. Gap-check — missing screens, missing states (empty, loading, error, success), missing components, missing data shape.725. Ask once with a gap table.7374## Form-specific verification7576Actually click through. Don't just read the code.7778Beyond `done` + `fork_verifier_agent`:7980- **Happy path works end-to-end** — every click and submit advances correctly.81- **Every screen reachable** via the app itself (not by URL edit).82- **Every CTA responds** — no silent buttons.83- **State visible** — change state via UI; confirm UI reflects the change.84- **Edge states present** — trigger empty, loading, error, success — each renders something designed, not a blank.85- **Keyboard** — tab reaches primary CTA; `Escape` closes modal; `Enter` submits.86- **Target match** — desktop prototypes render at 1440×900; mobile at 390×844.8788## Feedback protocol8990| User says | Ask |91|---|---|92| "feels slow" | Which transition — [X → Y], submit, page load? Timing is N ms. Tighten to M, or add optimistic update? |93| "confusing" | On which screen? Primary CTA is "[label]"; next step is [action]. Rename CTA [A] or add helper line [B]? |94| "dead end" | Which screen? Outgoing paths are [list]. Add link to [Y], or make [element] clickable? |95| "too plain" | Motion (currently none), visuals (accent / imagery), or layout density? Pick one. |96| "doesn't look like a real app" | Often missing chrome — header, sticky nav, loading skeleton on async? |97| "broken" | Which action? Open devtools, share the console error. Target the specific failing path. |9899Never say *"I'll make it feel faster"* without naming the transition and the new timing.100101## When not to use102103- Static printable document → the matching document skill.104- Slide deck → `slide-deck`.105- Real backend app needing auth, persistent storage, server logic → full-stack path, not this.106- Design system itself (components, tokens, demos) → edit the design system's assets, not a prototype.
rebyteai