PlayGround: The Component Fitting Room
Writing UI features directly into the page means one change breaks everything — tweaking a single button requires spinning up the whole page. The solution is to build an isolated component PlayGround first: each UI element has its own demo, and once it works, you integrate it into the real page.
Below is a minimal PlayGround: the left panel shows a live component preview, and the right panel has the parameter controls. Tweak anything freely — no change here will affect anything else on the page. This is "isolated debugging."
Tweaking in PlayGround
Every tweak you just made affected only this one demo. Styles and business logic don't interfere with each other — finished parameters go straight into the real component, which is already production-ready by the time you integrate.
What Happens When You Write Directly into the Page
To tweak the same button: first spin up the whole page, log in, fetch data, and navigate to the right state — just to see it once. Styles and business logic are tangled together, so increasing the corner radius might push the adjacent layout sideways. Pull one thread, unravel everything.
Same idea, different cost. Storybook is the industry-standard solution, but its setup overhead is too heavy — overkill for AI-assisted rapid prototyping. PlayGround borrows the concept: lay all component demos out on a single static page, so changing components doesn't break business logic and adjusting business logic doesn't scramble component styles. The cost is nearly zero.
Animations Must Come First
Whenever a page animation is involved, you must first create a static PlayGround page to freely adjust and test the component, before writing it into the real page.
When Requirements Change, the Demo Changes Too
After a requirement changes, you must synchronously update the PlayGround. Keep the demo reflecting the latest form of the component — don't let it become an outdated decoration.
Even Canceled Demos Are Kept
Demos are only added or modified — never deleted. Even if a feature requirement is canceled, keep its demo. It's a historical archive of the design process; when that requirement is revived, you can pick it right back up.
Three real-world scenarios. Choose what you think is the correct action, then see the verdict and reasoning.
A Conversation Test Page Is Required
When the project involves an AI conversation feature, the PlayGround must include a simple conversation test page — one that can run a single dialogue round independently, without the full business flow.
List All Prompts
The page must list every Prompt the project uses. Prompts are the core assets of an AI product — buried in code strings, they are impossible to debug. Laid out on the page, they can be quickly compared and tuned.
Fine-tune the component in the fitting room before it walks the stage. PlayGround, at the cost of a single static page, buys you bidirectional isolation between components and business logic.
Source: corresponds to rule-opensource.mdc Chapter 3 "PlayGround Component Page Specification," repository itshen/xs_vibe_rules.