AddThisFeature
Sign in

Component Playground

Render every component in isolation, in every state, with its props adjustable.

moderate Developer Experience

What it adds

A development surface that renders each component on its own with controls for its props, themes, and states.

What your agent is told to do

5
  1. 1

    Render playground examples inside the same providers, theme, reset, and global styles the real application uses. A component that only looks right in the playground is a component whose playground is lying.

  2. 2

    Give each component controls for its documented props, and derive the control list from the component's own definition so a new variant appears without anyone remembering to add it.

  3. 3

    Cover the states that are hard to reach in the product: loading, empty, error, disabled, no-permission, and content far longer than the design assumed. Those are the states the playground exists for; the happy path is already visible in the app.

  4. 4

    Include the theme and viewport switches in the playground itself, so light, dark, and narrow layouts can be checked without a build change.

  5. 5

    Do not add branches to component code for the playground's benefit. A condition that changes behaviour when rendered outside the app means the thing being reviewed is not the thing that ships.

Edge cases it handles

7
  • Examples must render through the application's real providers and styles. A playground with its own stripped-down wrapper hides exactly the theme, layout, and context problems it was built to catch.
  • Loading, error, empty, and overlong-content states must each have an example. Those states reach users through paths that are awkward to reproduce in the running app, so they go unreviewed unless the playground forces them.
  • No component may contain a code path that exists only for the playground. Test hooks, mocked data injected inside the component, and conditions keyed on the environment all mean the reviewed rendering is not the shipped one.
  • Examples must stay aligned with the component's current props, and a renamed or removed prop must break the example loudly rather than silently rendering a default.
  • Every component in the inventory should have at least one example, and the gap between the two lists should be visible, since the components without examples are usually the ones that need them.
  • The playground must not become a route in the production build, and it must not require the production data sources to load.
  • Fixture content should include text in a language with long compound words and a right-to-left script, because layouts break there first and never in the sample copy.

Definition of done

9
  • Examples render inside the application's real providers, theme, and global styles.
  • Prop controls are derived from each component's definition rather than maintained by hand.
  • Loading, error, empty, disabled, no-permission, and overlong-content states each have an example.
  • No component contains a branch that exists only for the playground.
  • Theme and viewport can be switched from within the playground.
  • Components lacking an example are reported against the component inventory.
  • The playground is absent from the production build and needs no production data source.
  • The feature matches the existing design system.
  • No existing functionality is broken.

Related features

How it works

  1. 1

    Copy the link

    Grab the Markdown instruction URL for this feature.

  2. 2

    Give it to your AI

    Paste it into Claude Code, Cursor, v0, Lovable — whatever you build with.

  3. 3

    It inspects, then implements

    Your agent reads your existing app first, then adds the feature to fit it.

Works with your stack

These instructions are written to adapt. They tell the agent to detect your framework, match your existing design system, and reuse what you already have — rather than assuming a particular stack.

Need it tighter than that? Customize the feature and tell it exactly what you're running.