Playground Skills: the Prompt Is the Deliverable

You might expect a playground built with Claude to be a settings panel that hands you back raw values. This video, from the playlist on extending Claude with skills, plugins and connectors, explains why it does not. A playground hands back a prompt, written in natural language, that you copy straight into Claude. The preview is only the means of getting there.

Six templates across four zones

The skill organizes its work around six templates spread across four zones:

• Design decisions: a design playground for components, layout, spacing, color, and typography.
• Data and queries: a data explorer covering SQL, APIs, pipelines, and rejects.
• Learning: a concept map, knowledge gaps, and scope mapping.
• Review work: document critique, diff review, and a code map.

Five requirements for every playground

Whatever the template, each playground has to meet five requirements:

• One self-contained HTML file with everything inlined.
• A live preview that updates on every change, with no Apply button.
• A prompt written in natural language rather than a dump of values.
• A copy button.
• Three to five ready-made presets, so it looks right the moment it loads.

One state object

The whole thing runs on a single invariant: one state object. Every control writes to it when it changes, every part of the preview reads from it, and one function refreshes both the preview and the prompt together.

Skip that and the pattern does not just get messy; the video says it breaks silently. If a control's value is read straight from the page instead of from state, the live preview stops being reliable.

What a good prompt looks like

The prompt has its own rule: it must read like an instruction, not a printout. The video gives the contrast directly. Instead of "border radius 8 px, shadow blur four," the prompt should say something like "a tight border radius with a subtle shadow." It should mention only the settings that changed from their defaults, and give enough context to act on even without the playground open.

Nothing enforces it

The video then names the catch. Nothing in the skill actually stops the value-dump output from happening. Whether the prompt reads as a natural instruction or as a colon-separated list of settings is left entirely to whoever writes the code, and there is no check built in.

That is why opening the finished file in a browser is a required last step, not an afterthought. It is the only way to catch a prompt that came out as a dump before it ships.

The test of a finished playground

The video's closing rule is blunt: the playground's real output is a prompt, not a list of settings. If what it hands back cannot be copied straight into Claude and acted on, it is not finished. It is a value dump.

Key takeaways

• A playground's real deliverable is the prompt the user copies, not the preview.
• The skill defines six templates across design, data, learning, and review zones.
• Every playground is one self-contained HTML file with live updates, a copy button, and three to five presets.
• A single state object feeds both the preview and the prompt through one update function.
• Reading values from the page instead of from state breaks the preview silently.
• A good prompt reads like an instruction and mentions only what changed from the defaults.
• Nothing enforces prompt quality, so opening the file in a browser is a required final step.

Try it yourself

Ask Claude to build an interactive playground for designing a card component, with border radius, shadow, padding, and color, a live preview, and a copyable prompt. Then check the result. Does the prompt read like an instruction or a printout of numbers? Does every control update the preview instantly? Are at least three presets in place on load? Does the file actually work when opened in a browser? Try it on your own component idea rather than the video's example.