Interactive styler

Interactive Styler

Overview

Instead of describing styles in words ("we could use a soft glassy look with rounded cards…"), show them. This skill renders live, clickable previews inline using the show_widget tool. The user sees real rendered components, clicks the one they want, and the click sends their choice straight back to chat via sendPrompt(). Their picks are captured as concrete CSS-variable design tokens that get wired into the actual build — so what they saw is literally what they get.

Core principle: a picked preview beats a described option. Never make the user imagine a style you could just render.

When to Use

• User asks to build/design/restyle any webpage, page, or UI component.
• User says "show me options", "give me styles to pick from", or invokes /interactive-styler.
• Any moment in a build where you'd otherwise write "we could go with X, Y, or Z" for a visual choice.

When NOT to use: backend/logic-only work, copy edits, or when the user says "just build it" / "skip the picker". Text choices (framework, data model, scope) stay in the terminal — this is for visual decisions only.

The one-line opt-in (required first step)

When a UI build request arrives, do not silently start pickers and do not silently start coding. Ask exactly one short question first:

"Want to pick the styling visually (I'll render clickable previews), or should I just build it?"

If they choose visual → run the funnel. If "just build" → proceed normally, no widgets. This gate is cheap and prevents both surprise-widgets and surprise-coding.

Before your first widget

Call mcp__visualize__read_me once (silently — do not narrate it) to load the widget contract, then render. Every widget:

• Uses CSS variables for color so it respects the user's light/dark theme; transparent page background; no outer padding.
• Calls the global sendPrompt(text) to return the user's choice as a chat message.
• Follows the templates in references/widget-patterns.md — read that file before building your first picker so pickers stay consistent and fast.

The staged funnel

Move one stage at a time. Each stage renders 3–4 options with exactly one marked ⭐ Recommended (your pick + a one-line why). After each stage, apply the choice and offer the next — the user can stop at any point with "good enough, build it."

Stage	Widget	Selection	Seeded from
1. Vibe	Mini mock-pages, one per vibe	single-click → sends	references/vibe-presets.md (6 presets) + a "✏️ Create my own" option
2. Palette & type	Swatch rows + font-pairing samples	single-click → sends	chosen vibe's tokens
3. Components	Gallery: 3 buttons, 3 cards, 3 nav, etc.	multi-select toggle → Confirm button sends all	chosen vibe + palette
4. Animations	Live-playing hover / transition / loading cells	multi-select toggle → Confirm	chosen vibe
↺ Assembled preview	A small real page built from picks so far	view only, re-rendered after each stage	all picks

Stage 1 custom vibe: if the user picks "✏️ Create my own", ask them to describe it in words ("dark, moody, neon accents, sharp corners"), generate a full token set for it, render its mock-page like a preset, and drop it into the funnel. If they like it, offer to append it to references/vibe-presets.md for reuse.

Assembled preview: after every stage, re-render one widget that is a small but real page (hero + card + button + nav) using the accumulated tokens, so the user sees their choices combined, not just in isolation. This is the payoff — always keep it current.

Every widget carries two escape hatches

Include these as buttons in every picker so the user is never trapped in the funnel:

• ⭐ Just use your recommendations → sendPrompt("Use your recommended styling and build it")
• Skip / build now → sendPrompt("Skip the rest of the picker and build with current selections")

When you receive either, stop rendering pickers and proceed to the build with the best current token set.

Capturing picks → real code

This is what makes the skill honest. Each option in a widget is backed by a concrete token block (see references/vibe-presets.md for the shape: --bg, --surface, --text, --accent, --radius, --shadow, --font-sans, --ease, etc.).

1. When a sendPrompt selection arrives, record the exact tokens behind that option into a running style spec (keep it in your working notes / a :root { } block).
2. Build the real site using those same variables — do not eyeball or re-invent values. The preview and the product share one token set.
3. Put the final tokens in a single :root { } (or theme file) in the actual project so the choices are centralized and easy to tweak later.

Common mistakes

• Describing instead of rendering. If you catch yourself typing "we could use…" for a visual choice, render a widget instead.
• Skipping the opt-in. Always ask the one-line question first; never auto-spawn widgets or auto-code.
• Widgets without sendPrompt. A preview the user can't click to choose is just decoration. Wire every option.
• Forgetting the assembled preview. Isolated components hide clashes; the combined preview is the point.
• Re-inventing token values at build time. Wire the picked tokens verbatim, or the build won't match the preview.
• No escape hatch. Every widget must offer "use recommendations" and "build now".