Detalle del Skill
html-design-prototypes
Useful for HTML UI prototyping, but not general HTML development.
Revisar antes de usar
La revisión automática comprueba relevancia, no seguridad ni respaldo. Lee las instrucciones de la fuente antes de usar este Skill.
SKILL.md
Este extracto es una copia guardada durante la revisión. La fuente externa contiene la versión completa y actual.
---
name: html-design-prototypes
description: >-
**TRIGGER: about to populate `AskUserQuestion` options with `preview:` content for any visual UI / screen / layout / component / animation comparison.** STOP and ask first: *"Quick inline chip comparison, or a full HTML prototype you can open in the browser?"* Chips flatten color, type, spacing, and motion into monospace; HTML prototypes are real. **No carve-out for "simulate", "demo", "mock up", "quick decision" — those name the surface, not an exception.** When user picks HTML, this skill creates prototypes for visual design, component playgrounds, animation tuning, and design system exploration — even when the final target is React, Swift, SwiftUI, Android, or another framework. Use whenever the user wants to mock, prototype, sketch, tune, or explore any UI element before production code. HTML is the fastest design-thinking surface; reach for it even for non-web targets. For N alternatives use html-brainstorm-grid; for a single tunable component use this skill.
metadata:
version: "1.2.1"
---
# HTML Design & Prototypes
HTML is the fastest design surface available — instant feedback loop, real layout engine, real typography, real interaction. Use it to sketch designs even when the production target is React Native, Swift, or anything else. The translation from HTML+CSS to the final framework is mechanical; the design exploration is what's hard.
## Pre-flight — run BEFORE writing the artifact
This skill produces an interactive artifact. **Invoke the `html-skills-listen` skill from this plugin first** (Skill tool: `html-skills:html-skills-listen`). It sets up a per-session local receiver and arms a `Monitor` so user submissions arrive as session notifications instead of as copy-paste round-trips. It's idempotent — invoke every time you fire this skill.
Capture the URL it returns. If it returned one, inject it as `window.__CLAUDE_SUBMIT_URL__` in the HTML you're about to write. If it reported web/sandbox mode (no URL returned), generate the HTML *without* `__CLAUDE_SUBMIT_URL__` set — `submitToClaude` will fall back to clipboard mode automatically.
Skipping this step costs the user a copy-paste round-trip on every submit. Invoking the skill is cheap and idempotent.
## When to use this skill
- "Design / mock / prototype a [component, screen, animation, transition]"
- "Help me visualize how X should look"
- "Try a few directions for the [hero, card, modal, button]"
- "Tune this animation / interaction"
- "Build a quick playground for the [tooltip, dropdown, picker]"
- Whenever the user is in the design-thinking phase, even if the final target is non-web
## Output requirements
Real CSS, no Tailwind unless asked. Real fonts via Google Fonts. Real animations via CSS transitions/keyframes or the Web Animations API.
For interactive prototypes, always include a **Submit button** (calls `submitToClaude`) that sends the chosen values back to the agent in the standard payload envelope, ready to apply to the real component:
```js
const params = { duration: '220ms', scale: 1.04, shadow: '8px', easing: 'spring' };
navigator.clipboard.writeText(`Apply these to the real CheckoutButton:\n${JSON.stringify(params, null, 2)}`);
```
## HTML output foundation
These defaults apply to **every** artifact this skill produces, on top of the requirements above. If a rule above conflicts with this list, the rule above wins; otherwise these are non-negotiable.
- **Output a real `.html` file the user opens in a browser — never inline-render in chat.** Every artifact this skill produces is a file on disk (`<topic>-<kind>.html`), not an HTML block embedded in the agent's chat surface (claude.ai artifact/canvas widgets, fenced ```html``` blocks, custom rendered iframes, etc.). Inline rendering strips features, themes unpredictably against the surrounding chat (often unreadable in dark mode), and lacks the stable origin and clipboard/network access the submit handler needs. Always write the fileLeer la fuente completa en GitHub (abre una página externa)