---
name: feature-interactive-demo
description: Build a single-file interactive HTML walkthrough that explains a feature in ~30 seconds. Generates a 3-column prototype (input → artifact → step-by-step wizard) so engineers, PMs, and QA can grasp how an implementation works without reading a doc. Use when the user wants an RFC demo, design walkthrough, code-review companion, or asks to "make a demo / interactive prototype / step-by-step explainer / RFC artifact" for a feature, code change, or PR. Source can be conversation context, a code diff, or a free-text feature spec.
---

# Feature Interactive Demo

A single self-contained `prototype.html` that walks a reviewer through a feature step-by-step. Vanilla HTML/CSS/JS. No build, no network.

## Quick start

1. Identify the feature's **input → artifact → walkthrough** triad
2. Carve the feature into **3 architectural steps** (sometimes 4) — each one corresponds to a boundary
3. For each step, derive: title (1–3 words), description (2–3 sentences with `<code>` inline), **decision callout** (the "why this way, not the obvious other way" takeaway)
4. Pick **2–4 scenarios** (turns) the reviewer steps through; each makes a visible artifact change
5. Copy [prototype.template.html](prototype.template.html). Customize the `SCENARIO` + `STEPS` arrays and the step content render functions for the feature
6. Save as `prototype.html` in a new directory (e.g. `<feature-name>-rfc-prototype/prototype.html`)

See [REFERENCE.md](REFERENCE.md) for the layout shell, scenario shape, animation primitives, widget patterns, and anti-patterns.

## Workflow

### From conversation context (most common)

When a feature was just designed in chat, distill:
- What's the user-driven **input**? (chat composer, form, action button)
- What's the visible **artifact**? (UI mock, document, list, record)
- What's the **under-the-hood machinery**? (LLM calls, DB rows, locks, API requests, state mutations)

Map under-the-hood machinery to **3 steps** — input received → server-side work → response/state applied. Each step's content shows the relevant subsystem.

### From code diff / PR

Read the diff. Identify which architectural layers were touched. Construct 2–4 scenarios that exercise the change. Each step shows what changed in that layer (e.g., "request lands", "service mutates rows", "response shipped + UI applies").

### From free-text spec

If anything is ambiguous, ask 1–2 clarifying questions about (a) the artifact the user sees change and (b) the 2–4 concrete example scenarios. Then proceed.

## Output

Single static HTML file. Opens directly in a browser. Suggest a path like `<repo>/../feature-name-rfc-prototype/prototype.html` — a sibling directory rather than inside the repo, since the demo is throwaway and should not be committed unless the user asks.

## Principles (load-bearing)

- **Decision callouts are the payoff.** Without them, it's just animation. Don't skip them — they're what the reviewer takes away.
- **Per-step content**, not accumulating logs. Only show what's relevant to the current step. The reviewer should never parse a wall of mixed events.
- **User-driven advancement.** No auto-play. `Send` to start a turn, `→`/`←` to step, `↻ Reset` to replay.
- **One artifact.** The middle column is the user-facing thing. Side panels are under-the-hood state. Don't mix.
- **Drop what you can't visualize.** If a concept doesn't fit a step's content area, leave it in the description text only — don't add an extra panel that ends up extraneous.

## Reject

- ❌ Auto-play demos that play once on load — feels passive, no one absorbs it
- ❌ Single "log pane" with everything streaming in — too dense
- ❌ Tiny grey type for density — bigger text, higher contrast, even if it means scrolling
- ❌ Composite "magic" widgets in the demo that hide what the feature actually does — same principle as in the real feature; show the primitives