← Game Development StudioCONTENT HISTORY

Update to Game Development Studio

Snapshot Sep 30, 2026 · 23:15 UTC · version 1.0.2

Collection source: not recorded for this historical snapshot.

WHAT CHANGED · RULE-BASED ANALYSIS

First saved snapshot

No earlier snapshot is available to establish a change.

Compare saved observations

Download comparison JSON
Full technical diff · 0 changed fields
Full snapshot data
{
  "description": "Summarize sealed game-run telemetry, compare baseline and candidate metrics, and execute bounded code-optimization goals with explicit path and iteration limits. Use for measurable performance work after a reproducible adapter scenario exists; not for visual diagnosis without a metric.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 333
    },
    {
      "relative_path": "assets/icon-provenance.json",
      "size_in_bytes": 1230
    },
    {
      "relative_path": "assets/icon.png",
      "size_in_bytes": 1303154
    },
    {
      "relative_path": "references/optimization-loop.md",
      "size_in_bytes": 1851
    }
  ],
  "name": "game-performance-optimization",
  "skill_md_contents": "---\nname: game-performance-optimization\ndescription: Summarize sealed game-run telemetry, compare baseline and candidate metrics, and execute bounded code-optimization goals with explicit path and iteration limits. Use for measurable performance work after a reproducible adapter scenario exists; not for visual diagnosis without a metric.\n---\n\n# Game Performance Optimization\n\nUse `game-dev` run bundles as the measurement boundary. Begin only after a reproducible scenario emits the requested metric with a stable unit.\n\nRead [references/optimization-loop.md](references/optimization-loop.md) for goal requests, commands, and comparison rules.\n\n## Workflow\n\n1. Verify the baseline run, summarize its metrics, and choose one named metric, statistic, unit, direction, and target. Do not optimize a proxy without explaining why it represents the user's outcome.\n2. Confirm scene, seed, workload, build mode, renderer path, hardware, power state, and instrumentation are comparable. Hardware timings require the separately authorized evidence path; arithmetic over unadmitted values is not hardware-performance proof.\n3. Create a dry-run goal with a narrow source-path allowlist and a fixed maximum iteration count. Exclude repository metadata, dependencies, build output, run bundles, and broad project roots.\n4. After explicit confirmation, make one bounded candidate change, run relevant non-performance tests, capture one candidate, verify it, and evaluate it once.\n5. Compare the target metric and inspect correctness signals, raster evidence, errors, and secondary regressions. A numeric improvement does not establish which change caused it.\n6. Stop when the target is met, the iteration budget is exhausted, the measurement becomes incomparable, correctness regresses, or progress requires broader authority.\n\nDo not reuse a candidate run as another iteration, silently widen allowed paths, change the target mid-goal, or turn a bounded goal into an open-ended autonomous loop.\n\n## Evidence boundary\n\nThe summarizer proves deterministic arithmetic over sealed telemetry and profile fields. It does not prove timer quality, GPU synchronization, hardware comparability, statistical significance, or causal attribution. Report the adapter's measurement claims and the harness's admitted evidence separately.\n"
}

SHA-256 of public snapshot: cbbab9e08b7a4fce4bd61b5d581921a678f987f383daf6ba8b1396f6d61a65b3