Playground

Build a playground experiment from the supplied source: [Component name]

Usage context
[Who uses it, where it appears and what decision it supports.]

Source: attached image or screenshot.

- Recreate only the exact slice named below and ignore the rest of the frame.
- Treat the image as the source of composition, hierarchy, density, spacing
  relationships and visual intent.
- Estimate measurements from the reference at normal browser zoom.
- Preserve relationships between values rather than chasing isolated pixels.
- Do not introduce visual elements that are absent from the named slice.

Exact slice
[Name only the element to recreate and what to ignore.]

Implementation mode: Playground — reference first

Priority:
1. visual similarity
2. layout and proportions
3. hierarchy and density
4. token alignment

Decision order:
1. Reuse an existing UI primitive when it fits the semantic role and at least
   80% of the required structure or behaviour.
2. Prefer an existing semantic token when it preserves the reference.
3. Use an existing foundation token when it is the closest suitable value.
4. Use a local custom Tailwind value only when the available tokens visibly
   damage a defining trait of the reference.

- Local values such as rounded-[29px], w-[720px] or a local arbitrary shadow
  are allowed when justified by the visual analysis.
- Keep every custom value inside the experiment file and list it in the final
  report with the token considered and why it failed.
- Do not create or change tokens, add global CSS or modify production
  primitives.

Fidelity: Reference-preserving

- Preserve silhouette, proportions, anatomy, hierarchy, density, alignment and
  distinguishing visual character.
- Adapt only where required by the selected implementation mode,
  accessibility or responsive behaviour.
- Do not reinterpret the source as a different pattern.

Visual intent
- Derive the intended character, dominant element and supporting emphasis from
  the source and usage context.

Must preserve
- Identify and preserve the traits that make the source recognisable.

Must avoid
- Do not add patterns or decoration that are absent from the source or product
  context.
- Do not fall back to a generic SaaS composition.

Copywriting
- Transcribe visible source text exactly. If the source has no supplied copy,
  use concise product-specific language and never use lorem ipsum, Acme or
  placeholder metrics.

Interactions
- Infer only interactions that are visible or strongly implied by the source.
- Implement local behaviour without a backend.

Scope

- Read src/components/playground/README.md first and follow it.
- Keep the experiment implementation inside src/components/playground/.
- Create one component file, export it from
  src/components/playground/index.ts, and render it once in one DocSection in
  src/app/docs/playground/content.tsx.
- Do NOT edit src/tokens/**, src/components/ui/**, src/app/** routes,
  src/config/navigation.ts, global stylesheets, existing experiments or
  existing documentation outside that single preview integration.
- Do NOT add dependencies, routes, navigation items, global CSS or a second
  theming runtime.
- Design system mode changes the implementation strategy, not the edit scope:
  it does not author or modify production components.
- If the brief genuinely requires a change outside the allowed files, stop and
  explain the required change instead of making it.

Workflow — follow in order

Phase 1 — Inspect

- Read src/components/playground/README.md.
- Read the relevant Next.js guide in node_modules/next/dist/docs/ before
  writing code.
- Inspect src/tokens/** for available semantic, foundation and component
  values.
- Inspect src/components/ui/** before implementation.
- Inspect existing playground examples that solve a similar layout or
  interaction problem.
- Inspect the current playground barrel and preview integration.
- Do not write implementation code during this phase.

Primitive reuse rule

- Reuse an existing primitive when it satisfies the semantic role and at least
  80% of the required structure or behaviour.
- Compose existing primitives before creating a new control.
- Do not modify production primitives from the playground.
- In Playground mode, style locally when a primitive cannot preserve the
  defining reference traits.
- In Design system mode, keep the system primitive and adapt the composition
  around its authored contract.

Phase 2 — Analyse and plan

Analyse the source yourself. Do not ask the user to supply technical visual
analysis. Cover:
- Visual DNA
- component anatomy
- reading flow
- optical hierarchy
- density and layout
- surface, border and radius hierarchy
- typography hierarchy
- spacing rhythm
- interaction hierarchy
- token and primitive strategy

Keep the pre-code report compact and use exactly this structure:

Visual DNA
1. [defining trait]
2. [defining trait]
3. [defining trait]

Anatomy
[compact component tree]

Hierarchy
Primary:
Secondary:
Supporting:
Decorative:

Layout and rhythm
Silhouette:
Density:
Spacing:
Surface / border / radius:
Typography:

Implementation strategy
Reuse:
Compose:
Create locally:
Token:
Custom:

Plan
1. [implementation step]
2. [implementation step]
3. [review step]

Do not turn this analysis into a long essay. Estimate only measurements that
materially affect silhouette, hierarchy or interaction.

Phase 3 — Implement

- Create src/components/playground/<name>.tsx and keep the experiment in that
  one file. Do not create a folder, stylesheet, story or notes file.
- Use the supplied copy exactly and implement the listed interactions locally.
- Preserve intentional asymmetry, uneven whitespace and differences in
  emphasis. Do not automatically normalise the source into a centred grid.
- Establish hierarchy through typography, spacing, alignment and contrast
  before adding borders, shadows, icons or surfaces.
- Use the fewest visual containers necessary. Do not wrap every section in a
  card.
- Do not add gradients, glow, glass, decorative pills, badges, illustrations
  or icon chips unless the source or product context requires them.
- Follow project conventions: use client only when interaction requires it,
  compose classes with cn(), use semantic markup, preserve visible focus,
  handle disabled states and respect reduced motion.
- Export the experiment from src/components/playground/index.ts.
- Render it once in a focused preview section in
  src/app/docs/playground/content.tsx.

Phase 4 — Review, validate and report

Visual QA

- Compare the implementation to the reference at normal browser zoom.
- Review in this exact order:
  1. silhouette
  2. proportions
  3. hierarchy
  4. layout
  5. density
  6. spacing rhythm
  7. typography
  8. alignment
  9. surface hierarchy
  10. decoration
- Fix the three largest visible mismatches before reporting completion.
- Do not keep an implementation choice merely because it compiles. Change it
  when it visibly weakens the reference.
- Verify light and dark themes, narrow and wide layouts, keyboard focus, hover,
  pressed, disabled and reduced-motion behaviour where relevant.
- Confirm that the component introduces no accidental horizontal overflow.

Validation

- Run npx tsc --noEmit.
- Run npm run lint.

Final report

- List created and modified files.
- Report the three defining visual traits.
- Report the three largest mismatches fixed during visual QA.
- Summarise primitive reuse, token choices, snapped measurements and any
  mode-allowed custom values.
- Report TypeScript and lint results.
- Confirm that token files, production UI primitives, navigation and unrelated
  routes were not modified.
- Classify each meaningful part using only:
  - Reusable as-is
  - Needs adaptation
  - Experiment-only
- Do not calculate a promotion score or confidence number.