home / skills / petekp / agent-skills / tuning-panel

tuning-panel skill

/skills/tuning-panel

This skill creates interactive tuning panels to adjust parameters visually, surfacing relevant values and exporting changes for lightweight LLM consumption.

This is most likely a fork of the tuning-panel skill from petekp
npx playbooks add skill petekp/agent-skills --skill tuning-panel

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

Files (7)
SKILL.md
4.6 KB
---
name: tuning-panel
description: Create visual parameter tuning panels for iterative adjustment of animations, layouts, colors, typography, physics, or any numeric/visual values. Use when the user asks to "create a tuning panel", "add parameter controls", "build a debug panel", "tweak parameters visually", "fine-tune values", "dial in the settings", or "adjust parameters interactively". Also triggers on mentions of "leva", "dat.GUI", or "tweakpane".
---

# Tuning Panel Skill

Create bespoke parameter tuning panels that give users visual control over values they're iterating on. These panels surface all relevant parameters for the current task, enable real-time adjustment, and export tuned values in an LLM-friendly format.

## Core Philosophy

**Err on the side of exhaustive.** When a user is tuning something, surface every parameter that could reasonably affect the outcome. Missing a parameter forces context-switching; having "too many" parameters costs only scroll distance.

**Debug-mode only.** Tuning panels should never appear in production. Use environment checks, build flags, or URL parameters.

**Export changed values only.** LLM exports should show only what was tuned, not all 100+ parameters.

## Platform Selection

| Platform | Library | Reference |
|----------|---------|-----------|
| **React** | Leva (recommended) | [references/react-leva.md](references/react-leva.md) |
| **SwiftUI** | Native controls | [references/swiftui.md](references/swiftui.md) |
| **Vanilla JS** | Tweakpane or dat.GUI | [references/vanilla-js.md](references/vanilla-js.md) |

## Implementation Workflow

### Step 1: Identify All Tunable Parameters

Analyze the code being tuned and extract every parameter that affects the output. See [references/parameter-categories.md](references/parameter-categories.md) for exhaustive lists by domain.

**Common categories:**
- **Animation**: duration, delay, easing, spring physics (stiffness, damping, mass)
- **Layout**: padding, margin, gap, width, height, position
- **Visual**: colors, opacity, shadows, borders, transforms
- **Typography**: font size, line height, letter spacing, weight

**Discovery strategies:**
1. Search for magic numbers (any hardcoded numeric value)
2. Look for style objects (CSS-in-JS, inline styles, theme values)
3. Find animation definitions (Framer Motion, CSS transitions, SwiftUI animations)
4. Identify color values (hex, RGB, HSL anywhere in the file)
5. Check component props with numeric or color defaults
6. Examine CSS custom properties (`--var-name` declarations)

### Step 2: Create Debug-Mode Panel

Wrap the tuning panel so it only appears in development:

- **React**: `process.env.NODE_ENV === 'development'`
- **SwiftUI**: `#if DEBUG`
- **Vanilla JS**: URL parameter `?debug` or environment check

See platform-specific references for code patterns.

### Step 3: Implement Controls

Follow these principles:

1. **Group related parameters** using folders/sections
2. **Use appropriate control types**: sliders for numbers, color pickers for colors, dropdowns for enums
3. **Set sensible min/max/step values** based on the parameter domain
4. **Include presets** for common configurations
5. **Add reset buttons** to return to defaults

### Step 4: Add LLM Export

**Critical requirements:**

1. **Store defaults** at initialization for comparison
2. **Use tolerance for floats** (e.g., `Math.abs(a - b) > 0.001`)
3. **Filter to changed values only** - don't show unchanged parameters
4. **Format for readability** - group by category, use human-readable names

**Export format:**

```markdown
## Tuned Parameters for [ComponentName]

### Changed Values
- Duration: 300 → 450
- Spring Damping: 0.80 → 0.65
- Corner Radius: 12 → 16

### Apply These Values
Update the component at `src/components/Card.tsx:42` with the values above.
```

**Why this matters:**
- A panel might expose 100+ parameters
- Exporting all values wastes tokens and obscures what changed
- The `default → current` format makes diffs scannable

## Additional Resources

### Reference Files
- **[references/react-leva.md](references/react-leva.md)** - Complete React/Leva implementation guide
- **[references/swiftui.md](references/swiftui.md)** - SwiftUI native controls and export patterns
- **[references/vanilla-js.md](references/vanilla-js.md)** - Tweakpane and dat.GUI for plain JS
- **[references/parameter-categories.md](references/parameter-categories.md)** - Exhaustive parameter lists by domain

### Example Files
- **[examples/react-leva-animation.tsx](examples/react-leva-animation.tsx)** - Complete animation tuning panel
- **[examples/export-format.md](examples/export-format.md)** - Full LLM export template

Overview

This skill creates visual tuning panels for iterating on animations, layouts, colors, typography, physics, and other numeric or visual values. It surfaces every relevant parameter for a task, enables real-time adjustment, and exports only the values that changed in an LLM-friendly format. The panels are intended for debug/development use and include sensible controls, grouping, presets, and reset behaviors.

How this skill works

The skill scans the target code or UI to identify tunable parameters (magic numbers, style objects, animation configs, color values, and component props). It builds a debug-only panel using an appropriate platform library (Leva for React, native controls for SwiftUI, Tweakpane/dat.GUI for vanilla JS), groups related controls, and wires live updates into the running UI. When requested, it compares current values to stored defaults, filters changed fields, applies a numeric tolerance for floats, and outputs a concise `default → current` export grouped by category.

When to use it

  • When a user asks to "create a tuning panel", "add parameter controls", or "build a debug panel"
  • When iterating on animations, easing, or physics parameters
  • When fine-tuning layout, spacing, and responsive values
  • When adjusting visual properties like colors, opacity, shadows, and borders
  • When you need an exportable summary of tuned values for code updates

Best practices

  • Expose every parameter that can affect the outcome; err on the side of exhaustive discovery
  • Restrict panels to debug mode (environment flags, build targets, or URL query) so they never ship to production
  • Group related controls and choose appropriate control types (sliders for numbers, color pickers for colors, dropdowns for enums)
  • Store initial defaults at panel init and export only changed values using a small tolerance for floats
  • Provide presets and reset buttons to speed iteration and revert mistakes

Example use cases

  • Add a Leva panel to a React animation playground to tweak duration, easing, and spring settings live
  • Add a debug overlay in a SwiftUI prototype to adjust font sizes, line heights, and spacing during design reviews
  • Attach a Tweakpane to a vanilla JS canvas demo to tune physics parameters like mass, damping, and gravity
  • Generate a compact LLM-friendly export showing only changed values to paste into a PR description or issue
  • Create presets for common visual themes and share tuned values with engineers for implementation

FAQ

Will the panel appear in production?

No. The pattern requires a debug-only guard (NODE_ENV, #if DEBUG, or a ?debug query) so panels are omitted from production builds.

How are exports formatted?

Exports show grouped, human-readable `default → current` entries and list only parameters that changed, making diffs easy to apply in code.