{"id":22060,"plugin_id":"plugins_6aaff56b7f048191894b661584c8e86d","kind":"skill","collection_source":null,"comparison_source":null,"observed_at":"2026-09-30T23:17:07.959Z","digest":"c410705e14c1e6c0af33f310b347bfdebbef4431c183c1ea397a03f0d866919b","against":null,"payload":{"description":"Verify or reconcile canonical game design against code, designated live configuration, synced CSV, builds, logs, and runtime evidence.","included_files":[{"relative_path":"agents/openai.yaml","size_in_bytes":239}],"name":"runtime-audit","skill_md_contents":"---\nname: runtime-audit\ndescription: Verify or reconcile canonical game design against code, designated live configuration, synced CSV, builds, logs, and runtime evidence.\n---\n\n# Runtime Audit Skill\n\nApply the [receiving-project contract](../../references/project-context.md) to resolve canonical sources, project paths, and companion skills.\n\n## Goal\nVerify what the game actually does without silently converting implementation evidence into design intent, and surface actionable drift between canonical design, structured config, release artifacts, and runtime behavior.\n\n## Trigger\nUse for code inspection, config/runtime verification, mapping checks, implementation audits, build/test evidence, or design↔runtime reconciliation. Activate `knowledge-steward` when findings change durable KB knowledge.\n\n## Evidence roles\n- Canonical KB → accepted design intent/rules.\n- Designated live configuration (for example, `BlueprintData` in a project that uses it) → current structured configuration used by the game; proves configured values, not final design/balance approval.\n- Synced repository CSV → release-build artifact expected to match an approved Sheet snapshot; mismatch is a sync observation unless another owner establishes a design defect.\n- The designated repository/code → implemented behavior and schemas.\n- Build/log/test → observed runtime behavior for the tested version/environment.\n\n## Required workflow\n1. Read the available project guide, current state and relevant domain context resolved through the receiving-project contract, then the smallest canonical document set.\n2. State the exact audit question and expected canonical behavior.\n3. Read only the code/config paths required to answer it; avoid broad repository scans unless dependency discovery requires expansion.\n4. Capture exact evidence: file/path, class/method/system, config table/row/field, build/test version, or log reference as applicable.\n5. Classify each finding as `Matches design`, `Config drift`, `Implementation drift`, `Unspecified runtime behavior`, `Design ambiguity`, or `Validation gap`.\n6. Do not silently choose a winner when sources conflict. Apply Source-of-Truth ownership and surface unresolved intent to the owner.\n7. Distinguish a runtime defect from an outdated GDD, provisional config, release-sync issue, or intentionally deferred implementation.\n8. For approved corrections, update the smallest authoritative source(s), then read back and record any remaining validation requirement.\n\n## Audit report minimum\nInclude question, canonical expectation, evidence locations, observed behavior/config, classification, impact, recommended owner/action, confidence/evidence level, and whether the finding changes current `_Context.md` or `PROJECT_STATE.md`.\n\n## Safety against re-derivation\nOnce a verified runtime semantic has been compiled into an active canonical/current-state artifact, do not re-audit it on every task. Reopen code/config when the implementation changed, evidence is stale/uncertain, a conflict appears, or the task explicitly requires verification.\n"},"changes":[],"summary":"First saved snapshot. No earlier version is available for comparison.","summary_kind":"deterministic","summary_metadata":{}}