home / skills / petekp / claude-code-setup / explanatory-playground

explanatory-playground skill

/skills/explanatory-playground

This skill helps you visualize internal system behavior by building interactive debugging views for state machines, data flows, and algorithms.

npx playbooks add skill petekp/claude-code-setup --skill explanatory-playground

Review the files below or copy the command above to add this skill to your agents.

Files (2)
SKILL.md
4.6 KB
---
name: explanatory-playground
description: Build interactive debugging interfaces that reveal internal system behavior. Use when asked to "help me understand how this works", "show me what's happening", "visualize the state", "build a debug view", "I can't see what's going on", or any request to make opaque system behavior visible. Applies to state machines, data flow, event systems, algorithms, render cycles, animations, CSS calculations, or any mechanism with hidden internals.
---

# Explanatory Playground

Build dev-only visualizations that make invisible system behavior visible.

## Workflow

### 1. Clarify the target

Use AskUserQuestion to understand what needs visualization:

```
question: "What kind of system should the playground reveal?"
header: "System type"
options:
  - label: "State machine"
    description: "Finite states with transitions (auth flow, form wizard, game state)"
  - label: "Data flow"
    description: "Data transforming through a pipeline (API → transform → render)"
  - label: "Event system"
    description: "Publishers and subscribers, event propagation"
  - label: "Algorithm"
    description: "Step-by-step logic (sorting, pathfinding, search)"
```

Then ask what's confusing:

```
question: "What specifically is hard to understand?"
header: "Hidden aspect"
options:
  - label: "Current state"
    description: "I can't see what state the system is in right now"
  - label: "Why transitions happen"
    description: "I don't know what triggers changes or why"
  - label: "Data shape"
    description: "I can't see what the data looks like at each step"
  - label: "Timing/sequence"
    description: "Things happen too fast or in unclear order"
```

### 2. Identify what's hidden

Based on answers, determine what to surface:
- **State** — Values that change over time
- **Transitions** — Events that trigger changes
- **Relationships** — How parts communicate
- **Logic** — Conditions, thresholds, rules

### 3. Pick visualization approach

| System | Visualization | Library |
|--------|--------------|---------|
| State machines | Node-edge graph | react-flow |
| Data flow | Directed graph / Sankey | react-flow |
| Events | Timeline | custom or recharts |
| Algorithms | Step animation | custom |
| Render cycles | Component tree + diffs | custom |
| Animations | Timeline scrubber | custom |
| CSS/Layout | Box model overlay | custom |

See [references/patterns.md](references/patterns.md) for layouts, code, and implementation details.

### 4. Choose interactivity level

Ask if unclear:

```
question: "How interactive should the playground be?"
header: "Interactivity"
options:
  - label: "Just show me (Recommended)"
    description: "Real-time display of state and changes"
  - label: "Let me poke around"
    description: "Click/hover to inspect details and trace origins"
  - label: "Let me trigger things"
    description: "Fire events, modify state, inject test data"
  - label: "Time travel"
    description: "Record history, scrub through past states, replay"
```

| Level | Features | When |
|-------|----------|------|
| 1 - Observe | Real-time state display | Always |
| 2 - Inspect | Click/hover for details | Usually |
| 3 - Manipulate | Trigger events, modify state | Edge cases |
| 4 - Time travel | History scrubbing, replay | Race conditions |

Start with 1-2. Add 3-4 when needed.

### 6. Instrument minimally

**Prefer event emitters** (least invasive):
```typescript
const debugEmitter = new EventEmitter();
function transition(from, to, event) {
  debugEmitter.emit('transition', { from, to, event, timestamp: Date.now() });
  // existing logic...
}
```

**Use proxies** for third-party code:
```typescript
function observable<T extends object>(obj: T) {
  return new Proxy(obj, {
    set(target, prop, value) {
      window.dispatchEvent(new CustomEvent('state:change', {
        detail: { prop, old: target[prop], new: value }
      }));
      return Reflect.set(target, prop, value);
    }
  });
}
```

### 7. Create dev-only route

```
app/__dev/[system-name]/page.tsx
```

Guard against production:
```typescript
if (process.env.NODE_ENV !== 'development') {
  return notFound();
}
```

### 8. Document removal

Header in every created file:
```typescript
/**
 * EXPLANATORY-PLAYGROUND DEBUG TOOL
 * Remove when done:
 * 1. Delete: app/__dev/[name]/page.tsx
 * 2. Delete: src/lib/[system]-debug.ts
 * 3. Remove hooks from: src/lib/[system].ts (lines XX-YY)
 * Purpose: [what this debugs]
 */
```

## Cleanup

On removal request:
1. Delete `__dev/` route
2. Remove instrumentation (emitters, proxies)
3. Uninstall added deps if unused elsewhere
4. Search for `EXPLANATORY-PLAYGROUND` markers

Report what was removed.

Overview

This skill builds developer-only interactive debugging interfaces that reveal hidden internal behavior. It creates visual, instrumented playgrounds for state machines, data flows, event systems, algorithms, render cycles, animations, and CSS/layout issues. The goal is fast insight: show current state, why transitions happen, data shapes over time, and execution order so problems become obvious.

How this skill works

Start by clarifying what to visualize and what aspect is confusing. Instrument the target minimally (emitters, proxies, or lightweight hooks), then render a focused interactive UI (graphs, timelines, scrubbable traces, or step animations). Provide a guarded dev-only route and clear removal instructions so the playground is safe for temporary use and easy to delete.

When to use it

  • You or a teammate ask “help me understand how this works” or “show me what's happening”.
  • When state transitions, event propagation, or timing are opaque and causing bugs.
  • While debugging race conditions, unexpected renders, or data-shape mismatches.
  • When onboarding engineers to a complex flow or system design review.
  • To reproduce and explain intermittent issues in demos or bug reports.

Best practices

  • Start with a lightweight observer (event emitter or proxy) to avoid invasive changes.
  • Ask the user which system type and hidden aspect to surface before building the UI.
  • Begin with read-only displays (real-time state and timelines), then add interactivity if necessary.
  • Guard the playground with a development-only route and environment checks to prevent leaks to production.
  • Include a header comment and a short removal checklist in every created file so cleanup is simple.

Example use cases

  • State machine visualizer for an auth flow showing current state, triggers, and failed transitions.
  • Data pipeline Sankey view that shows payload shape and size at each transform step.
  • Event timeline for a pub/sub system to trace origin, propagation order, and subscribers that react.
  • Algorithm stepper for pathfinding to animate visited nodes, frontier, and chosen path.
  • Render-cycle inspector to show component tree diffs and props/state changes between frames.

FAQ

How invasive is the instrumentation?

Instrumentation is minimal by design: prefer emitters and proxies that observe without changing core logic. Add temporary hooks only when required.

How do I ensure the playground is not shipped to production?

Create a dev-only route and guard it with NODE_ENV checks. Add a clear removal header in each file and a simple checklist for uninstalling instrumentation and deps.