Playground demos

How playgrounds work is in the Playground README, mainly its Layouts and Design system sections.

Goal

A demo soft-sells Data Client first and teaches users and agents how to use it second. People copy what they see and agents copy the code, so both teach.

• Use case: one where the preview clearly shows the feature's advantage over the alternative.
• Mechanism: easy to see how it works and why it's better.
• Look: very beautiful, built from the playground design system, with no inline styles or CSS in the example code.
• Scope: as simple as possible while still showing maximum value, utility and related features.
• New ideas: inventing one needs at least high reasoning effort. At lower or unknown effort, hand the ideation to a high-effort subagent or ask the user.

Conventions

• The demo makes its point without captions or narration text. If it needs them, pick another use case.
• Loading states are skeletons (<Loading />, skeleton), not "Loading…" text.
• A demo of a real public API calls its real URL, intercepted by a fixture in website/src/fixtures/, so copied code works.
• The code follows the practices a careful app would, even where the demo could skip them, because readers copy it.
• Use the row layout, with one uncollapsed file, when the code is the lesson. Use demo, which hides the code, only when the point is purely visual, and ask the user first.
• Anything extra a demo needs goes in the demo code with a design-system component, never a new Playground prop.
• Check phone width and both themes.