Game Performance Profiler

!bash "${CLAUDE_SKILL_DIR}/../../hooks/yaml-helper.sh" resolve_config --keys performance.enforce,automation

Resolved above — use as-is. No block → defaults in .claude/docs/config-resolution.md.

Every AskUserQuestion call follows .claude/docs/automation-modes.md (collaborative asks always · guided major-only · autonomous logs and proceeds; automation_always_ask categories always prompt).

Insufficient input — check this before producing any report

If the inputs this skill needs do not exist, the answer is "could not run" — not a filled-in report. Check first, and stop if the check fails.

1. List the inputs this skill reads (data files, prior reports, profiler output, test results, registries, source code).
2. For each, record FOUND or ABSENT — not "assumed present".
3. If any input required for a section is ABSENT, that section is NOT ASSESSED — NO DATA. Do not estimate it, do not infer it from an adjacent artifact, and do not leave a mandated cell to be filled by whoever reads the template next.
4. If every required input is ABSENT, stop and report NOT ASSESSED — NO DATA as the whole verdict, naming what was missing and which skill produces it.

A verdict of NOT ASSESSED is a success. It is the correct, useful answer to "what does the data say?" when there is no data. The failure mode this prevents is specific and has been observed in practice: report templates whose verdict enum had no "could not run" state produced false clean passes — an asset audit returning COMPLIANT on a project with no assets and no standards, and a performance profile reporting ">99% headroom against a 16.67ms budget" with zero profiler data and no budget ever set.

Absence of evidence is never evidence of absence. A scan that finds no matches because there are no files to scan has not verified anything. Say which of the two happened — a reader cannot tell from a green result.

Phase 0: Resolve Budget Enforcement

performance.enforce decides what a budget violation means in this run. It does not change which budgets are measured — performance.target_framerate, frame_budget_ms, draw_call_limit and memory_ceiling_mb are profiled the same way at every level:

Only warn, block and off are recognized. Surface any other value to the user and fall back to warn rather than guessing.

The value is locally overridable (/settings --local performance.enforce=block), so use the resolved block above rather than reading project.yaml — a teammate's stricter local setting is meant to bite on their machine only.

Phase 1: Determine Scope

Read the argument:

• System name → focus profiling on that specific system
• full → run a comprehensive profile across all systems

Phase 2: Load Performance Budgets

Read the committed budgets from config first — they are the project's record of what it agreed to, and design docs are the fallback, not the source:

source "${CLAUDE_PROJECT_DIR:-.}/.claude/hooks/yaml-helper.sh" 2>/dev/null
get_effective_yaml_key performance.target_framerate
get_effective_yaml_key performance.frame_budget_ms
get_effective_yaml_key performance.draw_call_limit
get_effective_yaml_key performance.memory_ceiling_mb

Written as four literal keys rather than a loop over leaf names, deliberately. The dead-settings audit matches the full dotted key, so a loop building performance.$k leaves three of the four spelled nowhere and the audit reports them DEAD while this skill reads them. Spell each key out in full.

Resolve these budgets from project.yaml, not from prose. Phase 0 above states these four budgets "are profiled the same way at every level". Sending the reader to "design docs or CLAUDE.md" instead means a user who set performance.target_framerate: 60 in project.yaml has it ignored by the one skill that profiles against budgets. The keys resolve correctly — this phase has to actually ask for them.

Then fall back to design docs or CLAUDE.md for anything config does not carry:

• Target FPS (e.g., 60fps = 16.67ms frame budget)
• Memory budget (total and per-system)
• Load time targets
• Draw call budgets
• Network bandwidth limits (if multiplayer)

A metric with no committed budget is NOT ASSESSED, not a pass. Do not measure against the template's [16.67ms] placeholder — an unset budget is not a budget that was met, and reporting headroom against a number nobody chose is the exact fabrication this skill's own header warns about.