---
name: HTML Prototype (HTML)
description: Single-file interactive HTML prototype — React/Tailwind via CDN, runs by opening one file in the browser. For product demos, interaction studies, and shareable explorations that don't need a build step.
triggers:
  - html prototype
  - single file prototype
  - interactive prototype
  - react cdn prototype
  - clickable demo
cd:
  mode: prototype
  platform: html-canvas
  scenario: interactive-demo
  preview: html_file
  fidelity: high
  animations: true
  featured: true
  design_system:
    requires: true
    sections: [palette, type, spacing, motion]
  craft:
    requires:
      - typography
      - color
      - anti-ai-slop
      - state-coverage
      - accessibility-baseline
      - react-html-setup
      - animation-best-practices
      - animation-pitfalls
  inputs:
    - brief (what the prototype demonstrates)
    - target screens / surfaces
    - which interactions matter
  parameters:
    - viewport (default 1440)
    - fidelity (default high)
  outputs:
    primary: html_file
    capabilities_required:
      - write_file
      - read_file
  default_for:
    - html-prototype
  example_prompt: "Single-file HTML prototype of a chat onboarding flow with three interactive steps"
---

## Single-file rule

Output **one** `.html` file that opens directly in a modern browser. No build step. No `npm install`. No external assets the user has to fetch separately. React + ReactDOM + Babel-standalone + Tailwind via CDN. See `react-html-setup` for the exact scaffold.

## What HTML is for

HTML prototypes earn their place when:

- the interaction is the point (you can't show it in a static frame),
- the prototype must be shared as a link or zipped file,
- the user wants to play with it before committing to a Figma flow,
- or the brief is exploratory and the cost of Figma component plumbing isn't paid back yet.

If the brief is "design these screens for handoff", **decline this skill** and route to `mobile-screens-figma` or another Figma skill. Figma is the source of truth for spec; HTML is for *feel*.

## Layout principles

- One viewport at a time. Don't try to be responsive across mobile + desktop in a prototype unless the brief explicitly demands it; pick the canvas the interaction lives on.
- Real content always. No `Lorem ipsum`, no `Feature One`. If copy is missing, ask the user or mark `[REPLACE: …]` explicitly.
- Visible interactivity. The first thing the user sees should hint at where to click. Use a subtle cue (cursor, hover, micro-pulse) — never a flashing CTA.
- Quiet chrome by default. The prototype's job is to demonstrate the work, not the wrapper.

## Animation discipline

Read `animation-best-practices.md` and `animation-pitfalls.md` craft files before composing motion. Defaults:

- 150–250ms for UI transitions, 350–500ms for narrative beats. Never linear easing.
- Respect `prefers-reduced-motion`. Wrap motion in a media query and provide a non-motion alternative.
- One signature animation per prototype, not three. Pick the moment that earns the cinematics.

## Quality bar

- Self-check against `craft_lint` before returning the file.
- Test that the file works when opened directly via `file://` (no fetch from missing endpoints).
- All state visible: empty, loading, error, success — covered or explicitly omitted with reason.
