mirror of
https://github.com/Donchitos/Claude-Code-Game-Studios.git
synced 2026-10-16 01:37:05 +00:00
Release 1.1.0 — one config file, and a process weight you choose
`project.yaml` at the repo root is now the single source of truth for a project's configuration, replacing `production/stage.txt`, `production/review-mode.txt` and `.claude/docs/technical-preferences.md` (all three still read as a fallback; nothing is force-deleted). **`modes.rigor` — one question instead of six.** `minimal`, `standard` or `full` fronts six knobs: `modes.workflow`, `docs.density`, `qa.level`, `modes.story_granularity`, `modes.review_mode` and `team.size`. It defaults to `minimal`, which is a change from 1.0's behaviour: the heavier tier was measured costing several times more to reach working code without producing a better result, and returning nothing when a fresh developer inherited the project. Pin `modes.rigor: standard` to keep 1.0's process level. Also in this release: - `/settings` to view or change any setting, and `project.local.yaml` for per-developer preferences that should not be committed. - `system_overrides` to hold one system to a higher standard than the rest of the project, and `testing.strict` to set per test type whether missing evidence blocks a story or warns. - A story that changes anything the player sees is not closed until the game has been launched, observed, and a screenshot retained in `production/qa/evidence/`. A parse check is not a run. This holds at every rigor level, including `minimal`, where automated tests are waived but the look is not. - The code root is engine-specific and enforced as such: Godot `src/`, Unity `Assets/`, Unreal `Source/<Module>/`. Two of the three will not build a project laid out any other way. - Migration tooling for existing projects: `.claude/scripts/migrate-v1-config.sh` converts a 1.0 layout, non-destructively by default, with a report to review before `--finalize` deletes anything. - Ask-before-write holds regardless of personal automation settings. Upgrading from 1.0 or earlier: see UPGRADING.md. Full list of changes: CHANGELOG.md. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016xvzG3i7pWQg4LjyDwWMXd
This commit is contained in:
Donchitos
co-authored by
Claude Opus 5
Claude Opus 5
parent
984023ddac
commit
d05699707f
@@ -1,13 +1,71 @@
|
||||
---
|
||||
name: perf-profile
|
||||
description: "Structured performance profiling workflow. Identifies bottlenecks, measures against budgets, and generates optimization recommendations with priority rankings."
|
||||
description: "Performance profiling — find bottlenecks, measure against budgets, produce ranked optimization recommendations."
|
||||
argument-hint: "[system-name or 'full']"
|
||||
user-invocable: true
|
||||
agent: performance-analyst
|
||||
allowed-tools: Read, Glob, Grep, Bash
|
||||
model: sonnet
|
||||
---
|
||||
|
||||
!`source "${CLAUDE_PROJECT_DIR:-.}/.claude/hooks/yaml-helper.sh" 2>/dev/null && 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:
|
||||
|
||||
| Value | Effect on this profile's findings |
|
||||
|-------|-----------------------------------|
|
||||
| `warn` (default) | Violations are reported as findings. They do not block; CI logs them without failing. |
|
||||
| `block` | Violations are **blockers**. Say so explicitly in the report — a `block` project treats an over-budget system as release-stopping, and `/gate-check` will FAIL the Polish gate on it. |
|
||||
| `off` | Budgets are informational only. Still report measured values, but do not raise violations as findings or recommendations to fix. |
|
||||
|
||||
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:
|
||||
@@ -19,7 +77,30 @@ Read the argument:
|
||||
|
||||
## Phase 2: Load Performance Budgets
|
||||
|
||||
Check for existing performance targets in design docs or CLAUDE.md:
|
||||
**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:
|
||||
|
||||
```bash
|
||||
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)
|
||||
@@ -27,6 +108,11 @@ Check for existing performance targets in design docs or CLAUDE.md:
|
||||
- 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.
|
||||
|
||||
---
|
||||
|
||||
## Phase 3: Analyze Codebase
|
||||
@@ -62,6 +148,22 @@ Check for existing performance targets in design docs or CLAUDE.md:
|
||||
|
||||
## Phase 4: Generate Profiling Report
|
||||
|
||||
**Write the report to `production/polish/[scope]-report-[date].md`**, asking first
|
||||
per the Collaboration Protocol: *"May I write this profiling report to
|
||||
`production/polish/[scope]-report-[date].md`?"* Create the directory if absent.
|
||||
|
||||
> **Name the destination — do not just render the template into the
|
||||
> conversation.** A profile that lives only in the transcript is gone the moment
|
||||
> the session ends, and no two runs can be compared. `production/polish/`
|
||||
> is the same location `/team-polish` writes, deliberately: a profile taken by
|
||||
> either route belongs in one place, or the comparison this skill exists to enable
|
||||
> cannot be made.
|
||||
>
|
||||
> If a `NOT ASSESSED` section survives into the report, keep it in the written
|
||||
> file. A profile whose gaps are edited out on the way to disk reads, later, as a
|
||||
> complete measurement.
|
||||
|
||||
|
||||
```markdown
|
||||
## Performance Profile: [System or Full]
|
||||
Generated: [Date]
|
||||
|
||||
Reference in New Issue
Block a user