home / skills / petekp / agent-skills / explanatory-playground

explanatory-playground skill

/skills/explanatory-playground

This skill helps you reveal hidden system behavior with interactive visualizations of state machines, data flows, and event systems.

This is most likely a fork of the explanatory-playground skill from petekp
npx playbooks add skill petekp/agent-skills --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 dev-only interactive visualizations that reveal hidden system behavior. It helps create debug routes, lightweight instrumentation, and UI playgrounds to visualize state machines, data flow, events, render cycles, animations, algorithms, and CSS/layout internals. The goal is fast developer feedback without changing production code.

How this skill works

Ask targeted questions to clarify the system type and the specific hidden aspect, then choose a visualization pattern (graphs, timelines, step animations, box overlays). Instrument minimally using event emitters or proxies, add a guarded dev-only route, and expose controls for observing, inspecting, manipulating, or time-traveling through state. Include clear headers and a removal checklist so everything can be traced and cleaned up after debugging.

When to use it

  • When someone asks “help me understand how this works” or “show me what’s happening”.
  • To reveal current state and transitions in state machines or auth flows.
  • To trace data shape and transformations through pipelines and renders.
  • To inspect event propagation, timing, and sequence issues.
  • To debug render cycles, layout calculations, animations, or algorithm steps.

Best practices

  • Start by asking what to visualize: system type and the confusing aspect before building UI.
  • Prefer non-invasive instrumentation (event emitters) and probes that can be toggled or removed easily.
  • Add a dev-only route protected by NODE_ENV checks so debug UIs never reach production.
  • Start with observe/inspect modes; add manipulation and time travel only when necessary.
  • Document every debug file with an explicit removal header and a short cleanup checklist.

Example use cases

  • State machine inspector: node-edge graph showing current state, available transitions, and recent events. Click a node to reveal guard conditions and payloads.
  • Data pipeline trace: directed graph or Sankey that shows data shape at each stage with sample payloads and timing. Hover to view diffs.
  • Event timeline: ordered stream showing publisher, subscribers, payload, and propagation path for race conditions or missed handlers.
  • Render cycle diff: component tree overlay highlighting props/state changes and DOM diffs between frames.
  • Algorithm stepper: animated sequence that lets you step forward/back through algorithm iterations with variable inspection.

FAQ

How invasive is the instrumentation?

Keep it minimal. Prefer emitting events or wrapping objects with proxies rather than modifying core logic. Instrumentation should be opt-in and isolated in dev-only files.

How do I prevent debug UI from shipping to users?

Put the playground behind a dev-only route and gate it with NODE_ENV checks or authenticated dev flags. Remove files and references after debugging and follow the documented cleanup steps.