Route Unity and Unreal frame-time complaints into one bottleneck-first profiling brief. Use when the main job is interpreting profiler screenshots, `stat unit` / `stat gpu` output, benchmark-route complaints, or Steam Deck / target-device review packets; choosing the smallest useful next capture; naming one primary bottleneck family; and deciding whether to stay with quick packets, move to an engine-native profiler, or escalate further. Route generic app/service tuning to `performance-optimization`, build/editor/package failures to `game-build-log-triage`, broader game-production coordination to `bmad-gds`, and mixed demo/community feedback to `game-demo-feedback-triage`.
Instrucciones de origen · Vista previa de solo lectura
name
game-performance-profiler
description
Route Unity and Unreal frame-time complaints into one bottleneck-first profiling brief. Use when the main job is interpreting profiler screenshots, `stat unit` / `stat gpu` output, benchmark-route complaints, or Steam Deck / target-device review packets; choosing the smallest useful next capture; naming one primary bottleneck family; and deciding whether to stay with quick packets, move to an engine-native profiler, or escalate further. Route generic app/service tuning to `performance-optimization`, build/editor/package failures to `game-build-log-triage`, broader game-production coordination to `bmad-gds`, and mixed demo/community feedback to `game-demo-feedback-triage`.
allowed-tools
Bash Read Write Edit Glob Grep
compatibility
Best for repositories, bug reports, profiler screenshots, Unity Profiler captures, Unreal Insights traces, stat-command output, benchmark notes, or target-device review packets. Works as a triage and planning workflow, not as an automatic optimizer or build-tuning bot.
Use this skill when the main question is "what packet do we trust, which bottleneck family is most likely, and what is the next capture or review artifact worth producing?"
The job is not to dump generic optimization advice.
The job is to normalize the current packet, choose one operating mode, name one primary bottleneck family, recommend the smallest next capture that can improve confidence, and return one profiling artifact teams can actually act on.
Unity or Unreal projects with low FPS, frame-time spikes, hitches, or performance regressions where the bottleneck is not yet isolated
Profiler screenshots, stat unit / stat gpu output, Unreal Insights traces, overlay captures, route notes, or benchmark complaints that need interpretation
Steam Deck, handheld, mobile, console, VR, or low-spec review requests where packaged-on-device behavior matters more than editor impressions
Requests for a profiling plan, benchmark route, device review packet, CPU/GPU split note, or escalation choice instead of immediate code edits
Mixed performance packets where the next owner is still unclear and the first job is choosing between quick packet, deeper trace, or neighboring game skill
When not to use this skill
The main issue is a Unity/Unreal build, cook, package, editor, or CI failure with no runtime frame-time diagnosis yet → use game-build-log-triage
The main issue is generic web/app/service performance rather than engine-specific runtime capture interpretation → use performance-optimization
The real task is broad milestone or production coordination across bugs, playtest notes, launch goals, and roadmap tradeoffs → use bmad-gds
The packet is mainly playtest/demo/community feedback and the question is fix-first prioritization → use game-demo-feedback-triage
The next move is already a deep implementation change with a confirmed cause; route to the implementation skill after producing the profiling brief
Instructions
Step 1: Frame the packet
Capture the minimum useful context before diagnosing anything.
Record:
engine: Unity | Unreal | Unknown
target: PC | Steam Deck / handheld | console | mobile | VR | low-spec laptop | unknown
Rule: one primary mode, optional secondary note. Do not try to handle every mode at once.
Step 3: Name the likely bottleneck family before proposing fixes
Choose one primary family and an optional secondary family.
Primary families:
cpu-gameplay-scripting
cpu-render-thread-draw-call-pressure
gpu-rendering-shaders-postfx
memory-gc-allocation-churn
loading-streaming-io
physics-animation-simulation
platform-config-thermal-device-specific
unknown-needs-better-capture
Good bottleneck statements:
"The strongest signal points to streaming / IO hitching during traversal, not steady-state GPU load."
"The packet suggests GC/allocation spikes during combat more than rendering saturation."
"This looks device/config-bound because the team is still relying on editor impressions instead of packaged-on-target evidence."
Avoid: "performance is bad overall."
Step 4: Recommend the smallest next capture
Pick the cheapest capture that can materially separate the likely causes.
Typical next captures:
one better Unity Profiler CPU/GPU/Memory packet from a representative player build
one stat unit + stat gpu pair on the exact Unreal repro route
one fixed traversal route with warm-up and repeat counts
one packaged-on-device capture instead of more editor screenshots
one deeper trace (Unreal Insights, GPU Visualizer, Frame Debugger, or external GPU tool) only after the first packet justifies it
Rule: prefer engine-native captures before vendor GPU tools unless the packet is already clearly render-path specific.
Step 5: Make route and device context explicit
If reproducibility is missing, define the smallest repeatable pass.
Specify:
save slot / checkpoint / scene
start point and traversal path
warm-up pass count
measured repeat count or duration
graphics preset / frame cap / power mode
whether the packet is editor-only, packaged-only, or target-device
Do not treat "the market area feels bad" as a durable benchmark route.
Step 6: Return one profiling brief
Always return one concise artifact with this shape:
# Game Performance Profiling Brief## Scope- Mode: ...
- Engine: ...
- Target: ...
- Environment: ...
- Symptom: ...
- Confidence: high | medium | low
## Evidence packet- What exists now: ...
- What's missing: ...
- Editor vs packaged / device note: ...
## Primary bottleneck hypothesis- Bucket: ...
- Why it fits: ...
- Evidence: ...
## Secondary hypothesis- Bucket: ...
- Why it still matters: ...
## Next capture1. ...
2. ...
3. ...
## Benchmark route / device review- Repro route or save: ...
- Repeat / warm-up guidance: ...
- Device or packaged-build checks: ...
## Escalation path- Stay with quick packet | move to engine profiler | escalate to GPU tool
- Why: ...
## Recommended next artifact- Choose one: quick triage packet | profiling plan | benchmark route brief | CPU/GPU split note | memory/GC checklist | streaming hitch checklist | device review brief
## What not to do yet- 1-3 bullets that prevent premature optimization or blind rewrites
Output format
Required qualities:
classify the bottleneck before talking about fixes
separate evidence from hypothesis
recommend the next capture, route, or device review step instead of a giant backlog
make editor-vs-packaged and packet-vs-trace boundaries explicit
keep the report roughly 300-550 words unless the user asks for more
use engine-native terms such as Unity Profiler, Frame Debugger, Unreal Insights, stat unit, stat gpu, frame time, draw-call pressure, GC, streaming, and packaged build
Examples
Example 1: Unity combat spike
Input: "Our Unity game drops from 120 to 45 FPS in combat. We have Profiler screenshots and someone suspects GC spikes. Triage what to look at first."
Expected shape: classify around memory-gc-allocation-churn or cpu-gameplay-scripting, keep the current screenshots as a real packet, recommend the smallest next capture, and avoid jumping to rendering advice first.
Example 2: Unreal open-world traversal hitch
Input: "Unreal is fine indoors but frame time explodes in our open world area. Help me triage whether this is CPU, GPU, streaming, or shaders."
Expected shape: use bottleneck-classification or benchmark-route-plan, recommend stat unit / stat gpu or Unreal Insights as appropriate, and define a reproducible traversal route instead of guessing fixes.
Example 3: Steam Deck review packet
Input: "We need a Steam Deck performance review plan before our demo release. The editor feels rough but we have not profiled the packaged build on device yet."
Expected shape: choose device-review, keep confidence limited, prioritize packaged-on-device evidence, and return a device review brief or benchmark route brief.
Example 4: Route-out to build failure triage
Input: "Our Unreal packaged build crashes during cook and we do not even have runtime numbers yet."
Expected shape: route to game-build-log-triage instead of pretending this is already a profiling problem.
Best practices
Start from the packet the team already has instead of demanding an ideal trace immediately.
Name one primary bottleneck family before discussing optimizations.
Treat reproducibility as part of the diagnosis, not an optional extra.
Prefer packaged-on-device evidence over editor impressions when the release target is a handheld or constrained machine.
Escalate from screenshot/stat packets to engine-native profilers before jumping to GPU-vendor tooling.
Recommend one next artifact, not a giant optimization backlog.
Keep route-outs explicit so game-performance work does not sprawl into build triage, generic app tuning, or production coordination.
