Static browser prototyping

Build standalone prototypes that validate flows and interactions before production implementation. Keep them zero-build and browser-native.

"Static" describes the delivery architecture: directly servable HTML, CSS, and JavaScript with no backend or required build pipeline. The prototype may still include realistic client-side interactions.

When a prototype belongs to an agile initiative, place it in planning/<initiative>/proto/ beside the intake, roadmap, business rules, and future epic artifacts. Use {app}/client-proto/ only when the project already follows that convention.

Complementary skill: htm-ui

/agile-proto is the process: where to write, scenes, z-proto, Figma capture, chaining. Components, tokens, importmap, API, and UI examples belong to the htm-ui skill (https://github.com/djalmajr/htm-ui). This package does not bundle that skill or its example catalog.

Before implementing scenes:

Look for htm-ui/SKILL.md in the harness skill roots (.agents/skills/, .claude/skills/, .opencode/skills/, and their ~/ equivalents).
If it exists, read it and follow it for component choice, theme, and API validation.
If it does not exist, say the complement is missing. Do not pretend this skill replaces htm-ui. Ask to install it: