---
name: blazium-performance
description: >
  Profiles a Blazium project with JustAMCP monitors
  (get_performance_monitors, profiling_detect_bottlenecks, profiling_monitor)
  plus Autowork soak. Use for FPS/memory bottlenecks. Not a generic
  profiler.
when-to-use: >
  FPS drop, hitch, memory leak, get_performance_monitors,
  profiling_detect_bottlenecks, profiling_monitor, Autowork soak
metadata:
  author: blazium-games
  short-description: Measure bottlenecks with JustAMCP profiling_tools + soak
---

# Blazium performance

JustAMCP + Autowork soak. Baseline: **Blazium
0.8.x (Godot 4.8.x fork, branch `blazium_4.8`)**.

**Version drift:** inspect `config_version` / `features` in `project.blazium`
(or `project.godot`). Keep `blazium_4.8`-safe APIs unless the user asks to migrate.

Toolset: JustAMCP `profiling_tools`.
`disciplines/performance-optimization` into this skill.

## When to use

- Use when FPS, hitching, or memory needs evidence before a change.

**When not to use:** feature work without a measured problem. Export size
→ `blazium-export`. A generic “optimize everything” pass.

## Grok host

Read this skill, then the domain skill that owns the bottleneck (3D /
physics / UI). Spawn `qa-tester` for the soak and the domain specialist
for the fix. Child prompts must include monitor names and the before
snapshot. Do not dump the catalog.

Evidence is monitor JSON + Autowork soak — not a screenshot of a profiler
dock. Grok `code_execution` is not Blazium evidence.

## Workflow

1. **Inspect.** Play-mode vs editor. `list_toolsets` → `profiling_tools`.
2. **Choose.** Snapshot vs threshold watch vs Autowork soak.
3. **Implement.** Call the three tools below. Change one bottleneck at a
   time using the owning domain skill.
4. **Verify.** Re-run `profiling_detect_bottlenecks` / Autowork soak.
5. **Handoff.** Monitor names + before/after. Fix in the domain skill.

## Patterns

### Monitor list

`get_performance_monitors` — memory, FPS, navigation, rendering counters.

### Bottleneck workflow

1. `get_performance_monitors` (baseline)
2. `profiling_detect_bottlenecks` (common counter heuristics)
3. `profiling_monitor` with caller thresholds
4. Fix via the matching skill (3D / physics / UI / …)
5. Repeat

### Autowork soak

Long `wait` / input simulate in `test_*.gd` — see `blazium-autowork`.
Do not treat a single screenshot as proof.

## Output contract

- Surface used (`:6506` or files-only)
- Monitor names + before/after
- Domain skill used for the fix
- Autowork soak name or `INCONCLUSIVE`

## Pitfalls

- **Guessed a profiler dock** → `Performance.get_monitor(Performance.TIME_FPS)` and JustAMCP `get_performance_monitors`.
- **Rewrote a performance discipline book** → three tools + soak.
- **Changed three systems at once** → no evidence.

## Resources

- JustAMCP `profiling_tools` (`justamcp_profiling_tools.cpp`)

## Related skills

- `blazium-autowork` — soak
- `blazium-mcp` — tool discovery