Static browser prototyping

Build standalone prototypes that validate flows and interactions before production implementation. Keep them zero-build and browser-native. Use HTM UI as the component source of truth; never bundle or maintain a copied component catalog inside each prototype.

"Static" describes the delivery architecture: directly servable HTML, CSS, and JavaScript with no backend or required build pipeline. The browser prototype may still include realistic client-side interactions. Never create or edit .pen artifacts in this skill; route those requests to agile-pen.

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.

Project root

Resolve all paths from the repository where the prototype lives, not from the skills repository. If the active directory is a sibling repository, prepend the explicit project root. Ask only when the target is genuinely ambiguous.

Prompting

Use the harness's structured-question tool for choices that materially branch the result: