Interactive UI Prototyping

Build standalone interactive prototypes to validate UI flows before implementation. Zero build tools — everything runs from CDN. Visual and API should mirror the target project's component system. Use an existing local prototype as reference only when the project already has one.

When the prototype is part of an agile planning initiative, keep it with the planning artifacts: planning/<initiative>/proto/. This makes proto/ a sibling of intake.md, roadmap.md, notes, and future epic folders. Use client-proto/ only when the project already follows that convention or when prototyping inside an application package.

When product behavior or domain rules emerge during prototype work, document them beside the planning artifacts in planning/<initiative>/business/*.md with stable rule IDs. Keep the prototype close to the real product surface: do not add visible explanatory copy for internal architecture, business rules, testing strategy, provider details, or implementation notes unless that text would exist in the shipped UI.

Project root

This skill writes artifacts at paths relative to the project root (the repo where the prototype lives), not the agent's current working directory.

• If invoked from inside the project, use the relative paths shown in this skill (e.g., planning/<initiative>/proto/).
• If invoked from another directory (e.g., a sibling repo, or when the project lives elsewhere), prepend <project-root>/ to every artifact path.
• When the project root is ambiguous, confirm with the user via the harness question tool before writing.

Prompting

Follow the project-wide convention in CLAUDE.md / AGENTS.md ("Skill Prompting Conventions"). Use the harness's structured-question tool — AskUserQuestion (Claude Code), ask_user_question (Codex), or question (OpenCode) — for the decision points below. Use free-form text only where a path/name/value cannot be enumerated.