Rapid UI prototyping as a single self-contained HTML file with constraint tracking and theme support. Use this skill whenever the user wants to prototype, mock up, or preview a user interface before implementing it — for any target: web apps, mobile apps, desktop apps, plugin/extension UIs (Lightroom, VS Code, Figma), embedded displays, or any SDK/toolkit. Trigger on requests to "create an HTML mockup", "sketch the interface", "prototype the dialog/panel/form/dashboard", "show me how it would look", or any request to visualize a UI layout. Also trigger when the user wants to explore how a UI would work within specific platform constraints (SDK widget limitations, screen size limits, toolkit restrictions). Do NOT trigger for fixing CSS bugs in existing code, building production React/Vue/Angular components, accessibility audits of existing UIs, or adding features to already-implemented interfaces.
Create interactive UI prototypes as single self-contained HTML files. The prototype serves as a visual reference for how the interface should look and behave, regardless of the target technology.
Start by gathering essential context from the user:
If documentation about the target environment exists in the project, read it to extract relevant constraints. The user may also provide constraints verbally — capture both sources.
For constrained environments (plugin SDKs, embedded UIs, specific toolkits), constraints are the most valuable part of the prototyping process. Invest time in understanding the target platform deeply: what widgets exist, what layout is possible, what events are available, what workarounds are commonly used. A prototype that looks great but ignores platform limitations gives a false sense of what's achievable.
Save all identified constraints to a constraints.md file alongside the prototype HTML.
This file is the single source of truth for what the UI can and cannot do.
Structure of constraints.md:
# UI Prototype Constraints
## Target Environment
[Environment name and brief description]
## Technical Constraints
- [Constraint from SDK/platform docs or user input]
- [...]
## Design Constraints
- [User-defined constraint: branding, sizes, etc.]
- [...]
## Acknowledged Violations
- [Constraints the user chose to ignore, with reason]
Present the constraints to the user for confirmation before starting the prototype. The user can add, modify, or remove constraints at any time during the process.
Generate a single self-contained HTML file with all CSS and JavaScript inline.
Prototype standards:
localStorage so it persists across
page reloads. Define both themes as CSS custom properties for easy switching.After generating the file, ask the user:
"Do you want me to open the prototype in your browser, or just save the file?"
Act according to their preference. If they want it opened, use the appropriate command for the platform.
The user will request changes: adding elements, modifying layout, changing behavior, removing components. For each request:
constraints.md with the user's reasoning.After applying changes, offer to reopen the file in the browser if they had it open before.
When the prototype contains acknowledged violations, display them as a visible notice panel at the bottom of the HTML interface. This panel should:
This makes violations immediately visible to anyone viewing the prototype, not just those reading the source code.
Also, when a constraint conflict was detected and resolved with an alternative (e.g., splitting a form into multiple steps to respect a field-per-screen limit), display a brief "Constraint Resolution" note near the relevant UI area explaining what was adapted and why. This helps reviewers understand that the design choice was intentional, not arbitrary.
constraints.md before applying changes —
constraints may have been updated during the conversation.