{"owner":"Donchitos","repo":"Claude-Code-Game-Studios","hasSkills":true,"totalSkillsCount":335,"totalTokensCount":801396,"categories":["subagent-persona","anthropic-skill","claude-rule"],"hasMcp":false,"mcpConfig":null,"found":[".claude/agents/accessibility-specialist.md",".claude/agents/ai-programmer.md",".claude/agents/analytics-engineer.md",".claude/agents/art-director.md",".claude/agents/audio-director.md",".claude/agents/community-manager.md",".claude/agents/creative-director.md",".claude/agents/devops-engineer.md",".claude/agents/economy-designer.md",".claude/agents/engine-programmer.md",".claude/agents/game-designer.md",".claude/agents/gameplay-programmer.md",".claude/agents/godot-csharp-specialist.md",".claude/agents/godot-gdextension-specialist.md",".claude/agents/godot-gdscript-specialist.md",".claude/agents/godot-shader-specialist.md",".claude/agents/godot-specialist.md",".claude/agents/lead-programmer.md",".claude/agents/level-designer.md",".claude/agents/live-ops-designer.md",".claude/agents/localization-lead.md",".claude/agents/narrative-director.md",".claude/agents/network-programmer.md",".claude/agents/performance-analyst.md",".claude/agents/producer.md",".claude/agents/prototyper.md",".claude/agents/qa-lead.md",".claude/agents/qa-tester.md",".claude/agents/release-manager.md",".claude/agents/security-engineer.md",".claude/agents/sound-designer.md",".claude/agents/systems-designer.md",".claude/agents/technical-artist.md",".claude/agents/technical-director.md",".claude/agents/tools-programmer.md",".claude/agents/ue-blueprint-specialist.md",".claude/agents/ue-gas-specialist.md",".claude/agents/ue-replication-specialist.md",".claude/agents/ue-umg-specialist.md",".claude/agents/ui-programmer.md",".claude/agents/unity-addressables-specialist.md",".claude/agents/unity-dots-specialist.md",".claude/agents/unity-shader-specialist.md",".claude/agents/unity-specialist.md",".claude/agents/unity-ui-specialist.md",".claude/agents/unreal-specialist.md",".claude/agents/ux-designer.md",".claude/agents/world-builder.md",".claude/agents/writer.md",".claude/rules/agent-memory.md",".claude/rules/ai-code.md",".claude/rules/data-files.md",".claude/rules/design-docs.md",".claude/rules/engine-code.md",".claude/rules/gameplay-code.md",".claude/rules/narrative.md",".claude/rules/network-code.md",".claude/rules/prototype-code.md",".claude/rules/scene-files.md",".claude/rules/shader-code.md",".claude/rules/skill-authoring.md",".claude/rules/test-standards.md",".claude/rules/ui-code.md",".claude/skills/adopt/SKILL.md",".claude/skills/adopt/references/1-detect.md",".claude/skills/adopt/references/2-format-audit.md",".claude/skills/adopt/references/3-classify.md",".claude/skills/adopt/references/4-migration-plan.md",".claude/skills/adopt/references/5-summary.md",".claude/skills/adopt/references/6-write.md",".claude/skills/adopt/references/7-first-action.md",".claude/skills/architecture-decision/CONTRACT.md",".claude/skills/architecture-decision/SKILL.md",".claude/skills/architecture-decision/references/0-accept.md",".claude/skills/architecture-decision/references/0-retrofit.md",".claude/skills/architecture-decision/references/1-engine-context.md",".claude/skills/architecture-decision/references/3-gather-context.md",".claude/skills/architecture-decision/references/4-decide.md",".claude/skills/architecture-decision/references/5-generate.md",".claude/skills/architecture-review/SKILL.md",".claude/skills/architecture-review/references/1-load.md",".claude/skills/architecture-review/references/2-extract-requirements.md",".claude/skills/architecture-review/references/3-traceability.md",".claude/skills/architecture-review/references/4-conflicts.md",".claude/skills/architecture-review/references/5-engine.md",".claude/skills/architecture-review/references/6-document-coverage.md",".claude/skills/architecture-review/references/7-report.md",".claude/skills/architecture-review/references/8-write.md",".claude/skills/architecture-review/references/9-handoff.md",".claude/skills/art-bible/SKILL.md",".claude/skills/asset-audit/SKILL.md",".claude/skills/asset-spec/SKILL.md",".claude/skills/balance-check/SKILL.md",".claude/skills/brainstorm/SKILL.md",".claude/skills/brainstorm/references/full-concept.md",".claude/skills/bug-report/SKILL.md",".claude/skills/bug-triage/SKILL.md",".claude/skills/changelog/SKILL.md",".claude/skills/code-review/SKILL.md",".claude/skills/consistency-check/SKILL.md",".claude/skills/content-audit/SKILL.md",".claude/skills/create-architecture/SKILL.md",".claude/skills/create-architecture/references/0-load-context.md",".claude/skills/create-architecture/references/1-layers.md",".claude/skills/create-architecture/references/2-module-ownership.md",".claude/skills/create-architecture/references/3-data-flow.md",".claude/skills/create-architecture/references/4-api-boundaries.md",".claude/skills/create-architecture/references/5-adr-audit.md",".claude/skills/create-architecture/references/6-missing-adrs.md",".claude/skills/create-architecture/references/7-write.md",".claude/skills/create-architecture/references/8-handoff.md",".claude/skills/create-control-manifest/SKILL.md",".claude/skills/create-epics/CONTRACT.md",".claude/skills/create-epics/SKILL.md",".claude/skills/create-epics/references/pr-epic-gate.md",".claude/skills/create-stories/CONTRACT.md",".claude/skills/create-stories/SKILL.md",".claude/skills/create-stories/references/qa-lead-gate.md",".claude/skills/day-one-patch/SKILL.md",".claude/skills/design-review/SKILL.md",".claude/skills/design-system/SKILL.md",".claude/skills/design-system/references/1-parse-arguments.md",".claude/skills/design-system/references/2-gather-context.md",".claude/skills/design-system/references/3-file-skeleton.md",".claude/skills/design-system/references/4-section-design.md",".claude/skills/design-system/references/5-post-design.md",".claude/skills/dev-story/CONTRACT.md",".claude/skills/dev-story/SKILL.md",".claude/skills/dev-story/references/engine-checks.md",".claude/skills/dev-story/references/version-mismatch.md",".claude/skills/estimate/SKILL.md",".claude/skills/gate-check/CONTRACT.md",".claude/skills/gate-check/SKILL.md",".claude/skills/gate-check/references/2b-workflow-tier.md",".claude/skills/gate-check/references/3-run-gate-check.md",".claude/skills/gate-check/references/4-assessment.md",".claude/skills/gate-check/references/5-verdict.md",".claude/skills/gate-check/references/6-update-stage.md",".claude/skills/gate-check/references/7-next-steps.md",".claude/skills/gate-check/references/gate-polish.md",".claude/skills/gate-check/references/gate-pre-production.md",".claude/skills/gate-check/references/gate-production.md",".claude/skills/gate-check/references/gate-release.md",".claude/skills/gate-check/references/gate-systems-design.md",".claude/skills/gate-check/references/gate-technical-setup.md",".claude/skills/help/SKILL.md",".claude/skills/hotfix/SKILL.md",".claude/skills/launch-checklist/SKILL.md",".claude/skills/localize/SKILL.md",".claude/skills/map-systems/SKILL.md",".claude/skills/milestone-review/SKILL.md",".claude/skills/onboard/SKILL.md",".claude/skills/patch-notes/SKILL.md",".claude/skills/perf-profile/SKILL.md",".claude/skills/playtest-report/SKILL.md",".claude/skills/project-stage-detect/SKILL.md",".claude/skills/propagate-design-change/SKILL.md",".claude/skills/prototype/SKILL.md",".claude/skills/prototype/references/1-question.md",".claude/skills/prototype/references/2-load-context.md",".claude/skills/prototype/references/3-choose-path.md",".claude/skills/prototype/references/4-plan.md",".claude/skills/prototype/references/5-implement.md",".claude/skills/prototype/references/6-debrief.md",".claude/skills/prototype/references/7-report.md",".claude/skills/prototype/references/8-cd-review.md",".claude/skills/prototype/references/9-summary.md",".claude/skills/prototype/references/spike-mode.md",".claude/skills/qa-plan/SKILL.md",".claude/skills/quick-design/SKILL.md",".claude/skills/regression-suite/SKILL.md",".claude/skills/release-checklist/SKILL.md",".claude/skills/retrospective/SKILL.md",".claude/skills/reverse-document/SKILL.md",".claude/skills/review-all-gdds/SKILL.md",".claude/skills/review-all-gdds/references/1-load.md",".claude/skills/review-all-gdds/references/2-consistency.md",".claude/skills/review-all-gdds/references/3-design-holism.md",".claude/skills/review-all-gdds/references/4-scenarios.md",".claude/skills/review-all-gdds/references/5-report.md",".claude/skills/review-all-gdds/references/6-write.md",".claude/skills/review-all-gdds/references/7-handoff.md",".claude/skills/scope-check/SKILL.md",".claude/skills/security-audit/SKILL.md",".claude/skills/settings/SKILL.md",".claude/skills/setup-engine/SKILL.md",".claude/skills/setup-engine/references/11-upgrade.md",".claude/skills/setup-engine/references/12-output-summary.md",".claude/skills/setup-engine/references/2-guided-mode.md",".claude/skills/setup-engine/references/3-version.md",".claude/skills/setup-engine/references/4-claude-md-stack.md",".claude/skills/setup-engine/references/5-technical-preferences.md",".claude/skills/setup-engine/references/5.5-project-yaml.md",".claude/skills/setup-engine/references/6-knowledge-gap.md",".claude/skills/setup-engine/references/7-reference-docs.md",".claude/skills/setup-engine/references/7.5-scaffold.md",".claude/skills/setup-engine/references/8-verify.md",".claude/skills/setup-engine/references/godot-language-config.md",".claude/skills/skill-improve/SKILL.md",".claude/skills/skill-test/SKILL.md",".claude/skills/smoke-check/SKILL.md",".claude/skills/smoke-check/references/1-detect-setup.md",".claude/skills/smoke-check/references/2-run-tests.md",".claude/skills/smoke-check/references/3-coverage.md",".claude/skills/smoke-check/references/4-manual-checks.md",".claude/skills/smoke-check/references/5-report.md",".claude/skills/smoke-check/references/6-write-gate.md",".claude/skills/soak-test/SKILL.md",".claude/skills/sprint-plan/SKILL.md",".claude/skills/sprint-status/SKILL.md",".claude/skills/start/SKILL.md",".claude/skills/story-done/CONTRACT.md",".claude/skills/story-done/SKILL.md",".claude/skills/story-done/references/review-gates.md",".claude/skills/story-done/references/sprint-next.md",".claude/skills/story-done/references/tech-debt-row.md",".claude/skills/story-readiness/CONTRACT.md",".claude/skills/story-readiness/SKILL.md",".claude/skills/story-readiness/references/qa-lead-gate.md",".claude/skills/team-audio/SKILL.md",".claude/skills/team-combat/SKILL.md",".claude/skills/team-level/SKILL.md",".claude/skills/team-live-ops/SKILL.md",".claude/skills/team-narrative/SKILL.md",".claude/skills/team-polish/SKILL.md",".claude/skills/team-qa/SKILL.md",".claude/skills/team-release/SKILL.md",".claude/skills/team-ui/SKILL.md",".claude/skills/tech-debt/SKILL.md",".claude/skills/test-evidence-review/SKILL.md",".claude/skills/test-flakiness/SKILL.md",".claude/skills/test-helpers/SKILL.md",".claude/skills/test-setup/SKILL.md",".claude/skills/test-setup/references/1-detect.md",".claude/skills/test-setup/references/2-plan.md",".claude/skills/test-setup/references/3-directories.md",".claude/skills/test-setup/references/4-ci.md",".claude/skills/test-setup/references/5-smoke-seed.md",".claude/skills/test-setup/references/6-summary.md",".claude/skills/ux-design/SKILL.md",".claude/skills/ux-design/references/2-gather-context.md",".claude/skills/ux-design/references/3-file-skeleton.md",".claude/skills/ux-design/references/4-authoring.md",".claude/skills/ux-design/references/5-crossref-handoff.md",".claude/skills/ux-design/references/sections-hud.md",".claude/skills/ux-design/references/sections-patterns.md",".claude/skills/ux-design/references/sections-ux-spec.md",".claude/skills/ux-review/SKILL.md",".claude/skills/vertical-slice/SKILL.md","CLAUDE.md","design/CLAUDE.md","docs/CLAUDE.md","docs/engine-reference/unity/plugins/addressables.md","docs/engine-reference/unity/plugins/cinemachine.md","docs/engine-reference/unity/plugins/dots-entities.md","docs/engine-reference/unreal/plugins/common-ui.md","docs/engine-reference/unreal/plugins/gameplay-ability-system.md","docs/engine-reference/unreal/plugins/gameplay-camera-system.md","docs/engine-reference/unreal/plugins/pcg.md","src/CLAUDE.md","studio-tests/CLAUDE.md","studio-tests/skills/analysis/asset-audit.md","studio-tests/skills/analysis/balance-check.md","studio-tests/skills/analysis/code-review.md","studio-tests/skills/analysis/consistency-check.md","studio-tests/skills/analysis/content-audit.md","studio-tests/skills/analysis/estimate.md","studio-tests/skills/analysis/perf-profile.md","studio-tests/skills/analysis/scope-check.md","studio-tests/skills/analysis/security-audit.md","studio-tests/skills/analysis/tech-debt.md","studio-tests/skills/analysis/test-evidence-review.md","studio-tests/skills/analysis/test-flakiness.md","studio-tests/skills/authoring/architecture-decision.md","studio-tests/skills/authoring/art-bible.md","studio-tests/skills/authoring/create-architecture.md","studio-tests/skills/authoring/design-system.md","studio-tests/skills/authoring/quick-design.md","studio-tests/skills/authoring/ux-design.md","studio-tests/skills/authoring/ux-review.md","studio-tests/skills/gate/gate-check.md","studio-tests/skills/pipeline/create-control-manifest.md","studio-tests/skills/pipeline/create-epics.md","studio-tests/skills/pipeline/create-stories.md","studio-tests/skills/pipeline/dev-story.md","studio-tests/skills/pipeline/map-systems.md","studio-tests/skills/pipeline/propagate-design-change.md","studio-tests/skills/pipeline/vertical-slice.md","studio-tests/skills/readiness/story-done.md","studio-tests/skills/readiness/story-readiness.md","studio-tests/skills/review/architecture-review.md","studio-tests/skills/review/design-review.md","studio-tests/skills/review/review-all-gdds.md","studio-tests/skills/sprint/changelog.md","studio-tests/skills/sprint/milestone-review.md","studio-tests/skills/sprint/patch-notes.md","studio-tests/skills/sprint/retrospective.md","studio-tests/skills/sprint/sprint-plan.md","studio-tests/skills/sprint/sprint-status.md","studio-tests/skills/team/team-audio.md","studio-tests/skills/team/team-combat.md","studio-tests/skills/team/team-level.md","studio-tests/skills/team/team-live-ops.md","studio-tests/skills/team/team-narrative.md","studio-tests/skills/team/team-polish.md","studio-tests/skills/team/team-qa.md","studio-tests/skills/team/team-release.md","studio-tests/skills/team/team-ui.md","studio-tests/skills/utility/adopt.md","studio-tests/skills/utility/asset-spec.md","studio-tests/skills/utility/brainstorm.md","studio-tests/skills/utility/bug-report.md","studio-tests/skills/utility/bug-triage.md","studio-tests/skills/utility/day-one-patch.md","studio-tests/skills/utility/help.md","studio-tests/skills/utility/hotfix.md","studio-tests/skills/utility/launch-checklist.md","studio-tests/skills/utility/localize.md","studio-tests/skills/utility/onboard.md","studio-tests/skills/utility/playtest-report.md","studio-tests/skills/utility/project-stage-detect.md","studio-tests/skills/utility/prototype.md","studio-tests/skills/utility/qa-plan.md","studio-tests/skills/utility/regression-suite.md","studio-tests/skills/utility/release-checklist.md","studio-tests/skills/utility/reverse-document.md","studio-tests/skills/utility/settings.md","studio-tests/skills/utility/setup-engine.md","studio-tests/skills/utility/skill-improve.md","studio-tests/skills/utility/skill-test.md","studio-tests/skills/utility/smoke-check.md","studio-tests/skills/utility/soak-test.md","studio-tests/skills/utility/start.md","studio-tests/skills/utility/test-helpers.md","studio-tests/skills/utility/test-setup.md"],"skills":{".claude/agents/accessibility-specialist.md":"",".claude/agents/ai-programmer.md":"",".claude/agents/analytics-engineer.md":"",".claude/agents/art-director.md":"",".claude/agents/audio-director.md":"",".claude/agents/community-manager.md":"",".claude/agents/creative-director.md":"",".claude/agents/devops-engineer.md":"",".claude/agents/economy-designer.md":"",".claude/agents/engine-programmer.md":"",".claude/agents/game-designer.md":"",".claude/agents/gameplay-programmer.md":"",".claude/agents/godot-csharp-specialist.md":"",".claude/agents/godot-gdextension-specialist.md":"",".claude/agents/godot-gdscript-specialist.md":"",".claude/agents/godot-shader-specialist.md":"",".claude/agents/godot-specialist.md":"",".claude/agents/lead-programmer.md":"",".claude/agents/level-designer.md":"",".claude/agents/live-ops-designer.md":"",".claude/agents/localization-lead.md":"",".claude/agents/narrative-director.md":"",".claude/agents/network-programmer.md":"",".claude/agents/performance-analyst.md":"",".claude/agents/producer.md":"",".claude/agents/prototyper.md":"",".claude/agents/qa-lead.md":"",".claude/agents/qa-tester.md":"",".claude/agents/release-manager.md":"",".claude/agents/security-engineer.md":"",".claude/agents/sound-designer.md":"",".claude/agents/systems-designer.md":"",".claude/agents/technical-artist.md":"",".claude/agents/technical-director.md":"",".claude/agents/tools-programmer.md":"",".claude/agents/ue-blueprint-specialist.md":"",".claude/agents/ue-gas-specialist.md":"",".claude/agents/ue-replication-specialist.md":"",".claude/agents/ue-umg-specialist.md":"",".claude/agents/ui-programmer.md":"",".claude/agents/unity-addressables-specialist.md":"",".claude/agents/unity-dots-specialist.md":"",".claude/agents/unity-shader-specialist.md":"",".claude/agents/unity-specialist.md":"",".claude/agents/unity-ui-specialist.md":"",".claude/agents/unreal-specialist.md":"",".claude/agents/ux-designer.md":"",".claude/agents/world-builder.md":"",".claude/agents/writer.md":"",".claude/rules/agent-memory.md":"---\npaths:\n - \".claude/agent-memory/**\"\n---\n\n# Agent Memory Rules\n\n**Agent memory is one of three writes that need no \"May I write?\"** The other two\nare named in `CLAUDE.md`:\n\n- **Appends to `production/session-state/active.md`** — the session checkpoint\n the hooks and the next session rely on. An append, never a rewrite of what is\n already there.\n- **A subagent's new file at the path its orchestrating skill named.** Only a\n new file under `production/`, `docs/` or `tests/`, only at a path the skill's\n prompt names (never one you chose), and only inside a phase the user approved.\n\n`.claude/agent-memory/` is gitignored, per-agent, and never ships. Its exemption\nexists because the memory is the agent's own working notes about how to do its\njob, not a project artifact.\n\nNone of the three extends anywhere else. The Collaboration Protocol still governs\nevery other write under the code root (`src/`, `Assets/` or `Source/`),\n`design/`, `docs/`, `production/` and `assets/`: ask first, naming the path.\nWriting a memory is never a substitute for asking, and a memory must never be\nused to record something the user declined to have written.\n\n## Never record a temporary absence as a durable fact\n\nThis is the failure this file exists to prevent, and this repo is unusually\nexposed to it.\n\n**CCGS ships as a template the user clones *as their game*.** So on day one every\nagent observes the same things — no game code, no GDDs, no engine configured, no\n`tests/performance/` — and every one of those observations is **guaranteed to\nstop being true**. A memory reading *\"this repo is the framework, not a game;\nperf requests have no target\"* is accurate when written and actively harmful two\nweeks later, when it tells a future run to return BLOCKED on a project that now\nhas a build. The agent will not re-derive it; that is what memory is for.\n\nSo:\n\n- **Prefer recording a method over a state.** \"Confirm an engine project and a\n captured profile exist before profiling; return BLOCKED naming what is missing\n rather than estimating\" is durable. \"There is no game here\" is a timestamp.\n- **If you must record a state, state what invalidates it**, on the same line:\n `INVALIDATED WHEN: project.yaml declares an engine, or the code root (src/, Assets/ or Source/) contains game code.`\n A reader with no other context must be able to tell whether the note still\n holds.\n- **Never record absence of a game, of assets, of tests or of config as a\n settled property of the project.** Those are the states CCGS exists to move a\n user out of.\n\n## Disclose the write\n\nSay in your response that you recorded a memory and where. An unmentioned write\nis indistinguishable from no write, and the user cannot correct a note they do\nnot know exists — the same reason a skipped check has to announce itself\n(`.claude/rules/skill-authoring.md`, obligation 3).\n\n## Verify before you trust\n\nA recalled memory reflects what was true when it was written. If it names a file,\na path, a setting or a count, **check that it still holds before acting on it**.\nMemory is a starting point for investigation, never evidence.\n",".claude/rules/ai-code.md":"---\npaths:\n - \"src/ai/**\"\n - \"Assets/**/{AI,Ai,ai}/**/*.cs\"\n - \"Source/**/{AI,Ai,ai}/**/*.{h,cpp}\"\n---\n\n# AI Code Rules\n\n- AI update budget: 2ms per frame maximum — profile to verify\n- All AI parameters must be tunable from data files (behavior tree weights, perception ranges, timers)\n- AI must be debuggable: implement visualization hooks for all AI state (paths, perception cones, decision trees)\n- AI should telegraph intentions — players need time to read and react\n- Prefer utility-based or behavior tree approaches over hard-coded if/else chains\n- Group AI must support formation, flanking, and role assignment from data\n- All AI state machines must log transitions for debugging\n- Never trust AI input from the network without validation\n",".claude/rules/data-files.md":"---\npaths:\n - \"assets/data/**/*.json\"\n - \"Assets/**/{Data,data}/**/*.json\"\n - \"Content/**/{Data,data}/**/*.json\"\n---\n\n# Data File Rules\n\n- All JSON files must be valid JSON — broken JSON blocks the entire build pipeline\n- File naming: lowercase with underscores only, following `[system]_[name].json` pattern\n- Every data file must have a documented schema (either JSON Schema or documented in the corresponding design doc)\n- Numeric values must include comments or companion docs explaining what the numbers mean\n- Use consistent key naming: **`snake_case` for keys within JSON files**, matching\n the `[system]_[name].json` file convention one line above and the engine idiom\n every other standard in this repo uses.\n\n > **On Unity and Unreal this costs you a mapping layer — budget for it rather\n > than changing the keys.** `JsonUtility` binds by *exact field name*, and C#\n > fields are `camelCase` per `naming.variables`, so a snake_case file cannot bind\n > directly to the type that consumes it. Use a private nested DTO whose fields\n > are the wire format and which maps once into your real type, or take a\n > dependency that supports a naming policy (Newtonsoft `SnakeCaseNamingStrategy`,\n > `System.Text.Json` `JsonNamingPolicy`). Do **not** switch the file to camelCase\n > to avoid the DTO: keys are the cross-engine contract. Write the DTO and\n > document it as a wire-format boundary — that is the intended shape.\n- No orphaned data entries — every entry must be referenced by code or another data file\n- Version data files when making breaking schema changes\n- Include sensible defaults for all optional fields\n\n## Examples\n\n**Correct** naming and structure (`combat_enemies.json`):\n\n```json\n{\n \"goblin\": {\n \"base_health\": 50,\n \"base_damage\": 8,\n \"move_speed\": 3.5,\n \"loot_table\": \"loot_goblin_common\"\n },\n \"goblin_chief\": {\n \"base_health\": 150,\n \"base_damage\": 20,\n \"move_speed\": 2.8,\n \"loot_table\": \"loot_goblin_rare\"\n }\n}\n```\n\n**Incorrect** (`EnemyData.json`):\n\n```json\n{\n \"Goblin\": { \"hp\": 50 }\n}\n```\n\nViolations: uppercase filename, uppercase key, no `[system]_[name]` pattern, missing required fields.\n",".claude/rules/design-docs.md":"---\npaths:\n - \"design/gdd/**\"\n---\n\n# Design Document Rules\n\n- The 8 GDD sections are: Overview, Player Fantasy, Detailed Rules, Formulas, Edge Cases, Dependencies, Tuning Knobs, Acceptance Criteria\n- **How many are required depends on `modes.workflow`** — all 8 at `full`, 5 (+ Formulas when the system **defines numeric rules**: rates, curves, thresholds, costs, damage, drop weights — anything a balance pass would tune) at `standard`, none at `minimal` (the design record there is `design/game-brief.md`). Resolve the tier before flagging a section as missing; see `.claude/docs/workflow-modes.md`\n- **The Formulas test is what the system defines, not what it is called.** A system's `Category` in `systems-index.md` is a hint — `Gameplay`, `Economy` and `Progression` almost always qualify — never the test. Do not gate Formulas on a category token: the categories `/map-systems` writes (`Core · Gameplay · Progression · Economy · Persistence · UI · Audio · Narrative · Meta`) do not include `combat` or `AI`, which are example systems *within* `Gameplay`. Every site stating this rule must state the same test.\n- **Section-name alias**: The GDD template and `/design-system` author this section as `## Detailed Design`; the design standard calls it **Detailed Rules**. These are the SAME required section — accept either heading and never rewrite one into the other.\n- Formulas must include variable definitions, expected value ranges, and example calculations\n- Edge cases must explicitly state what happens, not just \"handle gracefully\"\n- Dependencies must be bidirectional — if system A depends on B, B's doc must mention A\n- Tuning knobs must specify safe ranges and what gameplay aspect they affect\n- Acceptance criteria must be testable — a QA tester must be able to verify pass/fail\n- No hand-waving: \"the system should feel good\" is not a valid specification\n- Balance values must link to their source formula or rationale\n- Design documents MUST be written incrementally: create skeleton first, then fill\n each section one at a time with user approval between sections. Write each\n approved section to the file immediately to persist decisions and manage context\n",".claude/rules/engine-code.md":"---\npaths:\n - \"src/core/**\"\n - \"Assets/**/{Core,core}/**/*.cs\"\n - \"Source/**/{Core,core}/**/*.{h,cpp}\"\n---\n\n# Engine Code Rules\n\n- ZERO allocations in hot paths (update loops, rendering, physics) — pre-allocate, pool, reuse\n- All engine APIs must be thread-safe OR explicitly documented as single-thread-only\n- Profile before AND after every optimization — document the measured numbers\n- Engine code must NEVER depend on gameplay code (strict dependency direction: engine <- gameplay)\n- Every public API must have usage examples in its doc comment\n- Changes to public interfaces require a deprecation period and migration guide\n- Use RAII / deterministic cleanup for all resources\n- All engine systems must support graceful degradation\n- Before writing engine API code, consult `docs/engine-reference/` for the current engine version and verify APIs against the reference docs\n\n## Examples\n\n**Correct** (zero-alloc hot path) — Godot:\n\n```gdscript\n# Pre-allocated array reused each frame\nvar _nearby_cache: Array[Node3D] = []\n\nfunc _physics_process(delta: float) -> void:\n _nearby_cache.clear() # Reuse, don't reallocate\n _spatial_grid.query_radius(position, radius, _nearby_cache)\n```\n\nUnity:\n\n```csharp\nprivate readonly Collider[] _nearbyCache = new Collider[64]; // allocated once\n\nvoid FixedUpdate()\n{\n int count = Physics.OverlapSphereNonAlloc(transform.position, radius, _nearbyCache);\n}\n```\n\nUnreal:\n\n```cpp\n// TArray member, reserved once; Reset() keeps the allocation\nvoid UProximityComponent::TickComponent(float DeltaTime, ELevelTick TickType,\n FActorComponentTickFunction* ThisTickFunction)\n{\n NearbyCache.Reset();\n SpatialGrid->QueryRadius(GetComponentLocation(), Radius, NearbyCache);\n}\n```\n\n**Incorrect** (allocating in hot path):\n\n```gdscript\nfunc _physics_process(delta: float) -> void:\n var nearby: Array[Node3D] = [] # VIOLATION: allocates every frame\n nearby = get_tree().get_nodes_in_group(\"enemies\") # VIOLATION: tree query every frame\n```\n",".claude/rules/gameplay-code.md":"---\npaths:\n - \"src/gameplay/**\"\n - \"Assets/**/{Gameplay,gameplay}/**/*.cs\"\n - \"Source/**/{Gameplay,gameplay}/**/*.{h,cpp}\"\n---\n\n# Gameplay Code Rules\n\n- ALL gameplay values MUST come from external config/data files, NEVER hardcoded\n- Use delta time for ALL time-dependent calculations (frame-rate independence)\n- NO direct references to UI code — use events for cross-system communication\n (Godot signals, C# events, Unreal delegates)\n- Every gameplay system must implement a clear interface\n- State machines must have explicit transition tables with documented states\n- Write unit tests for all gameplay logic — separate logic from presentation\n- Document which design doc each feature implements in code comments\n- No static singletons for game state — use dependency injection\n\n## Examples\n\n**Correct** (data-driven) — Godot:\n\n```gdscript\nvar damage: float = config.get_value(\"combat\", \"base_damage\", 10.0)\nvar speed: float = stats_resource.movement_speed * delta\n```\n\nUnity (values from a ScriptableObject):\n\n```csharp\nfloat damage = combatConfig.BaseDamage;\nfloat speed = stats.MovementSpeed * Time.deltaTime;\n```\n\nUnreal (values from a data asset):\n\n```cpp\nconst float Damage = CombatConfig->BaseDamage;\nconst float Speed = Stats->MovementSpeed * DeltaTime;\n```\n\n**Incorrect** (hardcoded):\n\n```gdscript\nvar damage: float = 25.0 # VIOLATION: hardcoded gameplay value\nvar speed: float = 5.0 # VIOLATION: not from config, not using delta\n```\n",".claude/rules/narrative.md":"---\npaths:\n - \"design/narrative/**\"\n---\n\n# Narrative Rules\n\n- All new lore must be cross-referenced against existing lore for contradictions\n- Every lore entry must specify canon level: Established / Provisional / Under Review\n- Character dialogue must match the voice profile defined for that character\n- World rules (what is possible/impossible) must be explicitly documented and consistent\n- Mysteries must have documented \"true answers\" even if players never learn them\n- Faction motivations, relationships, and power structures must be internally logical\n- All narrative text must be localization-ready: no idioms that don't translate, named placeholders for variables\n- No line of dialogue should exceed 120 characters for dialogue box constraints\n",".claude/rules/network-code.md":"---\npaths:\n - \"src/networking/**\"\n - \"Assets/**/{Networking,networking,Network,network}/**/*.cs\"\n - \"Source/**/{Networking,networking,Network,network}/**/*.{h,cpp}\"\n---\n\n# Network Code Rules\n\n- Server is AUTHORITATIVE for all gameplay-critical state — never trust the client\n- All network messages must be versioned for forward/backward compatibility\n- Client predicts locally, reconciles with server — implement rollback for mispredictions\n- Handle disconnection, reconnection, and host migration gracefully\n- Rate-limit all network logging to prevent log flooding\n- All networked values must specify replication strategy: reliable/unreliable, frequency, interpolation\n- Bandwidth budget: define and track per-message-type bandwidth usage\n- Security: validate all incoming packet sizes and field ranges\n",".claude/rules/prototype-code.md":"---\npaths:\n - \"prototypes/**\"\n---\n\n# Prototype Code Standards (Relaxed)\n\nPrototypes are throwaway code for validating ideas. Standards are intentionally\nrelaxed to maximize iteration speed. The goal is learning, not production quality.\n\n## What's Allowed in Prototypes\n- Hardcoded values (no need for data-driven config)\n- Minimal or no doc comments\n- Simple architecture (no dependency injection required)\n- Singletons and global state\n- Copy-pasted code (no need for abstraction)\n- Debug output left in place\n- Placeholder art and audio\n- Quick-and-dirty solutions\n\n## What's Still Required\n- Each prototype lives in its own subdirectory: `prototypes/[name]/`\n- Every prototype MUST have a `README.md` with:\n - What hypothesis is being tested\n - How to run the prototype\n - Current status (in-progress / concluded)\n - Findings (updated when prototype concludes)\n- No production code may reference or import from `prototypes/`\n- Prototypes must not modify files outside `prototypes/`\n- Prototypes must not be deployed or shipped\n\n## When a Prototype Succeeds\nIf a prototype validates a concept and the feature moves to production:\n1. The prototype code is NOT migrated directly — it is rewritten to production standards\n2. The prototype `README.md` findings inform the production design document\n3. The prototype directory is preserved for reference but never extended\n\n## Cleanup\nConcluded prototypes should be archived or deleted after findings are captured.\nNever let prototype code grow into production code through incremental \"cleanup.\"\n",".claude/rules/scene-files.md":"---\npaths:\n - \"**/*.tscn\"\n - \"**/*.tres\"\n - \"**/*.unity\"\n - \"**/*.prefab\"\n - \"Assets/**/*.asset\"\n---\n\n# Scene and Asset File Rules\n\nThe engine's editor writes these files. A hand edit that breaks one can stop a\nscene loading, or drop references without an error. Change them in the editor\nwhen you can.\n\n## Godot (`.tscn`, `.tres`, `.uid`)\n\nWhen you edit the text by hand:\n\n- Never change the `format=` value in the `[gd_scene]` or `[gd_resource]` header.\n- Never reuse an `id`: every `[ext_resource]` and `[sub_resource]` id is unique in its file.\n- Never copy a node block with its `unique_id=` (Godot 4.6+). Drop it from the copy.\n- Never invent a `uid://` value. Leave `uid=` off a new reference and let the\n editor or `godot --headless --path . --import` assign it.\n- Never hand-edit TileMapLayer or GridMap cell data. It is encoded, so change it in the editor.\n- Never edit or delete a `.uid` file, and commit it with its script or shader.\n Godot 4.4+ writes one beside each; when you move or rename the script or\n shader outside the editor, move its `.uid` with it.\n- After a hand edit, run `godot --headless --path . --import` and open or run\n the scene once to confirm it loads without errors.\n\n## Unity (`.unity`, `.prefab`, `.asset`)\n\n- Never hand-edit `.unity`, `.prefab` or `.asset` YAML while a Unity Editor is\n reachable: open on this project, or reachable through its command-line or MCP\n tools. The Editor holds its own copy, and its next save can overwrite or\n conflict with the edit. Make the change through the Editor, or hand the user\n the steps. If you cannot tell whether an Editor is reachable, treat it as reachable.\n- With no Editor reachable, keep every `fileID` and `guid` reference intact,\n never invent a GUID, never edit or delete a `.meta` file, and open the scene\n in the Editor afterwards to confirm it loads.\n",".claude/rules/shader-code.md":"---\npaths:\n - \"assets/shaders/**\"\n - \"**/*.gdshader\"\n - \"Assets/**/*.{shader,hlsl,cginc,compute,shadergraph}\"\n - \"Shaders/**\"\n - \"**/*.{usf,ush}\"\n---\n\n# Shader Code Standards\n\nAll shader files, in every engine, must follow these standards to maintain\nvisual quality, performance, and cross-platform compatibility.\n\n## Naming Conventions\n- File naming: `[type]_[category]_[name].[ext]`\n - `spatial_env_water.gdshader` (Godot)\n - `SG_Env_Water` (Unity Shader Graph)\n - `M_Env_Water` (Unreal Material)\n- Use descriptive names that indicate the material purpose\n- Prefix with the engine's shader type — Godot `spatial_`, `canvas_`, `particles_`,\n `post_`; Unity `SG_` (Shader Graph); Unreal `M_`, `MI_` (instance), `MF_` (function)\n\n## Code Quality\n- All uniforms/parameters must have descriptive names and appropriate hints\n- Group related parameters (Godot: `group_uniforms`, Unity: `[Header]`, Unreal: Category)\n- Comment non-obvious calculations (especially math-heavy sections)\n- No magic numbers — use named constants or documented uniform values\n- Include authorship and purpose comment at the top of each shader file\n\n## Performance Requirements\n- Document the target platform and complexity budget for each shader\n- Use appropriate precision: `half`/`mediump` on mobile where full precision isn't needed\n- Minimize texture samples in fragment shaders\n- Avoid dynamic branching in fragment shaders — use `step()`, `smoothstep()` and\n `mix()` (Godot, GLSL) or `lerp()` (HLSL: Unity, Unreal)\n- No texture reads inside loops\n- Two-pass approach for blur effects (horizontal then vertical)\n\n## Cross-Platform\n- Test shaders on minimum spec target hardware\n- Provide fallback/simplified versions for lower quality tiers\n- Document which render pipeline the shader targets (Forward/Deferred, URP/HDRP, Forward+/Mobile/Compatibility)\n- Do not mix shaders from different render pipelines in the same directory\n\n## Variant Management\n- Minimize shader variants — each variant is a separate compiled shader\n- Document all keywords/variants and their purpose\n- Use feature stripping where possible to reduce build size\n- Log and monitor total variant count per shader\n",".claude/rules/skill-authoring.md":"---\npaths:\n - \".claude/skills/**\"\n - \".claude/agents/**\"\n---\n\n# Skill and Gate Authoring\n\n**A check that cannot report that it did not run is not a check.**\n\nThe same shape recurs across unrelated subsystems, so treat it as the default\nrisk in any check you write, not as an unusual mistake.\n\nThe failure is always the same trade: a step that could not run produces output\nindistinguishable from a step that ran and found nothing. Nobody reading the\noutput can tell which happened, and the permissive reading is the one that gets\nbelieved, because it is the one that lets work proceed.\n\n## The five obligations\n\n### 1. Every gating verdict needs a \"could not assess\" value\n\nIf a skill emits a verdict something else depends on, its vocabulary must include\none — `NOT ASSESSED`, or the local equivalent — and the report must say *which*\nof the reasons applied. A vocabulary of three confident verdicts forces every\nunknown into a claim.\n\n**Rank it deliberately.** It must outrank the pass value: a run that could not\nassess part of its scope has not established that the scope is good. It must\n**not** outrank the failure values: a known problem is more actionable than an\nunknown, and demoting a real failure behind an access problem buries it.\n\n**`NOT ASSESSED` is not a gentler failure verdict.** \"I looked and found nothing\"\nand \"I could not look\" have different fixes — one needs work done, the other\nneeds access granted or an input classified. Collapsing them sends the reader to\nthe wrong fix.\n\n### 2. An absent value may not default to the permissive one\n\nEspecially when **nothing in the framework writes that key**. Before defaulting,\ncheck who sets it: a key with a reader and no writer takes its default branch on\nevery project that ever runs, so that branch is not an edge case — it is the\nbehaviour.\n\nOver-running a check costs minutes. Under-running one ships the category unrun.\n\n### 3. A skipped step announces itself\n\nIn the output, not only in the source. If a phase, category, or agent did not run\n— wrong engine, missing config, unavailable input, a `team.size` that collapses\nthe pipeline — the artifact must say so by name. A silent skip and a successful\none are the same artifact.\n\nA rule enforced in the body and never surfaced in the output is, to the reader,\nidentical to no rule at all.\n\n### 4. Never assert what you cannot source — and wire the gap to the verdict\n\nWhere this repo pins external facts (`docs/engine-reference/**`), do not fill a\ngap from training data. Write the gap down instead: `NOT SOURCEABLE — is\nnot covered by `.\n\n**Flagging alone is not enough.** A named gap that does not reach the verdict is\njust a comment. Wire it: a category with no sourced inputs must force obligation\n1's value, so the gap makes the pass unreachable rather than sitting beside it.\n\nA confidently wrong pattern list is worse than an absent one — it produces a scan\nthat looks thorough, finds nothing, and reads as a pass.\n\n### 5. Gates derive their covered set; they do not enumerate it\n\nAn allowlist pins what was known when it was written and is silent about\neverything added since. Derive the set from what the repo actually contains, so a\nnew skill or agent cannot ship outside coverage by simply not being on a list.\n\n**If the category is not mechanically crisp, say so in the gate and keep the\nlist.** A gate that fires on forty files does not get fixed, it gets muted — and\na muted gate is worse than a narrow one, because it reads as coverage. When you\nkeep a list, record *why* derivation failed and state the obligation to extend it.\n\nTwo further gate rules:\n\n- **Assert something that cannot be true by accident.** A check for the word\n \"unity\" is satisfied by a file path, and case-insensitively by \"community\".\n Assert a distinctive token instead.\n- **A gate you have not watched fail is not a gate.** Break the thing it guards,\n confirm it fails, restore. One mutation per tool invocation — a batch that\n times out leaves the repo holding a broken file, and `trap … EXIT` does not\n survive `SIGTERM`.\n\n## The test to apply\n\nBefore shipping a skill or gate, ask: **if this step silently did not run, what\nwould the output look like?**\n\nIf the answer is \"the same\", it is not finished.\n",".claude/rules/test-standards.md":"---\npaths:\n - \"tests/**\"\n - \"Assets/Tests/**/*.cs\"\n - \"Source/**/Tests/**/*.{h,cpp}\"\n---\n\n# Test Standards\n\n- Test naming follows the engine's language — every name says the scenario and\n the expected result:\n - **Godot (gdUnit4):** file `[system]_[feature]_test.gd`, function\n `test_[scenario]_[expected]`\n - **Unity (NUnit):** class `[System]Tests` in a file of the same name, method\n `[Scenario]_[Expected]` in PascalCase\n - **Unreal (Automation):** class `F[System][Scenario]Test` — one per test:\n each `IMPLEMENT_SIMPLE_AUTOMATION_TEST` defines its class, so a second test\n reusing a name fails to link — test name\n `.[System].[Scenario]` — the project's test command,\n `Automation RunTests .`, runs every test whose name contains\n `.` (a substring match, not a prefix). `.` is the root\n that filter in `commands.test` uses: the project name, or the distinct root\n `/setup-engine` chose when the project's name is also an engine area\n (`Audio`, `Core`, `Input`, …) — name tests under whichever it is\n- Every test must have a clear arrange/act/assert structure\n- Unit tests must not depend on external state (filesystem, network, database)\n- Integration tests must clean up after themselves\n- Performance tests must specify acceptable thresholds and fail if exceeded\n- Test data must be defined in the test or in dedicated fixtures, never shared mutable state\n- Mock external dependencies — tests should be fast and deterministic\n- Every bug fix must have a regression test that would have caught the original bug —\n and **you must watch it fail before you trust it.** Run the new test against the\n unfixed code, confirm it fails, then apply the fix and confirm it passes. A\n regression test that has only ever been seen passing is not known to test anything.\n\n > This is `.claude/rules/skill-authoring.md`'s \"a gate you have not watched fail\n > is not a gate\", applied to tests. It is written out here because stating the\n > *goal* is not enough. A regression test for an iteration-order defect can use\n > a fixture where no cell takes part in two transfers per tick — it then passes\n > against the very bug it was written for, and looks authoritative doing it. The\n > fixture, not the assertion, is what makes it useless, and only running it\n > against the unfixed code exposes that.\n\n## Examples\n\n**Correct** (proper naming + Arrange/Act/Assert) — Godot, gdUnit4:\n\n```gdscript\nextends GdUnitTestSuite\n\nfunc test_take_damage_reduces_health() -> void:\n # Arrange — auto_free: a Node left alive is an orphan (gdUnit4 exit 101)\n var health: HealthComponent = auto_free(HealthComponent.new())\n health.max_health = 100\n health.current_health = 100\n\n # Act\n health.take_damage(25)\n\n # Assert\n assert_int(health.current_health).is_equal(75)\n```\n\nUnity, NUnit (`Assets/Tests/EditMode/HealthTests.cs`):\n\n```csharp\nusing NUnit.Framework;\n\npublic class HealthTests\n{\n [Test]\n public void TakeDamage_ReducesHealth()\n {\n // Arrange\n var health = new Health(maxHealth: 100);\n\n // Act\n health.TakeDamage(25);\n\n // Assert\n Assert.AreEqual(75, health.Current);\n }\n}\n```\n\nUnreal, Automation (`Source//Private/Tests/HealthTest.cpp`):\n\n```cpp\n#include \"Misc/AutomationTest.h\"\n\n#if WITH_DEV_AUTOMATION_TESTS\n\nIMPLEMENT_SIMPLE_AUTOMATION_TEST(FHealthTakeDamageTest, \".Health.TakeDamageReducesHealth\",\n EAutomationTestFlags::EditorContext | EAutomationTestFlags::ProductFilter)\n\nbool FHealthTakeDamageTest::RunTest(const FString& Parameters)\n{\n // Arrange\n FHealthPool Health(100);\n\n // Act\n Health.TakeDamage(25);\n\n // Assert\n TestEqual(TEXT(\"health after 25 damage\"), Health.GetCurrent(), 75);\n return true;\n}\n\n#endif\n```\n\n**Incorrect**:\n\n```gdscript\nfunc test1() -> void: # VIOLATION: no descriptive name\n var h := HealthComponent.new()\n h.take_damage(25) # VIOLATION: no arrange step, no clear assert\n assert_bool(h.current_health < 100).is_true() # VIOLATION: imprecise assertion\n```\n",".claude/rules/ui-code.md":"---\npaths:\n - \"src/ui/**\"\n - \"Assets/**/{UI,Ui,ui}/**/*.cs\"\n - \"Source/**/{UI,Ui,ui}/**/*.{h,cpp}\"\n---\n\n# UI Code Rules\n\n- UI must NEVER own or directly modify game state — display only, use commands/events to request changes\n- All UI text must go through the localization system — no hardcoded user-facing strings\n- Support both keyboard/mouse AND gamepad input for all interactive elements\n- All animations must be skippable and respect user motion/accessibility preferences\n- UI sounds trigger through the audio event system, not directly\n- UI must never block the game thread\n- Scalable text and colorblind modes are mandatory, not optional\n- Test all screens at minimum and maximum supported resolutions\n",".claude/skills/adopt/SKILL.md":"---\nname: adopt\ndescription: \"Brownfield audit — do existing artifacts actually work? Numbered migration plan. Unlike /project-stage-detect, checks compliance not existence.\"\nargument-hint: \"[focus: full | gdds | adrs | stories | infra]\"\nuser-invocable: true\nallowed-tools: Read, Glob, Grep, Write, AskUserQuestion, Bash(bash \"*/.claude/skills/adopt/../../hooks/yaml-helper.sh\" resolve_config *), Bash(bash .claude/scripts/gdd-structure-check.sh *), Bash(bash .claude/scripts/migrate-v1-config.sh --dry-run*)\nmodel: sonnet\n---\n\n!`bash \"${CLAUDE_SKILL_DIR}/../../hooks/yaml-helper.sh\" resolve_config --keys review_mode,automation,automation_always_ask,workflow`\n\nResolved above — use as-is. `/adopt` also inspects `project.yaml` and the legacy\nconfig files directly when reporting and writing migration state; that raw\ninspection is deliberate and separate from the resolved values above.\n\n# Adopt — Brownfield Template Adoption\n\nThis skill audits an existing project's artifacts for **format compliance** with\nthe template's skill pipeline, then produces a prioritised migration plan.\n\n**This is not `/project-stage-detect`.**\n`/project-stage-detect` answers: *what exists?*\n`/adopt` answers: *will what exists actually work with the template's skills?*\n\nA project can have GDDs, ADRs, and stories — and every format-sensitive skill\nwill still fail silently or produce wrong results if those artifacts are in the\nwrong internal format.\n\n**Output:** `docs/adoption-plan-[date].md` — a persistent, checkable migration plan.\n\n**Argument modes:**\n\n**Audit mode:** `$ARGUMENTS` (blank = `full`)\n\n- **No argument / `full`**: Complete audit — all artifact types\n- **`gdds`**: GDD format compliance only\n- **`adrs`**: ADR format compliance only\n- **`stories`**: Story format compliance only\n- **`infra`**: Infrastructure artifact gaps only (registry, manifest, sprint-status, stage.txt)\n\n---\n\n**Automation mode**: Resolve `modes.automation` (`project.local.yaml` →\n`project.yaml` → default `collaborative`). Every `AskUserQuestion` call follows `.claude/docs/automation-modes.md`\n(collaborative asks always · guided major-only · autonomous logs and proceeds;\n`automation_always_ask` categories always prompt).\n\n**`workflow`** (per `.claude/docs/workflow-modes.md`). It scopes the Phase 2 audit and\nPhase 3 severity: `full` audits all doc types at full structure; `standard` audits\nonly the required docs/sections (optional sections are informational, not gaps);\n`minimal` is a `design/game-brief.md` format check — GDDs/ADRs/UX are not expected. See Phase 2.\n\n## Phase 1: Detect Project State\n\n**Read `references/1-detect.md` now and follow it** — this phase's steps are in that file, not here. Read it again if the conversation was compacted or resumed during this phase.\n\n## Phase 2: Format Audit\n\n**Read `references/2-format-audit.md` now and follow it** — this phase's steps are in that file, not here. Read it again if the conversation was compacted or resumed during this phase.\n\n## Phase 3: Classify and Prioritise Gaps\n\n**Read `references/3-classify.md` now and follow it** — this phase's steps are in that file, not here. Read it again if the conversation was compacted or resumed during this phase.\n\n## Phase 4: Build the Migration Plan\n\n**Read `references/4-migration-plan.md` now and follow it** — this phase's steps are in that file, not here. Read it again if the conversation was compacted or resumed during this phase.\n\n## Phase 5: Present Summary and Ask to Write\n\n**Read `references/5-summary.md` now and follow it** — this phase's steps are in that file, not here. Read it again if the conversation was compacted or resumed during this phase.\n\n## Phase 6: Write the Adoption Plan\n\n**Read `references/6-write.md` now and follow it** — this phase's steps are in that file, not here. Read it again if the conversation was compacted or resumed during this phase.\n\n## Phase 7: Offer First Action\n\n**Read `references/7-first-action.md` now and follow it** — this phase's steps are in that file, not here. Read it again if the conversation was compacted or resumed during this phase.\n\n## Collaborative Protocol\n\n**Applies in `collaborative` mode (the default).** For `guided` and\n`autonomous` modes, see `.claude/docs/automation-modes.md` — the rules below\ndescribe what collaborative mode requires, not universal behavior.\n\n1. **Read silently** — complete the full audit before presenting anything\n2. **Show the summary first** — let the user see scope before asking to write\n3. **Ask before writing** — always confirm before creating the adoption plan file\n4. **Offer, don't force** — the plan is advisory; the user decides what to fix and when\n5. **One action at a time** — after handing off the plan, offer one specific next step,\n not a list of six things to do simultaneously\n6. **Never regenerate existing artifacts** — only fill gaps in what exists;\n do not rewrite GDDs, ADRs, or stories that already have content\n",".claude/skills/adopt/references/1-detect.md":"# /adopt — Phase 1: Detect Project State\n\n> Part of `/adopt`. `SKILL.md` names when to read this file; the settings it\n> resolved and the rules under its later headings still apply here.\n\n## Phase 1: Detect Project State\n\nEmit one line before reading: `\"Scanning project artifacts...\"` — this confirms the\nskill is running during the silent read phase.\n\nThen read silently before presenting anything else.\n\n### Existence check\n- `project.stage` in `project.yaml` (fallback `production/stage.txt`) — if either is present, use that value (authoritative phase)\n- `design/gdd/game-concept.md` (or, at the minimal tier, `design/game-brief.md`) — concept exists?\n- `design/gdd/systems-index.md` — systems index exists?\n- Count GDD files: `design/gdd/*.md` (excluding game-concept.md and systems-index.md)\n- Count ADR files: `docs/architecture/adr-*.md`\n- Count story files: `production/epics/**/*.md` (excluding EPIC.md)\n- `project.yaml` (`engine.name`) / `.claude/docs/technical-preferences.md` — engine configured?\n- `docs/engine-reference/` — engine reference docs present?\n- Glob `docs/adoption-plan-*.md` — note the filename of the most recent prior plan if any exist\n\n### Infer phase (if no project.stage / stage.txt)\nUse the same heuristic as `/project-stage-detect`:\n- 10+ source files in the code root → Production\n- Stories in `production/epics/` → Pre-Production\n- ADRs exist → Technical Setup\n- systems-index.md exists → Systems Design\n- game-concept.md (or `design/game-brief.md`) exists → Concept\n- Nothing → Fresh (not a brownfield project — suggest `/start`)\n\nIf the project appears fresh (no artifacts at all), use `AskUserQuestion`:\n- \"This looks like a fresh project — no existing artifacts found. `/adopt` is for\n projects with work to migrate. What would you like to do?\"\n - \"Run `/start` — begin guided first-time onboarding\"\n - \"My artifacts are in a non-standard location — help me find them\"\n - \"Cancel\"\n\n`/start` and Cancel end this skill: say which, and stop.\n\n**If they pick \"help me find them\"**, search before asking anything else:\n\n1. Search the folder they named, if they named one; otherwise the whole\n project, skipping `.claude/`, `.git/`, `docs/engine-reference/`,\n `studio-tests/`, `node_modules/` and the engine's build and\n cache folders.\n2. Glob `**/*.md` there, then Grep the matches for the headings each artifact\n carries: a GDD has `## Overview` with `## Detailed Rules` or\n `## Detailed Design`; an ADR `## Status` with `## Decision`; a story\n `## Acceptance Criteria` with a `Status` line; a concept doc\n `## Elevator Pitch` or `## Game Pillars`; a brief `## Core loop` with\n `## MVP`.\n3. Show what was found, grouped by type, each with the place every skill reads\n it from: GDD → `design/gdd/[name].md`; ADR →\n `docs/architecture/adr-NNNN-[name].md`; story →\n `production/epics/[epic]/story-NNN-[name].md`; concept →\n `design/gdd/game-concept.md`; brief → `design/game-brief.md`. If nothing\n matched, say so, name the folders and headings searched, and offer `/start`.\n4. Ask before moving anything — a move takes the file away from its old path,\n so it is a `file_deletions` decision: \"May I move these [N] files to the\n standard folders?\" — `[A] Move them all` / `[B] Let me pick which` /\n `[C] Don't move them — I'll do it myself`. Move with `git mv` in a git\n repository (the file's history follows it), plain `mv` otherwise. Never\n overwrite a file already at the target: name the clash and skip that file.\n Files are moved, never edited.\n5. After the moves, run Phase 1 again from the top, so the audit reads the files\n where every other skill will. With [C], print the moves as a list and stop.\n\nReport: \"Detected phase: [phase]. Found: [N] GDDs, [M] ADRs, [P] stories.\"\n\n---\n",".claude/skills/adopt/references/2-format-audit.md":"# /adopt — Phase 2: Format Audit\n\n> Part of `/adopt`. `SKILL.md` names when to read this file; the settings it\n> resolved and the rules under its later headings still apply here.\n\n## Phase 2: Format Audit\n\n**In this file:**\n\n- 2a: GDD Format Audit\n- 2b: ADR Format Audit\n- 2c: systems-index.md Format Audit\n- 2d: Story Format Audit\n- 2e: Infrastructure Audit\n- 2f: Project Config Audit\n- 2g: v1.0 Migration Check\n\nFor each artifact type in scope (based on argument mode **and the resolved\nworkflow tier**), check not just that the file exists but that it contains the\ninternal structure the template requires. At `minimal`, scope the audit to\n`design/game-brief.md` — do not audit for GDDs, ADRs, or UX specs (they are not expected).\nSteps 2e (the Engine reference row only), 2f (project config) and 2g (v1.0\nmigration check) run at every tier.\n\n### 2a: GDD Format Audit\n\n**Gather section presence deterministically — do not read the GDDs to count\nheadings.** For each GDD discovered in Phase 1, pass its path explicitly to the\nstructure-check script:\n\n```\nBash: bash .claude/scripts/gdd-structure-check.sh [path-to-gdd]\n```\n\n**Pass paths one at a time; do not invoke it bare.** The no-argument form sweeps\n`design/gdd/` only, and a brownfield project's GDDs are not guaranteed to live\nthere — pass whatever paths Phase 1 found. The script prints a `PRESENT:` list\nand, when applicable, an `ABSENT:` list per file. It reports **presence only**\nand makes no REQUIRED/ADVISORY judgment (that is the tier logic below), and it\nalready accepts `## Detailed Design` as satisfying the `Detailed Rules`\nrequirement, so do not flag that alias as missing.\n\nIf the script prints `Not found:` for a path or errors, that is a **discovery\nfailure, not a format gap** — report it as \"could not audit [path]\" and do not\ncount it as a missing-sections finding.\n\n**Then apply the workflow tier** resolved above to each file's PRESENT/ABSENT\nlists. Which sections are **required** (a miss = gap) vs **advisory** (a miss =\ninformational):\n- **`full`** — all 8 sections are required.\n- **`standard`** — the 5 required (Overview, Detailed Rules, Edge Cases,\n Dependencies, Acceptance Criteria) + Formulas for any system that defines\n numeric rules (rates, curves, thresholds, costs — the system's `Category` is a\n hint, not the test); Player Fantasy and Tuning Knobs are advisory.\n- **`minimal`** — GDDs are not expected; audit `design/game-brief.md` instead,\n against `.claude/docs/templates/game-brief.md`: each of the six required fields\n present and not a placeholder; the three one-liners advisory. Any GDD that\n does exist is checked at the `standard` bar, advisorily.\n\nThe script's 8 canonical labels are: Overview, Player Fantasy, Detailed Rules,\nFormulas, Edge Cases, Dependencies, Tuning Knobs, Acceptance Criteria.\n\nA section reported PRESENT can still be an empty heading. For each GDD, also\nrecord with a targeted grep (not a full read):\n- Placeholder-only sections — the script's `PLACEHOLDER:` line names the\n present sections that hold only `[To be designed]` or nothing; a\n single-line stub body is the same in effect, so spot-check short sections.\n- The `**Status**:` header field — `Grep pattern=\"^>?[[:space:]]*\\*\\*Status\\*\\*:\"`.\n Valid values: `Draft`, `In Design`, `Designed`, `In Review`, `Approved`,\n `Implemented`, `Needs Revision`.\n\n> **The `>?` is load-bearing, and so are `Draft`/`Implemented`.** Both emitters\n> write this field inside a blockquote — `.claude/docs/templates/game-design-document.md`\n> and `/design-system` produce `> **Status**: …` — so an anchor of\n> `^\\*\\*Status\\*\\*:` matches nothing and reports *every* template-compliant GDD\n> as missing its Status. The template's own value list offers `Draft` and\n> `Implemented`, so both must count as valid.\n\n### 2b: ADR Format Audit\n\nFor each ADR file found, check for these critical sections:\n\n| Section | Impact if missing |\n|---|---|\n| `## Status` | **BLOCKING** — `/story-readiness` ADR status check silently passes everything |\n| `## ADR Dependencies` | HIGH — dependency ordering in `/architecture-review` breaks |\n| `## Engine Compatibility` | HIGH — post-cutoff API risk is unknown |\n| `## GDD Requirements Addressed` | MEDIUM — traceability matrix loses coverage |\n| `## Performance Implications` | LOW — not pipeline-critical |\n\nFor each ADR, record: which sections present, which missing, current Status value\nif the Status section exists.\n\n### 2c: systems-index.md Format Audit\n\nIf `design/gdd/systems-index.md` exists:\n\n1. **Parenthetical status values** — Grep for any Status cell containing\n parentheses: `\"Needs Revision (\"`, `\"In Progress (\"`, etc.\n These break exact-string matching in `/gate-check`, `/create-stories`,\n and `/architecture-review`. **BLOCKING.**\n\n2. **Valid status values** — check that Status column values are only from:\n `Not Started`, `In Progress`, `In Review`, `Designed`, `Approved`, `Needs Revision`\n Flag any unrecognised values.\n\n3. **Column structure** — check that the table has at minimum: System name,\n Layer, Priority, Status columns. Missing columns degrade skill functionality.\n\n### 2d: Story Format Audit\n\nFor each story file found:\n\n- **`Manifest Version:` field** — present in story header? (LOW — auto-passes if absent)\n- **TR-ID reference** — does story contain `TR-[a-z]+-[0-9]+` pattern? (MEDIUM — no staleness tracking)\n- **ADR reference** — does story reference at least one ADR? (check for `ADR-` pattern)\n- **Status field** — present and readable?\n- **Acceptance criteria** — does the story have a checkbox list (`- [ ]`)?\n\n### 2e: Infrastructure Audit\n\n| Artifact | Path | Impact if missing |\n|---|---|---|\n| TR registry | `docs/architecture/tr-registry.yaml` | HIGH — no stable requirement IDs |\n| Control manifest | `docs/architecture/control-manifest.md` | HIGH — no layer rules for stories |\n| Manifest version stamp | In manifest header: `Manifest Version:` | MEDIUM — staleness checks blind |\n| Sprint status | `production/sprint-status.yaml` | MEDIUM — `/sprint-status` falls back to markdown |\n| Stage file | `project.stage` in `project.yaml` (fallback `production/stage.txt`) | MEDIUM — phase auto-detect unreliable |\n| Engine reference | `docs/engine-reference/[engine]/VERSION.md` | HIGH — ADR engine checks blind |\n| Architecture traceability | `docs/architecture/requirements-traceability.md` | MEDIUM — no persistent matrix |\n\nAt `workflow: minimal` only the Engine reference row applies. The TR registry,\ncontrol manifest and its version stamp, sprint status, stage file and\ntraceability matrix are not on the minimal path, so their absence is not a gap.\n\n### 2f: Project Config Audit\n\nRead `project.yaml` (the primary config store) and `.claude/docs/technical-preferences.md` (legacy mirror). A setting counts as configured if EITHER source has a real value (in technical-preferences.md, `[TO BE CONFIGURED]` means unconfigured):\n- `engine.name`/`version`/`language`/`rendering`/`physics` (else the Engine/Language/Rendering/Physics fields) → HIGH if unconfigured in both (ADR skills fail)\n- `naming.*` (else Naming conventions) → MEDIUM\n- `performance.*` (else Performance budgets) → MEDIUM\n- Forbidden Patterns, Allowed Libraries (technical-preferences.md only — not migrated to project.yaml) → LOW (starts empty by design)\n\n### 2g: v1.0 Migration Check\n\nA project is a **v1.0 project needing migration** when `project.yaml` does NOT\nexist at the repo root AND at least one legacy file does: `production/stage.txt`,\n`production/review-mode.txt`, or a `.claude/docs/technical-preferences.md` with\nreal values.\n\n\"Real values\" means one of the keys the converter actually migrates — Engine,\nLanguage, Rendering, Physics, the naming, platform and performance fields,\nFramework, or the specialists. Not merely \"some bullet is filled in\": the\nshipped template ships one prose default (`- **Required Tests**: …`) that is\nnever migrated, and counting it would make every fresh clone read as a v1.0\nproject.\n\nDo not hand-migrate. Run the converter, which is deterministic and covered by\nthe framework's own test suite:\n\n```bash\nbash .claude/scripts/migrate-v1-config.sh --dry-run\n```\n\nThe dry run writes nothing; record what it lists for the report. Do not run the\nconverter during the audit — Phase 2 reads silently. The migration is\nclassified BLOCKING in Phase 3, heads the plan, and **Phase 7 offers it as the\nfirst action**: report what the dry run listed, then ask \"May I run the\nconverter? It writes `project.yaml` and `production/migration-report.md`.\" If\nthe user approves, run it without `--dry-run`. It\nwrites `project.yaml` plus `production/migration-report.md` and **deletes\nnothing** — the whole operation stays reversible with `git checkout`.\n\nThen tell the user to read `production/migration-report.md` before running:\n\n```bash\nbash .claude/scripts/migrate-v1-config.sh --finalize\n```\n\n`--finalize` deletes a legacy file only after proving its value is present in\n`project.yaml`; on mismatch it deletes nothing and exits 4. It never deletes\n`technical-preferences.md`, which still holds Forbidden Patterns and Allowed\nLibraries.\n\n**If the script refuses with exit 3**, do not work around it. Exit 3 means one\nof two things, and the message says which:\n\n- **the values DISAGREE** — two sources of truth and no way to know which the\n user edited last. Surface it and let them decide.\n- **a `production/migration-report.md` is already present** — a migration ran\n here, so these are post-migration leftovers and `--finalize` is the next step,\n not a second `migrate`.\n\nBoth files merely *existing* is not exit 3 and must not be reported as a\nconflict: `/start` writes `production/stage.txt` on every new v1.1 project as a\nmirror, so agreement is the normal state. The script says\n`the legacy files mirror it (values agree)` and exits 0 for that.\n\nClassify as **BLOCKING** in Phase 3: until migration runs, every skill reads\nconfig through the legacy fallback chain, and v1.1 settings are unavailable.\n\n---\n",".claude/skills/adopt/references/3-classify.md":"# /adopt — Phase 3: Classify and Prioritise Gaps\n\n> Part of `/adopt`. `SKILL.md` names when to read this file; the settings it\n> resolved and the rules under its later headings still apply here.\n\n## Phase 3: Classify and Prioritise Gaps\n\nOrganise every gap found across all audits into four severity tiers:\n\n**BLOCKING** — Will cause template skills to silently produce wrong results *right now*.\nExamples: ADR missing Status field, systems-index parenthetical status values,\nengine not configured when ADRs exist.\n\n**HIGH** — Will cause stories to be generated with missing safety checks, or\ninfrastructure bootstrapping will fail.\nExamples: ADRs missing Engine Compatibility, GDDs missing Acceptance Criteria\n(stories can't be generated from them), tr-registry.yaml missing.\n\n**MEDIUM** — Degrades quality and pipeline tracking but does not break functionality.\nExamples: GDDs missing Tuning Knobs or Formulas sections, stories missing TR-IDs,\nsprint-status.yaml missing.\n\n**LOW** — Retroactive improvements that are nice-to-have but not urgent.\nExamples: Stories missing Manifest Version stamps, GDDs missing Open Questions section.\n\nCount totals per tier. If zero BLOCKING and zero HIGH gaps: report that the project\nis template-compatible and only advisory improvements remain.\n\n---\n",".claude/skills/adopt/references/4-migration-plan.md":"# /adopt — Phase 4: Build the Migration Plan\n\n> Part of `/adopt`. `SKILL.md` names when to read this file; the settings it\n> resolved and the rules under its later headings still apply here.\n\n## Phase 4: Build the Migration Plan\n\nCompose a numbered, ordered action plan. Ordering rules:\n1. BLOCKING gaps first (must fix before any pipeline skill runs reliably)\n2. HIGH gaps next, infrastructure before GDD/ADR content (bootstrapping needs correct formats)\n3. MEDIUM gaps ordered: GDD gaps before ADR gaps before story gaps (stories depend on GDDs and ADRs)\n4. LOW gaps last\n\nFor each gap, produce a plan entry with:\n- A clear problem statement (one sentence, no jargon)\n- The exact command to fix it, if a skill handles it\n- Manual steps if it requires direct editing\n- A time estimate (rough: 5 min / 30 min / 1 session)\n- A checkbox `- [ ]` for tracking\n\n**Special case — systems-index parenthetical status values:**\nThis is always the first item if present. Show the exact values that need changing\nand the exact replacement text. Offer to fix this immediately before writing the plan.\n\n**Special case — ADRs missing Status field:**\nFor each affected ADR, the fix is:\n`/architecture-decision retrofit docs/architecture/adr-[NNNN]-[slug].md`\nList each ADR as a separate checkable item.\n\n**Special case — GDDs missing sections:**\nFor each affected GDD, list which sections are missing and the fix:\n`/design-system retrofit design/gdd/[filename].md`\n\n**Infrastructure bootstrap ordering** — always present in this sequence:\n1. Fix ADR formats first (registry depends on reading ADR Status fields)\n2. Run `/architecture-review` → bootstraps `tr-registry.yaml`\n3. Run `/create-control-manifest` → creates manifest with version stamp\n4. Run `/sprint-plan update` → creates `sprint-status.yaml`\n5. Run `/gate-check [phase]` (the gate into the phase the project is in; at Concept there is none — Concept is the default stage, nothing to run) → writes `project.stage` in `project.yaml` (and legacy `stage.txt`) authoritatively\n\n**At `workflow: minimal` the plan prescribes none of this sequence.** None of it\nis on the minimal path: ADRs are not expected, the brief's build order is the\nplan (no `/sprint-plan`), and nothing there runs `/gate-check`. The plan's\nStep 3 says so in one line and names the path's next step instead —\n`/create-stories` when no stories exist, else `/dev-story`.\n\n**Existing stories** — note explicitly:\n> \"Existing stories continue to work with all template skills — all new format\n> checks auto-pass when the fields are absent. They won't benefit from TR-ID\n> staleness tracking or manifest version checks until they're regenerated. This\n> is intentional: do not regenerate stories that are already in progress.\"\n\n---\n",".claude/skills/adopt/references/5-summary.md":"# /adopt — Phase 5: Present Summary and Ask to Write\n\n> Part of `/adopt`. `SKILL.md` names when to read this file; the settings it\n> resolved and the rules under its later headings still apply here.\n\n## Phase 5: Present Summary and Ask to Write\n\nPresent a compact summary before writing:\n\n```\n## Adoption Audit Summary\nPhase detected: [phase]\nEngine: [configured / NOT CONFIGURED]\nGDDs audited: [N] ([X] fully compliant, [Y] with gaps)\nADRs audited: [N] ([X] fully compliant, [Y] with gaps)\nStories audited: [N]\n\nGap counts:\n BLOCKING: [N] — template skills will malfunction without these fixes\n HIGH: [N] — unsafe to run /create-stories or /story-readiness\n MEDIUM: [N] — quality degradation\n LOW: [N] — optional improvements\n\nEstimated remediation: [X blocking items × ~Y min each = roughly Z hours]\n```\n\nBefore asking to write, show a **Gap Preview**:\n- List every BLOCKING gap as a one-line bullet describing the actual problem\n (e.g. `systems-index.md: 3 rows have parenthetical status values`,\n `adr-0002.md: missing ## Status section`). No counts — show the actual items.\n- Show HIGH / MEDIUM / LOW as counts only (e.g. `HIGH: 4, MEDIUM: 2, LOW: 1`).\n\nThis gives the user enough context to judge scope before committing to writing the file.\n\nIf a prior adoption plan was detected in Phase 1, add a note:\n> \"A previous plan exists at `docs/adoption-plan-[prior-date].md`. The new plan will\n> reflect current project state — it does not diff against the prior run.\"\n\nUse `AskUserQuestion`:\n- \"Ready to write the migration plan?\"\n - \"Yes — write `docs/adoption-plan-[date].md`\"\n - \"Show me the full plan preview first (don't write yet)\"\n - \"Cancel — I'll handle migration manually\"\n\nIf the user picks \"Show me the full plan preview\", output the complete plan as a\nfenced markdown block. Then ask again with the same three options.\n\n---\n",".claude/skills/adopt/references/6-write.md":"# /adopt — Phases 6 and 6b: Write the Adoption Plan and Report Review Mode\n\n> Part of `/adopt`. `SKILL.md` names when to read this file; the settings it\n> resolved and the rules under its later headings still apply here.\n\n## Phase 6: Write the Adoption Plan\n\n**In this file:**\n\n- Phase 6: the adoption plan template, then the write\n- Phase 6b: Report Review Mode\n\nIf approved, write `docs/adoption-plan-[date].md` with this structure:\n\n```markdown\n# Adoption Plan\n\n> **Generated**: [date]\n> **Project phase**: [phase]\n> **Engine**: [name + version, or \"Not configured\"]\n> **Template version**: v1.0+\n\nWork through these steps in order. Check off each item as you complete it.\nRe-run `/adopt` anytime to check remaining gaps.\n\n---\n\n## Step 1: Fix Blocking Gaps\n\n[One sub-section per blocking gap with problem, fix command, time estimate, checkbox]\n\n---\n\n## Step 2: Fix High-Priority Gaps\n\n[One sub-section per high gap]\n\n---\n\n## Step 3: Bootstrap Infrastructure\n\n[At `workflow: minimal`, replace 3a–3d with one line: \"Not on the minimal path —\nthe brief's build order is the plan. Next: `/create-stories` (or `/dev-story`\nonce stories exist).\"]\n\n### 3a. Register existing requirements (creates tr-registry.yaml)\nRun `/architecture-review` — even if ADRs already exist, this run bootstraps\nthe TR registry from your existing GDDs and ADRs.\n**Time**: 1 session (review can be long for large codebases)\n- [ ] tr-registry.yaml created\n\n### 3b. Create control manifest\nRun `/create-control-manifest`\n**Time**: 30 min\n- [ ] docs/architecture/control-manifest.md created\n\n### 3c. Create sprint tracking file\nRun `/sprint-plan update`\n**Time**: 5 min (if sprint plan already exists as markdown)\n- [ ] production/sprint-status.yaml created\n\n### 3d. Set authoritative project stage\nRun `/gate-check [current-phase]` (the gate into the phase the project is in;\nat Concept there is none — Concept is the default stage, nothing to run)\n**Time**: 5 min\n- [ ] `project.stage` in `project.yaml` written (legacy `production/stage.txt` also updated)\n\n---\n\n## Step 4: Medium-Priority Gaps\n\n[One sub-section per medium gap]\n\n---\n\n## Step 5: Optional Improvements\n\n[One sub-section per low gap]\n\n---\n\n## What to Expect from Existing Stories\n\nExisting stories continue to work with all template skills. New format checks\n(TR-ID validation, manifest version staleness) auto-pass when the fields are\nabsent — so nothing breaks. They won't benefit from staleness tracking until\nregenerated. Do not regenerate stories that are in progress or done.\n\n---\n\n## Re-run\n\nRun `/adopt` again after completing Step 3 to verify all blocking and high gaps\nare resolved. The new run will reflect the current state of the project.\n```\n\n---\n\n## Phase 6b: Report Review Mode\n\n**Do not write a review mode.** `modes.review_mode` is one of the six knobs\n`modes.rigor` fronts: pinning it in `project.yaml` shadows the rigor expansion, and\nthe legacy `production/review-mode.txt` sits *above* that expansion in resolution,\nso either write would freeze director-review depth for good — the rule `/start`\nand `project.yaml`'s header comment both state.\n\nReport the value the bootstrap above resolved instead: \"Review mode resolves to\n`[value]` — from `modes.rigor`, unless something pins it.\" If the user wants a\ndifferent depth, point them to changing `modes.rigor`, or to pinning it on purpose\nwith `/settings --local modes.review_mode=` (a personal override in\n`project.local.yaml`).\n\n---\n",".claude/skills/adopt/references/7-first-action.md":"# /adopt — Phase 7: Offer First Action\n\n> Part of `/adopt`. `SKILL.md` names when to read this file; the settings it\n> resolved and the rules under its later headings still apply here.\n\n## Phase 7: Offer First Action\n\nAfter writing the plan, don't stop there. Pick the single highest-priority gap\nand offer to handle it immediately using `AskUserQuestion`. Choose the first\nbranch that applies:\n\n**If Phase 2g found a v1.0 project needing migration:** offer the converter run\ndescribed there — report what the dry run listed and ask \"May I run the\nconverter? It writes `project.yaml` and `production/migration-report.md`.\"\nEvery other fix reads config through it, so it comes first.\n\n**If there are parenthetical status values in systems-index.md:**\nUse `AskUserQuestion`:\n- \"The most urgent fix is `systems-index.md` — [N] rows have parenthetical status\n values (e.g. `Needs Revision (see notes)`) that break /gate-check,\n /create-stories, and /architecture-review right now. I can fix these in-place.\"\n - \"Fix it now — edit systems-index.md\"\n - \"I'll fix it myself\"\n - \"Done — leave me with the plan\"\n\n**If ADRs are missing `## Status` (and no parenthetical issue):**\nUse `AskUserQuestion`:\n- \"The most urgent fix is adding `## Status` to [N] ADR(s): [list filenames].\n Without it, /story-readiness silently passes all ADR checks. Start with\n [first affected filename]?\"\n - \"Yes — retrofit [first affected filename] now\"\n - \"Retrofit all [N] ADRs one by one\"\n - \"I'll handle ADRs myself\"\n\n**If GDDs are missing Acceptance Criteria (and no blocking issues above):**\nUse `AskUserQuestion`:\n- \"The most urgent gap is missing Acceptance Criteria in [N] GDD(s):\n [list filenames]. Without them, /create-stories can't generate stories.\n Start with [highest-priority GDD filename]?\"\n - \"Yes — add Acceptance Criteria to [GDD filename] now\"\n - \"Do all [N] GDDs one by one\"\n - \"I'll handle GDDs myself\"\n\n**Otherwise, if any BLOCKING or HIGH gap remains** (one no branch above names —\ne.g. a missing TR registry):\nUse `AskUserQuestion`:\n- \"The most urgent remaining gap is [first BLOCKING or HIGH item in the plan] —\n [one line on what it breaks]. Start on it now?\"\n - \"Yes — start on [item]\"\n - \"Show me that plan item first\"\n - \"Done — leave me with the plan\"\n\n**If no BLOCKING or HIGH gaps exist:**\nUse `AskUserQuestion`:\n- \"No blocking gaps — this project is template-compatible. What next?\"\n - \"Walk me through the medium-priority improvements\"\n - \"Run /project-stage-detect for a broader health check\"\n - \"Done — I'll work through the plan at my own pace\"\n\n> **Adoption plan saved to `docs/adoption-plan-[date].md`.** Re-run `/adopt` at any time to re-check remaining gaps as you complete them.\n\n---\n",".claude/skills/architecture-decision/CONTRACT.md":"# /architecture-decision — Handoff Contract\n\n## Role in Pipeline\nAuthors a new Architecture Decision Record (ADR) by guiding a collaborative design session, cross-referencing the engine reference library and existing architectural stances, and writing a fully-structured ADR file to `docs/architecture/` as `Proposed`. Its `accept` mode is the only route to `Accepted`, and acceptance is what unblocks the stories and epics that depend on the decision.\n\nTwo checks inside the run emit `NOT ASSESSED` rather than passing silently, and\na reader of the resulting ADR should expect them: **engine validation** when no\nengine is configured (`engine.name` unset and no legacy fallback), and **GDD\nsync** when the referenced design docs cannot be read. A skipped check that says\nnothing is indistinguishable from a check that passed.\n\n## Inputs Required\n\n### Files That Must Exist\n| File | Required Fields / Sections | Read-Only? |\n|------|---------------------------|-----------|\n| `docs/engine-reference/[engine]/VERSION.md` | Engine name + version, LLM knowledge cutoff date, post-cutoff risk levels per domain | Yes |\n| `docs/engine-reference/[engine]/modules/[domain].md` | Domain-specific API reference (read if exists for the decision's domain) | Yes |\n| `docs/engine-reference/[engine]/breaking-changes.md` | Post-cutoff breaking changes in the relevant domain | Yes |\n| `docs/engine-reference/[engine]/deprecated-apis.md` | APIs that must not be referenced in the new ADR | Yes |\n| `docs/registry/architecture.yaml` | All existing architectural stances (state ownership, interface contracts, forbidden patterns, performance budgets) — checked for conflicts before the design begins | Yes |\n| `docs/architecture/` (existing ADRs) | Scanned to determine the next sequential ADR number | Yes |\n| `design/gdd/[system].md` (GDDs relevant to the decision) | Specific rules, formulas, performance constraints, or integration points that motivate the decision | Yes |\n| `project.yaml` | `engine.name` — derives the primary specialist (`-specialist`) to spawn for validation (Step 5.5) | Yes |\n| `.claude/docs/technical-preferences.md` | `Engine Specialists` section — legacy fallback, used only when `engine.name` is absent or empty in `project.yaml` | Yes — required only when `engine.name` is absent |\n\n### Preconditions\n- An engine must be configured (`docs/engine-reference/[engine]/VERSION.md` must exist) — if not, the skill prompts to run `/setup-engine` first\n- The title or subject of the decision must be provided by the user before Step 0 proceeds (if no argument is given, the skill asks)\n- If in **retrofit mode** (`retrofit [path]` argument), the target ADR file must already exist on disk\n- Any conflict with a registered architectural stance in `docs/registry/architecture.yaml` must be resolved or explicitly accepted as an exception before the ADR is drafted (Step 3a is a BLOCKING gate)\n\n## Outputs Produced\n\n### Files Written\n| File | Guaranteed Fields / Sections | Notes |\n|------|------------------------------|-------|\n| `docs/architecture/adr-NNNN-[slug].md` | `## Status`, `## Date`, `## Engine Compatibility` (table with engine, domain, knowledge risk, post-cutoff APIs, verification required), `## ADR Dependencies` (table with depends-on, enables, blocks, ordering note), `## Context` (problem statement, constraints, requirements), `## Decision` (+ architecture diagram + key interfaces), `## Alternatives Considered`, `## Consequences` (positive, negative), `## Risks`, `## GDD Requirements Addressed` (table), `## Performance Implications`, `## Migration Plan`, `## Validation Criteria`, `## Related` | created after user approves (\"May I write this ADR to docs/architecture/adr-NNNN-[slug].md?\") |\n| `docs/registry/architecture.yaml` | New stance entries (state ownership, interface contracts, performance budgets, forbidden patterns) derived from the ADR; existing entries marked `status: superseded_by` if overridden | appended after separate user approval (\"May I update docs/registry/architecture.yaml with these N new stances?\") |\n\n### Output Guarantees\n- The ADR number is the next sequential integer after the highest existing `adr-NNNN-*` filename in `docs/architecture/`\n- `## Status` is always present. Authoring writes `Proposed`; retrofit writes the status the user gives, except that an `Accepted` answer is written as `Proposed` and handed to acceptance mode. Only acceptance mode writes `Accepted`, after its dependency check and the user's confirmation\n- `## Engine Compatibility` is always populated using verified data from the engine reference docs — never from training data alone when the domain carries MEDIUM or HIGH risk\n- `## GDD Requirements Addressed` is always present (if no GDD motivated the decision, it documents which GDDs the decision will constrain or enable)\n- `## ADR Dependencies` is always present (fields set to \"None\" if no ordering constraints exist)\n- Engine specialist validation (Step 5.5) runs before the file is written if an engine specialist is configured; blocking issues found by the specialist cause the Decision section to be revised before saving\n\n## Immutability Rules\n- READS but does NOT modify: all existing ADR files in `docs/architecture/` (including in retrofit mode — existing sections are never touched), all GDD files in `design/gdd/`, `docs/engine-reference/**`, `project.yaml`, `.claude/docs/technical-preferences.md` (legacy fallback)\n- MODIFIES: `docs/architecture/adr-NNNN-[slug].md` (new file created; or missing sections appended in retrofit mode), `docs/registry/architecture.yaml` (append only; existing entries get `status: superseded_by` annotation, never deleted or rewritten)\n- In retrofit mode: appends only the missing sections — never modifies any section that is already present in the target ADR file\n\n## Hard Constraints (Never Violate)\n- Never sets `Status: Accepted` without explicit user confirmation — the default on creation is always `Status: Proposed`\n- **Acceptance route: `/architecture-decision accept ADR-NNNN`** — the only path that sets `Accepted`. It refuses when a dependency is still Proposed, and prompts for confirmation regardless of `modes.automation`. Retrofit mode's `Accepted` answer, for a decision already in force, is written as `Proposed` and handed to this route. Without this route acceptance would be enforced by ten skills, owned per the authority below, and reachable by nobody.\n- **Acceptance authority: the user, or `technical-director` on the user's explicit confirmation — no other agent, and not this skill on its own.** Recorded here because every consumer enforces the consequences of acceptance, and without this line nothing would say who can produce it. This narrows *who* may set the field; it does not relax the confirmation rule above.\n- Never assigns an ADR number that is already in use — always scan `docs/architecture/` first and use the next sequential number\n- Never proceeds past the architectural stance conflict check (Step 3a) if a conflict exists — surface the conflict and require resolution or explicit exception acknowledgment before drafting\n- Never references APIs listed in `docs/engine-reference/[engine]/deprecated-apis.md` in the Decision or Key Interfaces sections\n- Never writes the ADR file without asking: \"May I write this ADR to docs/architecture/adr-NNNN-[slug].md?\"\n- Never writes to `docs/registry/architecture.yaml` without a separate ask: \"May I update docs/registry/architecture.yaml with these N new stances?\"\n- In retrofit mode: never modifies any existing section — only appends absent sections\n\n## Downstream Skill Expects\n**Next skills:** `/create-epics`, `/create-stories`, `/dev-story`, `/architecture-review`\n\n### `/create-epics` reads ADRs expecting:\n- `## Status` field — value must be `Accepted` for epics to reference it\n- `## GDD Requirements Addressed` table — used to link epics to GDD traceability\n- `## Engine Compatibility` section — checked during the Technical Setup → Pre-Production gate\n\n### `/create-stories` reads ADRs expecting:\n- `### Implementation Guidelines` (under `## Decision`) — the concrete \"must / must never\" patterns programmer agents follow; the ADR template carries this subsection\n- `## ADR Dependencies` table — stories referencing a `Depends On` ADR that is still `Proposed` are automatically set `Status: Blocked`\n\n### `/dev-story` reads ADRs expecting:\n- `## Decision` (full text, verbatim — not summarized)\n- `### Implementation Guidelines` (under `## Decision`, verbatim)\n- `## Engine Compatibility` (post-cutoff API risks, verification required)\n- `## ADR Dependencies` (to detect if this ADR's dependencies are unresolved)\n\n### `/architecture-review` reads ADRs expecting:\n- All required sections present (it flags gaps)\n- `## Status` is set (required for coverage matrix)\n- `## Engine Compatibility` is stamped with the correct engine version\n\n## Known Fragile Points\n- If the ADR number scan misses a file (e.g., a file in a subdirectory of `docs/architecture/` or with a non-standard naming pattern), a duplicate number can be assigned — all ADR files must follow the `adr-NNNN-[slug].md` naming convention at the top level of `docs/architecture/`\n- Acceptance mode moves a story from `Blocked` to `Ready` only when the story file, under `production/epics/`, contains a Blocked Status line in any of the forms `/create-stories` writes (`> **Status**: Blocked`, `**Status:** Blocked`, `Status: Blocked`) and this ADR's id. A story blocked pending this ADR that never names its id is not found, and stays `Blocked` until it is updated by hand\n- The `## GDD Requirements Addressed` table is populated based on what the user tells the skill during the collaborative session; if the user does not know which GDDs motivated the decision, this table may be incomplete — `/create-epics` and `/gate-check` both rely on this linkage for traceability\n- Engine specialist validation (Step 5.5) is skipped only when **both** sources are unset — `engine.name` absent or empty in `project.yaml` **and** `.claude/docs/technical-preferences.md` still reading `[TO BE CONFIGURED]`. A project configured solely via `project.yaml` **does** get specialist validation. When both are unset, post-cutoff engine API risks are not caught before the ADR is written\n- `docs/registry/architecture.yaml` is append-only by design; if a stance entry becomes permanently invalid (not superseded by another ADR), it must be manually removed — there is no cleanup mechanism\n- In retrofit mode, if the existing ADR has sections present but empty (e.g., a `## Status` heading with no value), the skill treats the section as present and does not fill it — an empty Status is effectively invisible to downstream skills like `/story-readiness`\n",".claude/skills/architecture-decision/SKILL.md":"---\nname: architecture-decision\ndescription: \"Create an ADR documenting a technical decision: context, alternatives considered, consequences.\"\nargument-hint: \"[title | retrofit | accept ] [--review full|lean|solo]\"\nuser-invocable: true\nallowed-tools: Read, Glob, Grep, Write, Edit, Agent, AskUserQuestion, Bash(wc -c *), Bash(bash \"*/.claude/skills/architecture-decision/../../hooks/yaml-helper.sh\" resolve_config *), Bash(bash .claude/scripts/registry.sh *)\nmodel: sonnet\n---\n\n!`bash \"${CLAUDE_SKILL_DIR}/../../hooks/yaml-helper.sh\" resolve_config --keys review_mode,automation,workflow,docs.density,team.size`\n\nResolved above — use as-is; `--review` overrides `review_mode`. No block →\ndefaults in `.claude/docs/config-resolution.md`.\n\n# Architecture Decision\n\nWhen this skill is invoked:\n\n## 0. Parse Arguments — Detect Retrofit / Acceptance Mode\n\nSee `.claude/docs/director-gates.md` for the full check pattern. Individual gate definitions live in `.claude/docs/director-gates/[gate-id].md` — the spawned agent reads its own gate file; do not read it in the parent session.\n\nEvery `AskUserQuestion` call follows `.claude/docs/automation-modes.md`\n(collaborative asks always · guided major-only · autonomous logs and proceeds;\n`automation_always_ask` categories always prompt).\n\n**`team.size`**: which agents validate this ADR (orthogonal to review_mode/workflow).\n- **`individual`** (default): `technical-director` (TD-ADR) + the engine-specialist.\n- **`small`** and **`studio`**: the same two. This skill spawns no engine\n sub-specialist and no adversarial reviewer at any size.\n\n**`docs.density`** — it controls the *depth* of the ADR's prose sections, not\nwhich sections the skeleton emits (that is fixed). `modes.rigor` sets it\nalongside `workflow`; set `docs.density` explicitly to vary ADR verbosity alone:\n`terse` (the default, via `rigor: minimal`) = decision + alternatives as bullets, one line of rationale each;\n`balanced` = paragraph per section with light rationale (`rigor: standard`); `thorough` =\nfull prose with trade-offs and worked rationale in Decision, Alternatives, and\nConsequences. Apply it to the prose sections; the Engine Compatibility, ADR\nDependencies, and GDD Requirements tables are structural and stay whole at every\ndensity.\n\n**`workflow`** (see `.claude/docs/workflow-modes.md`):\n- `full` — all ADRs on the required ADR list must be completed.\n- `standard` — critical ADRs only (Foundation-layer systems).\n- `minimal` — not required. Can still be run voluntarily.\n\n**If the argument starts with `retrofit` followed by a file path**\n\n**Read `references/0-retrofit.md` now and follow it** — this phase's steps are in that file, not here. Read it again if the conversation was compacted or resumed during this phase.\n\n**If the argument starts with `accept` followed by an ADR id**\n\n**Read `references/0-accept.md` now and follow it** — this phase's steps are in that file, not here. Read it again if the conversation was compacted or resumed during this phase.\n\nIf NOT in retrofit or acceptance mode, proceed to Step 1 below (normal ADR authoring).\n\n**No-argument guard**: If no argument was provided (title is empty), ask before\nrunning Phase 0:\n\n> \"What technical decision are you documenting? Please provide a short title\n> (e.g., `event-system-architecture`, `physics-engine-choice`).\"\n\nUse the user's response as the title, then proceed to Step 1.\n\n---\n\n## 1. Load Engine Context (ALWAYS FIRST)\n\n**Read `references/1-engine-context.md` now and follow it** — this phase's steps are in that file, not here. Read it again if the conversation was compacted or resumed during this phase.\n\n## 2. Determine the next ADR number\n\nScan `docs/architecture/` for existing ADRs to find the next number.\n\n---\n\n## 3. Gather context\n\n**Read `references/3-gather-context.md` now and follow it** — this phase's steps are in that file, not here. Read it again if the conversation was compacted or resumed during this phase.\n\n## 4. Guide the decision collaboratively\n\n**Read `references/4-decide.md` now and follow it** — this phase's steps are in that file, not here. Read it again if the conversation was compacted or resumed during this phase.\n\n## 5. Generate the ADR\n\n**Read `references/5-generate.md` now and follow it** — this phase's steps are in that file, not here. Read it again if the conversation was compacted or resumed during this phase.\n\n## 6. Closing Next Steps\n\nAfter the ADR is written (and registry optionally updated), close with `AskUserQuestion`.\n\nBefore generating the widget:\n1. Read the `## Required ADRs` section of `docs/architecture/architecture.md` (by section) and list `docs/architecture/adr-*.md`: a required ADR with no file is still unwritten. Without `architecture.md`, look for ADRs flagged in technical-preferences.md or systems-index.md as prerequisites\n2. Check if all prerequisite ADRs are now written. If yes, include a \"Start writing GDDs\" option.\n3. List ALL remaining priority ADRs as individual options — not just the next one or two.\n\nWidget format:\n```\nADR-[NNNN] written and registry updated. What would you like to do next?\n[1] Write [next-priority-adr-name] — [brief description from prerequisites list]\n[2] Write [another-priority-adr] — [brief description] (include ALL remaining ones)\n[N] Start writing GDDs — run `/design-system [first-undesigned-system]` (only show if all prerequisite ADRs are written)\n[N+1] Stop here for this session\n```\n\nIf there are no remaining priority ADRs and no undesigned GDD systems, offer only \"Stop here\" and suggest running `/architecture-review` in a fresh session.\n\n**Always include this fixed notice in the closing output (do NOT omit it):**\n\n> To validate ADR coverage against your GDDs, open a **fresh Claude Code session**\n> and run `/architecture-review`.\n>\n> **Never run `/architecture-review` in the same session as `/architecture-decision`.**\n> The reviewing agent must be independent of the authoring context to give an unbiased\n> assessment. Running it here would invalidate the review.\n\n**Do NOT unblock stories here.** This ADR is `Proposed` — Step 5 guarantees it,\nand a story blocked *pending this decision* is still pending it. Unblocking on\nauthoring defeats the guard at the moment it becomes relevant: the pipeline\nappears to flow while running on decisions nobody has accepted.\n\nInstead, tell the user what is now waiting on acceptance:\n\n> \"ADR-NNNN is written and `Proposed`. [N] stories remain `Blocked` pending it.\n> Run `/architecture-decision accept ADR-NNNN` when the decision is settled —\n> that is what moves them to `Ready`.\"\n\nList the blocked stories by path so the cost of leaving it Proposed is visible.\n(Acceptance has consequences enforced across many skills and an authority\nrecorded in only a few, so the route between them must stay explicit.)\n",".claude/skills/architecture-decision/references/0-accept.md":"# /architecture-decision — Acceptance Mode\n\n> Part of `/architecture-decision`. `SKILL.md` names when to read this file; the settings it\n> resolved and the rules under its later headings still apply here.\n\n**If the argument starts with `accept` followed by an ADR id**\n\n(e.g., `/architecture-decision accept ADR-0005`):\n\nEnter **acceptance mode**. This is the *only* path in the framework that moves an\nADR from `Proposed` to `Accepted`. Authoring always produces `Proposed`\n(Step 5), while\n`/create-control-manifest`, `/create-epics`, `/create-stories` and `/gate-check`\nall require `Accepted` — so without this mode an ADR would enter a state it\nnever leaves.\n\n1. **Resolve the id to a file, then read it.** Glob\n `docs/architecture/adr-NNNN-*.md` for the given number. If **no** file matches,\n or **more than one** does, stop and say which — do not pick one. If the file\n has no `## Status` section, stop and say so; a missing Status is exactly what\n retrofit mode is for.\n2. **Check the current status.** If it is already `Accepted`, say so and stop.\n If it is `Deprecated` or `Superseded`, refuse: reviving a superseded decision\n is a new ADR, not a status edit.\n3. **Check its dependencies first.** Read `## ADR Dependencies`.\n\n **If that section is absent, empty, or reads `UNKNOWN`, do not read it as\n \"no dependencies\" — refuse and say which:**\n > \"ADR-0005's dependency section is [absent / UNKNOWN], so I cannot tell what\n > this decision rests on. An empty dependency list and an unexamined one look\n > identical here, and only one of them is safe to accept. Run\n > `/architecture-decision retrofit ` to establish it.\"\n\n A dependency check reading a field that defaults to empty is the vacuous-pass\n shape this gate exists to prevent — the check would examine nothing and report\n clean.\n\n If it depends on any ADR that is not itself `Accepted`, **refuse and name them**:\n > \"ADR-0005 depends on ADR-0002, which is still Proposed. Accept ADR-0002\n > first — an accepted decision resting on an unaccepted one is not a decision,\n > it is a deferral with a different label.\"\n This is the same dependency rule `/architecture-review` already flags; here it\n is enforced rather than reported.\n4. **Confirm with the user, always.** Per `CONTRACT.md`, acceptance authority is\n **the user, or `technical-director` on the user's explicit confirmation — no\n other agent, and never this skill on its own.** Use `AskUserQuestion`:\n - Prompt: \"Accept ADR-NNNN — [title]? This is what unblocks stories and epics\n that depend on it.\"\n - Options: `[A] Yes — accept it` / `[B] Not yet — leave it Proposed`\n **This prompt fires regardless of `modes.automation`, including `autonomous`.**\n Acceptance is the decision the whole architecture pipeline gates on; it is not\n a step to be inferred.\n5. **Find the stories this will unblock, BEFORE the prompt in step 4.** Grep\n every story for a Blocked Status line —\n `Grep pattern=\"Status\\**:\\**\\s*Blocked\" path=\"production/epics\" glob=\"**/story-*.md\" output_mode=\"files_with_matches\"`,\n which matches `> **Status**: Blocked` (the form `/create-stories` writes),\n `**Status:** Blocked` and `Status: Blocked` — and keep the files that name\n this ADR's id as the reason they are blocked. That pairing is what \"blocked\n pending this ADR\" means — a story blocked for an unrelated reason will not\n name it. Leave out a story that names this ADR only as the successor to point\n at (`point the story at ADR-NNNN`, the note for a `Deprecated` or\n `Superseded` ADR): it is still governed by the old ADR, and accepting the\n successor does not re-point it.\n > **Stories live only under `production/epics/`.** A flat top-level stories\n > directory does not exist and no skill creates one — never write or match a\n > path outside `production/epics/`. `/dev-story` matches entries *by file\n > path*, so a story recorded under any other path silently fails to match and\n > never gets picked up.\n\n Feed the count into step 4's prompt so it reads *\"3 stories become Ready\"*\n rather than a generic claim: **the user is being asked to authorise an effect, and should be\n shown the effect.** If none match, say \"no stories are waiting on this\" — that\n is useful information, not an empty result to omit.\n6. On confirmation, `Edit` the `## Status` line to `Accepted`. Leave an existing\n `## Date` as it is: it records when the ADR was written, and `/create-stories`\n stamps stories with it (or `## Last Verified`), so rewriting it on acceptance\n would make every story drafted against the Proposed ADR look out of date to\n `/dev-story`. **If that section is absent, add it** with today's date — retrofit\n mode already owns this shape, and acceptance must not fail on a template that\n predates the field.\n7. Then set each story found in step 5 from `Blocked` to `Ready`. Unblocking is a\n consequence of acceptance, never of authoring — see Step 6's note below.\n8. Report what moved: the ADR (and its `## Date`, if one was added), and every\n story that became Ready.\n",".claude/skills/architecture-decision/references/0-retrofit.md":"# /architecture-decision — Retrofit Mode\n\n> Part of `/architecture-decision`. `SKILL.md` names when to read this file; the settings it\n> resolved and the rules under its later headings still apply here.\n\n**If the argument starts with `retrofit` followed by a file path**\n\n(e.g., `/architecture-decision retrofit docs/architecture/adr-0001-event-system.md`):\n\nEnter **retrofit mode**:\n\n1. Read the existing ADR file completely. This step needs the whole ADR: read it\n in ranges by its headings (found with the Grep tool: pattern `^#`, content\n mode), since a whole-file Read over 40 KB is refused.\n2. Identify which template sections are present by scanning headings:\n - `## Status` — **BLOCKING if missing**: `/story-readiness` cannot check ADR acceptance\n - `## ADR Dependencies` — HIGH if missing: dependency ordering breaks\n - `## Engine Compatibility` — HIGH if missing: post-cutoff risk unknown. A\n present table with no **Layer** row is HIGH too: the ADR counts as critical\n wherever it is read, so at `standard` its advisory items become blockers\n - `## GDD Requirements Addressed` — MEDIUM if missing: traceability lost\n - `## Date` — MEDIUM if missing, and no `## Last Verified` either: `/create-stories`\n stamps stories with it and `/dev-story` compares against it, so without it a\n story can never tell whether the ADR changed\n3. Present to the user:\n ```\n ## Retrofit: [ADR title]\n File: [path]\n\n Sections already present (will not be touched):\n ✓ Status: [current value, or \"MISSING — will add\"]\n ✓ [section]\n\n Missing sections to add:\n ✗ Status — BLOCKING (stories cannot validate ADR acceptance without this)\n ✗ ADR Dependencies — HIGH\n ✗ Engine Compatibility — HIGH\n ```\n4. Ask: \"Shall I add the [N] missing sections? I will not modify any existing content.\"\n If no: write nothing, and report the missing sections by name.\n5. If yes:\n - For **Status**: ask the user — \"What is the current status of this decision?\"\n Options: \"Proposed\", \"Accepted\", \"Deprecated\", \"Superseded by ADR-XXXX\"\n An `Accepted` answer — a decision already in force — is not written as\n given: write `Proposed`, add the other missing sections, then run\n acceptance mode (below) on this ADR. Its dependency check, confirmation and\n story unblocking apply here too; it stays the only path that sets `Accepted`.\n - For **ADR Dependencies**: ask — \"Does this decision depend on any other ADR?\n Does it enable or block any other ADR or epic?\" Accept \"None\" for each field.\n - For **Engine Compatibility**: read the engine reference docs (same as Step 1 below)\n and ask the user to confirm the domain. Then generate the table with verified data,\n its Layer row included.\n - For a present Engine Compatibility table with no **Layer** row: find the\n layer as `references/5-generate.md` says under \"Always write the Layer row\",\n and add the row under **Domain**. It adds a row and changes none.\n - For **GDD Requirements Addressed**: ask — \"Which GDD systems motivated this decision?\n What specific requirement in each GDD does this ADR address?\"\n - Append each missing section to the ADR file using the Edit tool.\n - For **Date** (counted only when there is no `## Last Verified`): append\n `## Date` with today's date — even when it is the only missing section, the\n case `/dev-story` sends you here for — and say that it records the retrofit,\n not when the decision was made.\n - **Never modify any existing section.** Only append or fill absent sections.\n6. Suggest: \"Run `/architecture-review` to re-validate coverage now that this ADR\n has its Status and Dependencies fields.\"\n",".claude/skills/architecture-decision/references/1-engine-context.md":"# /architecture-decision — Step 1: Load Engine Context\n\n> Part of `/architecture-decision`. `SKILL.md` names when to read this file; the settings it\n> resolved and the rules under its later headings still apply here.\n\n## 1. Load Engine Context (ALWAYS FIRST)\n\nBefore doing anything else, establish the engine environment:\n\n1. Read `docs/engine-reference/[engine]/VERSION.md` to get:\n - Engine name and version\n - LLM knowledge cutoff date\n - Post-cutoff version risk levels (LOW / MEDIUM / HIGH)\n\n2. Identify the **domain** of this architecture decision from the title or\n user description. Common domains: Physics, Rendering, UI, Audio, Navigation,\n Animation, Networking, Core, Input, Scripting.\n\n3. Read the corresponding module reference if it exists:\n `docs/engine-reference/[engine]/modules/[domain].md`\n\n4. Read `docs/engine-reference/[engine]/breaking-changes.md` — flag any\n changes in the relevant domain that post-date the LLM's training cutoff.\n\n5. Read `docs/engine-reference/[engine]/deprecated-apis.md` — flag any APIs\n in the relevant domain that should not be used.\n\n6. **Display a knowledge gap warning** before proceeding if the domain carries\n MEDIUM or HIGH risk:\n\n ```\n ⚠️ ENGINE KNOWLEDGE GAP WARNING\n Engine: [name + version]\n Domain: [domain]\n Risk Level: HIGH — This version is post-LLM-cutoff.\n\n Key changes verified from engine-reference docs:\n - [Change 1 relevant to this domain]\n - [Change 2]\n\n This ADR will be cross-referenced against the engine reference library.\n Proceed with verified information only — do NOT rely solely on training data.\n ```\n\n If no engine has been configured yet, prompt: \"No engine is configured.\n Run `/setup-engine` first, or tell me which engine you are using.\"\n\n---\n",".claude/skills/architecture-decision/references/3-gather-context.md":"# /architecture-decision — Steps 3a and 3b: Gather Context\n\n> Part of `/architecture-decision`. `SKILL.md` names when to read this file; the settings it\n> resolved and the rules under its later headings still apply here.\n\n## 3. Gather context\n\n### 3a: Architecture Registry Check (BLOCKING gate) — do this FIRST\n\nRead `docs/registry/architecture.yaml`. Extract entries relevant to this ADR's\ndomain and decision (grep by system name, domain keyword, or state being touched).\nRun this before reading any existing ADR — the registry exists specifically so a\nnew ADR's author does not need to open prior ADRs to learn their binding facts\n(state ownership, interface contracts, forbidden patterns).\n\nPresent any relevant stances to the user **before** the collaborative design\nbegins, as locked constraints:\n\n```\n## Existing Architectural Stances (must not contradict)\n\nState Ownership:\n player_health → owned by health-system (ADR-0001)\n Interface: HealthComponent.current_health (read-only float)\n → If this ADR reads or writes player health, it must use this interface.\n\nInterface Contracts:\n damage_delivery → signal pattern (ADR-0003)\n Signal: damage_dealt(amount, target, is_crit)\n → If this ADR delivers or receives damage events, it must use this signal.\n\nForbidden Patterns:\n ✗ autoload_singleton_coupling (ADR-0001)\n ✗ direct_cross_system_state_write (ADR-0000)\n → The proposed approach must not use these patterns.\n```\n\nIf the user's proposed decision would contradict any registered stance, surface\nthe conflict immediately:\n\n> \"⚠️ Conflict: This ADR proposes [X], but ADR-[NNNN] established that [Y] is\n> the accepted pattern for this purpose. Proceeding without resolving this will\n> produce contradictory ADRs and inconsistent stories.\n> Options: (1) Align with the existing stance, (2) Supersede ADR-[NNNN] with\n> an explicit replacement, (3) Explain why this case is an exception.\"\n\nDo not proceed to Step 4 (collaborative design) until any conflict is resolved\nor explicitly accepted as an intentional exception.\n\n### 3b: Existing ADRs and Related GDDs — registry-scoped, never unbounded\n\nThe registry (3a) covers *what* prior decisions bind — not always *why*. If the\nregistry surfaced a directly relevant ADR and its reasoning matters here (not\njust its stated facts), read that specific ADR — never glob-and-read every\nADR in `docs/architecture/` on the chance one is relevant. Read it by section:\nfind the headings you need with the Grep tool (pattern `^#`, content mode)\nand Read those ranges with offset and limit.\n\n1. **Map its headings first** (cheap):\n ```\n Grep pattern=\"^## \" path=\"docs/architecture/[adr-file].md\" output_mode=\"content\" -n\n ```\n2. **Under ~40KB** (`Bash: wc -c \"docs/architecture/[adr-file].md\"`) — one full\n `Read` is fine; per-call overhead exceeds the savings from bounded reads at\n this size.\n3. **~40KB or larger** — bounded-read only `## Context`, `## Decision`, and\n `## Consequences` (the sections that carry reasoning, not just facts) via\n `Read(offset, limit)` from the heading map.\n\nRead GDDs the same way `/design-system` Step 2b does: only GDDs the registry\nor the ADR list names as directly relevant, and only their `## Dependencies`,\n`## Formulas`, and `## Edge Cases` sections\n(`Grep pattern=\"^## (Dependencies|Formulas|Edge Cases)\" ... -A 40`) — never a\nspeculative full read of `design/gdd/*.md` looking for anything that might\nrelate.\n\nSkip 3b entirely if the registry already answers everything this decision\nneeds — most ADRs will.\n\n---\n",".claude/skills/architecture-decision/references/4-decide.md":"# /architecture-decision — Step 4: Guide the Decision Collaboratively\n\n> Part of `/architecture-decision`. `SKILL.md` names when to read this file; the settings it\n> resolved and the rules under its later headings still apply here.\n\n## 4. Guide the decision collaboratively\n\nBefore asking anything, derive the skill's best guesses from the context already\ngathered (GDDs read, engine reference loaded, existing ADRs scanned). Then present\na **confirm/adjust** prompt using `AskUserQuestion` — not open-ended questions.\n\n**Derive assumptions first:**\n- **Problem**: Infer from the title + GDD context what decision needs to be made\n- **Alternatives**: Propose 2-3 concrete options from engine reference + GDD requirements\n- **Dependencies**: Scan existing ADRs for upstream dependencies. **If the scan is\n inconclusive, present `UNKNOWN — scan inconclusive, please confirm`, never\n `None`.** The two are not interchangeable: `None` asserts that nothing upstream\n constrains this decision, and a user confirming a prefilled list cannot tell an\n assertion from a guess. This field is load-bearing — `/architecture-review`\n flags unaccepted dependencies, `/dev-story` reads it, and the acceptance route\n in Phase 0 **refuses to accept an ADR whose dependencies are not themselves\n Accepted**. A dependency list that defaulted to empty makes that check pass\n while examining nothing. `UNKNOWN` must be resolved during the confirm/adjust\n prompt; it is a prompt state, never a value written to the file\n- **GDD linkage**: Extract which GDD systems the title directly relates to\n- **Status**: Always `Proposed` for new ADRs — never ask the user what the status is\n\n**Scope of assumptions tab**: Assumptions cover only: problem framing, alternative approaches, upstream dependencies, GDD linkage, and status. Schema design questions (e.g., \"How should spawn timing work?\", \"Should data be inline or external?\") are NOT assumptions — they are design decisions belonging to a separate step after the assumptions are confirmed. Do not include schema design questions in the assumptions AskUserQuestion widget.\n\n**After assumptions are confirmed**, if the ADR involves schema or data design choices, use a separate multi-tab `AskUserQuestion` to ask each design question independently before drafting.\n\n**Present assumptions with `AskUserQuestion`:**\n\n```\nHere's what I'm assuming before drafting:\n\nProblem: [one-sentence problem statement derived from context]\nAlternatives I'll consider:\n A) [option derived from engine reference]\n B) [option derived from GDD requirements]\n C) [option from common patterns]\nGDD systems driving this: [list derived from context]\nDependencies: [upstream ADRs if any, otherwise \"None\"]\nStatus: Proposed\n\n[A] Proceed — draft with these assumptions\n[B] Change the alternatives list\n[C] Adjust the GDD linkage\n[D] Add a performance budget constraint\n[E] Something else needs changing first\n```\n\nDo not generate the ADR until the user confirms assumptions or provides corrections.\n\n**After engine specialist and TD reviews return** (Step 5.5/5.6), if unresolved\ndecisions remain, present each one as a separate `AskUserQuestion` with the proposed\noptions as choices plus a free-text escape:\n\n```\nDecision: [specific unresolved point]\n[A] [option from specialist review]\n[B] [alternative option]\n[C] Different approach — I'll describe it\n```\n\n**ADR Dependencies** — derive from existing ADRs, then confirm:\n- Does this decision depend on any other ADR not yet Accepted?\n- Does it unlock or unblock any other ADR or epic?\n- Does it block any specific epic from starting?\n\nRecord answers in the **ADR Dependencies** section. Write \"None\" for each field if no constraints apply.\n\n---\n",".claude/skills/architecture-decision/references/5-generate.md":"# /architecture-decision — Step 5: Generate the ADR\n\n> Part of `/architecture-decision`. `SKILL.md` names when to read this file; the settings it\n> resolved and the rules under its later headings still apply here.\n\n## 5. Generate the ADR\n\n**In this file:**\n\n- The ADR template\n- 5.5 Engine Specialist Validation\n- 5.6 Technical Director Strategic Review, with the review mode check\n- 5.7 GDD Sync Check: found, none found, could not check\n- Write approval\n- Update Architecture Registry, and the registry append logic\n\nFollowing this format:\n\n```markdown\n# ADR-[NNNN]: [Title]\n\n## Status\n[Proposed | Accepted | Deprecated | Superseded by ADR-XXXX]\n\n## Date\n[Date of decision]\n\n## Last Verified\n[YYYY-MM-DD — when this ADR was last confirmed accurate against the current\nengine version and design. Update this date when you re-read and confirm it is\nstill correct, even if nothing changed.]\n\n## Decision Makers\n[Who was involved in this decision]\n\n## Summary\n[2 sentences: what problem this ADR solves, and what was decided. Written for\ntiered context loading — a skill scanning 20 ADRs uses this to decide whether to\nread the full decision. Be specific: name the system, the problem, and the\nchosen approach.]\n\n## Engine Compatibility\n\n| Field | Value |\n|-------|-------|\n| **Engine** | [e.g. Godot 4.7] |\n| **Domain** | [Physics / Rendering / UI / Audio / Navigation / Animation / Networking / Core / Input] |\n| **Layer** | [Foundation / Core / Feature / Presentation] |\n| **Knowledge Risk** | [LOW / MEDIUM / HIGH — from VERSION.md] |\n| **References Consulted** | [List engine-reference docs read, e.g. `docs/engine-reference/godot/modules/physics.md`] |\n| **Post-Cutoff APIs Used** | [Any APIs from post-LLM-cutoff versions this decision depends on, or \"None\"] |\n| **Verification Required** | [Specific behaviours to test before shipping, or \"None\"] |\n\n## ADR Dependencies\n\n| Field | Value |\n|-------|-------|\n| **Depends On** | [ADR-NNNN (must be Accepted before this can be implemented), or \"None\"] |\n| **Enables** | [ADR-NNNN (this ADR unlocks that decision), or \"None\"] |\n| **Blocks** | [Epic/Story name — cannot start until this ADR is Accepted, or \"None\"] |\n| **Ordering Note** | [Any sequencing constraint that isn't captured above] |\n\n## Context\n\n### Problem Statement\n[What problem are we solving? Why does this decision need to be made now?]\n\n### Constraints\n- [Technical constraints]\n- [Timeline constraints]\n- [Resource constraints]\n- [Compatibility requirements]\n\n### Requirements\n- [Must support X]\n- [Must perform within Y budget]\n- [Must integrate with Z]\n\n## Decision\n\n[The specific technical decision made, described in enough detail for someone\nto implement it.]\n\n### Architecture Diagram\n[ASCII diagram or description of the system architecture this creates]\n\n### Key Interfaces\n[API contracts or interface definitions this decision creates]\n\n### Implementation Guidelines\n[Specific guidance for the programmer implementing this decision — the rules a\n`/create-control-manifest` or `/dev-story` run should follow. State mandates as\n\"must / must never\" so they extract cleanly.]\n\n## Alternatives Considered\n\n### Alternative 1: [Name]\n- **Description**: [How this would work]\n- **Pros**: [Advantages]\n- **Cons**: [Disadvantages]\n- **Rejection Reason**: [Why this was not chosen]\n\n### Alternative 2: [Name]\n- **Description**: [How this would work]\n- **Pros**: [Advantages]\n- **Cons**: [Disadvantages]\n- **Rejection Reason**: [Why this was not chosen]\n\n## Consequences\n\n### Positive\n- [Good outcomes of this decision]\n\n### Negative\n- [Trade-offs and costs accepted]\n\n## Risks\n- [Things that could go wrong]\n- [Mitigation for each risk]\n\n## GDD Requirements Addressed\n\n| GDD System | Requirement | How This ADR Addresses It |\n|------------|-------------|--------------------------|\n| [system-name].md | [specific rule, formula, or performance constraint from that GDD] | [how this decision satisfies it] |\n\n## Performance Implications\n- **CPU**: [Expected impact]\n- **Memory**: [Expected impact]\n- **Load Time**: [Expected impact]\n- **Network**: [Expected impact, if applicable]\n\n## Migration Plan\n[If this changes existing code, how do we get from here to there?]\n\n## Validation Criteria\n[How will we know this decision was correct? What metrics or tests?]\n\n## Related\n- [Links to related ADRs — note if supersedes, contradicts, or depends on]\n- [Links to related design documents]\n```\n\n**Always write the Layer row.** An ADR with no Layer row counts as critical\n(Foundation) wherever it is read, so at `standard` its advisory items become\nblockers. The value is the ADR's own layer, how early in the build it must\nexist: the layer `docs/architecture/architecture.md`'s layer map gives the\nsystem this decision governs. With no layer map, or no system in it, ask the\nuser, with the four values as options. Never take it from an epic that\nreferences the ADR, and never reuse a `Domain` value (the template's note under\nEngine Compatibility says why).\n\n5.5. **Engine Specialist Validation** — Before saving, spawn the **primary engine specialist** via `Agent` to validate the drafted ADR:\n - Resolve the primary specialist: `-specialist` derived from `engine.name` in `project.yaml` (Godot→`godot-specialist`, Unity→`unity-specialist`, Unreal→`unreal-specialist`); if `engine.name` is absent or empty, read the Primary line of the `## Engine Specialists` section in `.claude/docs/technical-preferences.md`\n - If no engine is configured (neither source yields an engine), skip this step **Record ``Engine validation: NOT ASSESSED — no engine configured (`engine.name` unset in `project.yaml`)`` in this run's output.** A skipped check that says nothing is indistinguishable from a check that passed; the reader cannot tell engine guidance was never sought.\n - Spawn `subagent_type: [primary specialist]` with: the ADR's Engine Compatibility section, Decision section, Key Interfaces, and the engine reference docs path. Ask them to:\n 1. Confirm the proposed approach is idiomatic for the pinned engine version\n 2. Flag any APIs or patterns that are deprecated or changed post-training-cutoff\n 3. Identify engine-specific risks or gotchas not captured in the current ADR draft\n - If the specialist identifies a **blocking issue** (wrong API, deprecated approach, engine version incompatibility): revise the Decision and Engine Compatibility sections accordingly, then confirm the changes with the user before proceeding\n - If the specialist finds **minor notes** only: incorporate them into the ADR's Risks subsection\n\n**Review mode check** — apply before spawning TD-ADR:\n- `solo` → skip. Note: \"TD-ADR skipped — Solo mode.\" Proceed to Step 5.7 (GDD sync check).\n- `lean` → skip (not a PHASE-GATE). Note: \"TD-ADR skipped — Lean mode.\" Proceed to Step 5.7 (GDD sync check).\n- `full` → spawn as normal.\n\n5.6. **Technical Director Strategic Review** — After the engine specialist validation, spawn `technical-director` via `Agent` using gate **TD-ADR** (`.claude/docs/director-gates/td-adr.md`):\n - Pass: the ADR file path (or draft content), engine version, domain, any existing ADRs in the same domain\n - The TD validates architectural coherence (is this decision consistent with the whole system?) — distinct from the engine specialist's API-level check\n - On CONCERNS: show them to the user verbatim and ask with the standard options from `director-gates.md` — `Revise flagged items` / `Accept and proceed` / `Discuss further`. Revise the flagged Decision or Alternatives sections only on `Revise flagged items`.\n - On REJECT: show the blockers verbatim and revise the Decision or Alternatives sections before proceeding.\n - A revised draft still reaches the user through the write approval below; nothing is written before it. A `NOT ASSESSED` answer is not an approval — name the missing input (`director-gates.md`).\n\n5.7. **GDD Sync Check** — Before presenting the write approval, scan all GDDs\nreferenced in the \"GDD Requirements Addressed\" section for naming inconsistencies\nwith the ADR's Key Interfaces and Decision sections (renamed signals, API methods,\nor data types). If any are found, surface them as a **prominent warning block**\nimmediately before the write approval — not as a footnote:\n\n```\n⚠️ GDD SYNC REQUIRED\n[gdd-filename].md uses names this ADR has renamed:\n [old_name] → [new_name_from_adr]\n [old_name_2] → [new_name_2_from_adr]\nThe GDD must be updated before or alongside writing this ADR to prevent\ndevelopers reading the GDD from implementing the wrong interface.\n```\n\n**This check has three outcomes, not two.** The two above are \"found\" and \"none\nfound\"; the third is **could not check**, which must never take the silent\nbranch and render like a clean result.\n\n- **None found** — print one line, do not stay silent:\n `GDD sync: checked [N] referenced GDD(s), no naming inconsistencies.`\n A silent pass is indistinguishable from a check that never ran, and this one\n guards against developers implementing the wrong interface from a stale GDD.\n- **Could not check** — the ADR has no `GDD Requirements Addressed` section, it\n names no GDDs, or a named GDD does not exist on disk. Print:\n `GDD sync: NOT ASSESSED — [which reason, and which files]`\n Do **not** treat an ADR that references no GDDs as one whose GDDs are\n consistent. Nothing was compared.\n\nOnly the warning block itself is conditional; the check always reports.\n\n5. **Write approval** — Use `AskUserQuestion`:\n\nIf GDD sync issues were found:\n- \"ADR draft is complete. How would you like to proceed?\"\n - [A] Write ADR + update GDD in the same pass\n - [B] Write ADR only — I'll update the GDD manually\n - [C] Not yet — I need to review further\n\nIf no GDD sync issues:\n- \"ADR draft is complete. May I write it?\"\n - [A] Write ADR to `docs/architecture/adr-[NNNN]-[slug].md`\n - [B] Not yet — I need to review further\n\nIf yes to any write option, write the file, creating the directory if needed.\nFor option [A] with GDD update: also update the GDD file(s) to use the new names.\n\n6. **Update Architecture Registry**\n\nScan the written ADR for new architectural stances that should be registered:\n- State it claims ownership of\n- Interface contracts it defines (signal signatures, method APIs)\n- Performance budget it claims\n- API choices it makes explicitly\n- Patterns it bans (Consequences → Negative or explicit \"do not use X\")\n\nPresent candidates:\n```\nRegistry candidates from this ADR:\n NEW state ownership: player_stamina → stamina-system\n NEW interface contract: stamina_depleted signal\n NEW performance budget: stamina-system: 0.5ms/frame\n NEW forbidden pattern: polling stamina each frame (use signal instead)\n EXISTING (referenced_by update only): player_health → already registered ✅\n```\n\n**Registry append logic**: When writing to `docs/registry/architecture.yaml`, do NOT assume sections are empty. The file may already have entries from previous ADRs written in this session. Before each Edit call:\n1. Read the current state of `docs/registry/architecture.yaml`\n2. Find the correct section (state_ownership, interfaces, forbidden_patterns, api_decisions)\n3. If the section is still the empty list (`state_ownership: []`), replace `[]` with the first entry: the key alone on its line, the entry below it indented two spaces as in the file's commented example. An entry appended after `[]` makes the file invalid YAML. Otherwise append the new entry AFTER the last existing entry in that section\n4. If the section has entries already, use the closing content of the last entry as the `old_string` anchor, and append the new entry after it\n\n**BLOCKING — do not write to `docs/registry/architecture.yaml` without explicit user approval.**\n\nAsk using `AskUserQuestion`:\n- \"May I update `docs/registry/architecture.yaml` with these [N] new stances?\"\n - Options: \"Yes — update the registry\", \"Not yet — I want to review the candidates\", \"Skip registry update\"\n\nOnly proceed if the user selects yes. If yes: append new entries. Never modify existing entries — if a stance is\nchanging, set the old entry to `status: \"superseded_by: ADR-[NNNN]\"` and add the new entry. Keep the quotes:\nunquoted, the second colon makes the file invalid YAML.\n\nAfter writing, run `bash .claude/scripts/registry.sh validate` and fix every row about an entry this write added\nor changed (a DUPLICATE, STATUS or LAYOUT row, an UNQUOTED row (quote the value it names), or a PATH_MISSING row for a path it named) before you go on; name\nrows about other entries to the user rather than fixing them unasked. If the script is missing or prints nothing,\nsay the registry check did not run, then re-read the entries you wrote against the rules in the file's header.\n\n---\n",".claude/skills/architecture-review/SKILL.md":"---\nname: architecture-review\ndescription: \"Traceability matrix mapping GDD requirements to ADRs. Finds gaps, cross-ADR conflicts, engine compatibility. PASS/CONCERNS/NOT ASSESSED/FAIL.\"\nargument-hint: \"[focus: full | coverage | consistency | engine | rtm | single-gdd path/to/gdd.md]\"\nuser-invocable: true\nallowed-tools: Read, Glob, Grep, Write, Edit, Agent, AskUserQuestion, Bash(bash \"*/.claude/skills/architecture-review/../../hooks/yaml-helper.sh\" resolve_config *), Bash(bash .claude/scripts/review-receipts.sh check *), Bash(bash .claude/scripts/review-receipts.sh hash *), Bash(bash .claude/scripts/adr-dep-graph.sh*), Bash(bash .claude/scripts/registry.sh validate*)\nmodel: opus\n---\n\n!`bash \"${CLAUDE_SKILL_DIR}/../../hooks/yaml-helper.sh\" resolve_config --keys automation,workflow`\n\n# Architecture Review\n\nThe architecture review validates that the complete body of architectural decisions\ncovers all game design requirements, is internally consistent, and correctly targets\nthe project's pinned engine version. It is the quality gate between Technical Setup\nand Pre-Production.\n\n**Argument modes:**\n- **No argument / `full`**: Full review — all phases\n- **`coverage`**: Traceability only — which GDD requirements have no ADR\n- **`consistency`**: Cross-ADR conflict detection only\n- **`engine`**: Engine compatibility audit only\n- **`single-gdd [path]`**: Review architecture coverage for one specific GDD\n- **`rtm`**: Requirements Traceability Matrix — extends the standard matrix\n to include story file paths and test file paths; outputs\n `docs/architecture/requirements-traceability.md` with the full\n GDD requirement → ADR → Story → Test chain. Use in Production phase when\n stories and tests exist.\n\n---\n\nEvery `AskUserQuestion` call follows `.claude/docs/automation-modes.md`\n(collaborative asks always · guided major-only · autonomous logs and proceeds;\n`automation_always_ask` categories always prompt).\n\n**`workflow`** (see `.claude/docs/workflow-modes.md`):\n- `full` — full traceability matrix across all GDDs and all ADRs.\n- `standard` — reduced scope: architecture doc + critical ADRs only.\n- `minimal` — not applicable (no architecture doc required).\n\n## Phase 1: Load Everything\n\n**Read `references/1-load.md` now and follow it** — this phase's steps are in that file, not here. Read it again if the conversation was compacted or resumed during this phase.\n\n## Phase 2: Extract Technical Requirements from Every GDD\n\n**Read `references/2-extract-requirements.md` now and follow it** — this phase's steps are in that file, not here. Read it again if the conversation was compacted or resumed during this phase.\n\n## Phase 3: Build the Traceability Matrix\n\n**Read `references/3-traceability.md` now and follow it** — this phase's steps are in that file, not here. Read it again if the conversation was compacted or resumed during this phase.\n\n## Phase 4: Cross-ADR Conflict Detection\n\n**Read `references/4-conflicts.md` now and follow it** — this phase's steps are in that file, not here. Read it again if the conversation was compacted or resumed during this phase.\n\n## Phase 5: Engine Compatibility Cross-Check\n\n**Read `references/5-engine.md` now and follow it** — this phase's steps are in that file, not here. Read it again if the conversation was compacted or resumed during this phase.\n\n## Phase 6: Architecture Document Coverage\n\n**Read `references/6-document-coverage.md` now and follow it** — this phase's steps are in that file, not here. Read it again if the conversation was compacted or resumed during this phase.\n\n## Phase 7: Output the Review Report\n\n**Read `references/7-report.md` now and follow it** — this phase's steps are in that file, not here. Read it again if the conversation was compacted or resumed during this phase.\n\n## Phase 8: Write and Update Traceability Index\n\n**Read `references/8-write.md` now and follow it** — this phase's steps are in that file, not here. Read it again if the conversation was compacted or resumed during this phase.\n\n## Phase 9: Handoff\n\n**Read `references/9-handoff.md` now and follow it** — this phase's steps are in that file, not here. Read it again if the conversation was compacted or resumed during this phase.\n\n## Error Recovery Protocol\n\n**First, verify the artifact.** If the return contract named a path, check the\npath exists before treating the phase as done — **a named artifact that is not\non disk is a failed phase, however fluent the response reads.** An agent can\nburn a full phase and return a plausible preamble having written nothing, which\nis neither BLOCKED nor an error nor \"fails to complete\", so the trigger below\nnever fires. Resume it naming the unmet contract; the context is\nusually still there.\n\nIf any spawned agent returns BLOCKED, errors, or fails to complete: **surface it\nimmediately, don't proceed past a dependency it blocks, and always produce a\npartial report** (retry scope here = fewer GDDs / single-system). Full procedure:\n`.claude/docs/error-recovery-protocol.md`.\n\n---\n\n## Collaborative Protocol\n\n**Applies in `collaborative` mode (the default).** For `guided` and\n`autonomous` modes, see `.claude/docs/automation-modes.md` — the rules below\ndescribe what collaborative mode requires, not universal behavior.\n\n1. **Read silently** — do not narrate every file read\n2. **Show the matrix** — present the full traceability matrix before any write\n approval; let the user see the state\n3. **Don't guess** — if a requirement is ambiguous, ask: \"Is [X] a technical\n requirement or a design preference?\"\n4. **Draft before approval** — always show the content that will be written (the\n report, the updated ADR section, the systems-index row) inline in the conversation\n before requesting approval. Never ask to write something the user has not yet seen.\n5. **Use `AskUserQuestion` for write approvals** — plain text \"May I?\" is not\n sufficient. Use the structured tool with labeled options [A]/[B]/[C] so the\n user can choose between \"write now\", \"show full draft first\", and \"not yet\".\n Multi-file changesets must list every file and what changes, then ask once\n with grouped options — not a separate plain-text question per file.\n6. **Non-blocking** — the verdict is advisory; the user decides whether to continue\n despite CONCERNS or even FAIL findings\n",".claude/skills/architecture-review/references/1-load.md":"# /architecture-review — Phase 1: Load Everything\n\n> Part of `/architecture-review`. `SKILL.md` names when to read this file; the settings it\n> resolved and the rules under its later headings still apply here.\n\n## Phase 1: Load Everything\n\n**In this file:**\n\n- Phase 1a — L0: Summary Scan (fast, low tokens)\n- Phase 1b — L1/L2: Targeted Section Load\n- Design Documents\n- Architecture Documents\n- Engine Reference\n- Project Standards\n\n### Phase 1a — L0: Summary Scan (fast, low tokens)\n\n**Freshness check before any scan.** A prior report can stand in for this run\nonly if nothing it rests on has changed: the documents, the engine reference,\nthe project config, this skill, and the kind of review that produced it.\n\nIn `rtm` mode, skip the check and say so — *\"Freshness check: not run — rtm\nbuilds the matrix fresh, because stories and tests change without any review\ninput changing.\"*\n\nOtherwise locate the latest prior report — Glob\n`docs/architecture/architecture-review-*.md` and take the newest — and check\n**the review inputs**: every file the phases below read that can change a\nfinding or the verdict. `[engine]` is the lowercased `engine.name` from\n`project.yaml`, the value Phase 5 uses; with no engine configured, leave the two\nengine-reference paths out.\n\n```\nBash: bash .claude/scripts/review-receipts.sh check \"[latest-report]\" docs/architecture/adr-*.md design/gdd/*.md docs/architecture/tr-registry.yaml docs/architecture/architecture.md docs/engine-reference/[engine]/*.md docs/engine-reference/[engine]/modules/*.md project.yaml .claude/docs/technical-preferences.md docs/consistency-failures.md .claude/skills/architecture-review/SKILL.md .claude/skills/architecture-review/references/*.md\n```\n\nPhase 8 stamps the same list into this run's report; keep the two identical,\nand add any file a phase starts reading to both. The check also compares every\nfile the prior report stamped, named here or not, and prints `GONE:` for one\nthat no longer exists.\n\nThen read the prior report's `Mode:` and `Workflow:` lines. It **covers** this\nrun only when its Mode is this run's mode (for `single-gdd`, the same path) or\n`full`, and its Workflow is this run's resolved `workflow` or `full`. A report\nwithout those lines was written before they existed and covers nothing.\n\n- **Any `UNRESOLVED`** — check this FIRST; it disqualifies every option\n below. A glob matched no file, so that whole document class was never\n examined and the comparison covered less than it appears to. Say which\n pattern came back unresolved, and neither stand on the prior report nor\n scope a re-run from it: an ADR or GDD directory that is empty, renamed or\n misspelled is a finding about the project. Run the review as asked; its\n verdict is NOT ASSESSED for the missing class (Phase 7), never a stop with\n no report. Never read a set of `UNCHANGED` lines as\n \"everything is current\" while an `UNRESOLVED` line is present — the set\n compared was not the set requested.\n- **The prior report does not cover this run** — check this second, whatever\n the other lines say. Say why: *\"The last report was a [mode] review at\n workflow [tier]; it does not cover this run.\"* Run the review as asked.\n Never offer to stand on it or to scope a re-run from it.\n- **Everything `UNCHANGED`** — nothing this review reads has changed since\n that report; re-running reproduces it. Surface the prior report's date,\n mode and verdict and offer via `AskUserQuestion`: `[A] Stand on the prior\n report (Recommended)` / `[B] Re-run the full review anyway` — `guided`\n proceeds with [A] and notes it; `autonomous` logs via `log_decision` and\n stands on the prior report.\n- **Only GDDs or ADRs `CHANGED`/`NEW`** — name them, then scope instead of\n re-running everything: recommend `/architecture-review single-gdd [path]`\n for just the changed systems. A full re-run stays available on request, and\n a `NEW` ADR warrants one.\n- **Anything else `CHANGED`, `NEW` or `GONE`** — a deleted GDD or ADR, the TR\n registry, `architecture.md`, the engine reference, `project.yaml`,\n `technical-preferences.md`, `consistency-failures.md`, or this skill's own\n files. These reach every phase, so recommend re-running the review as\n asked, never a `single-gdd` scope, and name each input with what it\n affects — e.g. *\"The engine reference changed after the\n last report: its deprecated-API audit, which `/gate-check` reads, was made\n against the old one.\"*\n- **`RECEIPT: NONE`** — no prior report, or one written before receipts\n existed. Proceed with the full review; this run's report will carry the\n first stamps.\n\nBefore reading any full document, use Grep to extract `## Summary` sections\nfrom all GDDs and ADRs:\n\n```\nGrep pattern=\"## Summary\" glob=\"design/gdd/*.md\" output_mode=\"content\" -A 4\nGrep pattern=\"## Summary\" glob=\"docs/architecture/adr-*.md\" output_mode=\"content\" -A 3\n```\n\n**Fail open on a missing Summary.** Establish the denominator: glob\n`design/gdd/*.md` and count **N**. A scan matching fewer than N means those GDDs\npredate `## Summary` (`/design-system` emits it, but older GDDs lack it) — never\ntreat an absent Summary as a system out of scope. A zero-match scan means \"no GDD\ncarries a Summary yet\", not \"nothing to review\": full-read the unmatched set.\n\nFor `single-gdd [path]` mode: use the target GDD's summary to identify which\nADRs reference the same system (Grep ADRs for the system name), then load only\nthose ADRs' sections per Phase 1b. Skip unrelated GDDs entirely.\n\nFor `engine` mode: load ADR sections only — GDDs are not needed for engine checks.\nIn practice this is the `## Engine Compatibility` scan alone.\n\nFor `coverage` or `full` mode: proceed to Phase 1b for the full in-scope set.\n**This is a section load, not a full-file load** — see below for why, and for the\nnarrow cases that still justify escalating to a whole document.\n\n### Phase 1b — L1/L2: Targeted Section Load\n\nLoad the sections the later phases actually consume — **not whole files**. This\nskill reads the two largest document sets in the project (every GDD *and* every\nADR); at realistic sizes a full load of both exhausts the context window before\nPhase 2 starts, and most of what it loads is narrative this skill never uses.\n\n**Establish the denominator first.** Glob `design/gdd/*.md` and count **N_gdd**;\nglob `docs/architecture/adr-*.md` and count **N_adr**. Report both. A section\nscan matching fewer than the denominator means those documents lack the section —\n**never treat an absent section as an absent document.** The scan narrows the\n*read* set; it never shrinks the *in-scope* set.\n\n### Design Documents\n\nPhase 2 extracts *technical requirements* — data structures, performance\nconstraints, engine capabilities, cross-system communication, persistence,\nthreading, platform needs. Those live in a known set of sections; Overview and\nPlayer Fantasy are narrative and yield none.\n\n```\nGrep pattern=\"^## (Detailed Rules|Detailed Design|Formulas|Dependencies|Tuning Knobs|Acceptance Criteria)\" glob=\"design/gdd/*.md\" output_mode=\"content\" -A 40\n```\n\nAccept **either** `## Detailed Rules` or `## Detailed Design` — the design\nstandard and the GDD template disagree on the name and they denote the same\nrequired section. Full-read a single GDD only when a scanned section\ncross-references material outside itself, or when a GDD matched zero sections\n(it predates the template — read it whole and say so).\n\n- `design/gdd/systems-index.md` — the authoritative list of systems; read whole (small, and it is an index)\n\n### Architecture Documents\n\nPhases 3–5 need the traceability table, the decision itself, engine claims, and\nthe dependency edges — not Context, Consequences, Alternatives, Migration Plan or\nValidation Criteria, which explain *why* a decision was made.\n\n```\nGrep pattern=\"^## (Status|Decision|GDD Requirements Addressed|Engine Compatibility|ADR Dependencies|Performance Implications)\" glob=\"docs/architecture/adr-*.md\" output_mode=\"content\" -A 30\n```\n\nInterpret against **N_adr**, and distinguish the two zero-match cases — they are\nnot the same finding:\n\n| Result | Meaning | Action |\n|---|---|---|\n| N_adr matches | Normal. | Proceed on the scanned sections. |\n| Some ADRs match, some do not | Those ADRs are missing sections. | Record each as a **structural gap** in the Phase 7 report — a missing `## GDD Requirements Addressed` is itself a traceability finding. |\n| **0 matches, N_adr > 0** | **Malformed ADRs**, not \"no architecture\". | \"[N_adr] ADRs found, none carries a scannable section — run `/architecture-decision retrofit [file]` on each.\" Do **not** report zero coverage; that would read as a design failure when it is a format failure. |\n\nEscalate to a full read of one ADR only when judging a conflict needs its\nreasoning (Phase 4) — that is a per-ADR decision, not a blanket load.\n\n- `docs/architecture/architecture.md` if it exists\n\n### Engine Reference\n- `docs/engine-reference/[engine]/VERSION.md`\n- `docs/engine-reference/[engine]/breaking-changes.md`\n- `docs/engine-reference/[engine]/deprecated-apis.md`\n- **Only the module docs the in-scope ADRs actually name** — take the union of\n each ADR's `References Consulted` and `Post-Cutoff APIs Used` fields (already\n captured by the `## Engine Compatibility` scan above) and read those files.\n Reading the whole `modules/` directory loads engine subsystems the project may\n not use at all. If no ADR names any module, read none and note it: Phase 5\n cannot cross-check engine claims that were never made.\n\n### Project Standards\n- `project.yaml` — `naming.*` and `performance.*`; plus `.claude/docs/technical-preferences.md` for those keys when absent and for forbidden patterns / allowed libraries\n\nReport a count: \"Loaded [N] GDDs, [M] ADRs, engine: [name + version].\"\n\n**Also read `docs/consistency-failures.md`** if it exists. Extract entries with\nDomain matching the systems under review (Architecture, Engine, or any GDD domain\nbeing covered). Surface recurring patterns as a \"Known conflict-prone areas\" note\nat the top of the Phase 4 conflict detection output.\n\n---\n",".claude/skills/architecture-review/references/2-extract-requirements.md":"# /architecture-review — Phase 2: Extract Technical Requirements\n\n> Part of `/architecture-review`. `SKILL.md` names when to read this file; the settings it\n> resolved and the rules under its later headings still apply here.\n\n## Phase 2: Extract Technical Requirements from Every GDD\n\n### Pre-load the TR Registry\n\nBefore extracting any requirements, read `docs/architecture/tr-registry.yaml`\nif it exists. Index existing entries by `id` and by normalized `requirement`\ntext (lowercase, trimmed). This prevents ID renumbering across review runs.\n\nThen read the Technical Requirements Baseline in `docs/architecture/architecture.md`\nif it exists. `/create-architecture` numbers each requirement the registry did not\nhold as `(provisional)`, from the registry's next free ID, and ADRs written from\nthe baseline may already cite those IDs.\n\nFor each requirement you extract, the matching rule is:\n1. **Exact/near match** to an existing registry entry for the same system →\n reuse that entry's TR-ID unchanged. Update the `requirement` text in the\n registry only if the GDD wording changed (same intent, clearer phrasing) —\n add a `revised: [date]` field.\n2. **Match to a provisional baseline row** (same system, same intent) → keep that\n ID when the registry holds no entry with it, active or retired: registering it\n is what makes it permanent. When the ID is taken, assign the next available one\n and list the rename (`TR-[system]-004 (provisional) → TR-[system]-006`) in the\n report, so the ADRs and stories that cite it can be updated.\n3. **No match** → assign a new ID: next available `TR-[system]-NNN` for that\n system, starting from the highest existing sequence + 1, skipping any ID a\n provisional baseline row holds.\n4. **Ambiguous** (partial match, intent unclear) → ask the user:\n > \"Does '[new requirement text]' refer to the same requirement as\n > `TR-[system]-NNN: [existing text]'`, or is it a new requirement?\"\n User answers: \"Same requirement\" (reuse ID) or \"New requirement\" (new ID).\n\nFor any requirement with `status: deprecated` in the registry — skip it.\nIt was removed from the GDD intentionally.\n\nFor each GDD, read it and extract all **technical requirements** — things the\narchitecture must provide for the system to work. A technical requirement is any\nstatement that implies a specific architectural decision.\n\nCategories to extract:\n\n| Category | Example |\n|----------|---------|\n| **Data structures** | \"Each entity has health, max health, status effects\" → needs a component/data schema |\n| **Performance constraints** | \"Collision detection must run at 60fps with 200 entities\" → physics budget ADR |\n| **Engine capability** | \"Inverse kinematics for character animation\" → IK system ADR |\n| **Cross-system communication** | \"Damage system notifies UI and audio simultaneously\" → event/signal architecture ADR |\n| **State persistence** | \"Player progress persists between sessions\" → save system ADR |\n| **Threading/timing** | \"AI decisions happen off the main thread\" → concurrency ADR |\n| **Platform requirements** | \"Supports keyboard, gamepad, touch\" → input system ADR |\n\nFor each GDD, produce a structured list:\n\n```\nGDD: [filename]\nSystem: [system name]\nTechnical Requirements:\n TR-[GDD]-001: [requirement text] → Domain: [Physics/Rendering/etc]\n TR-[GDD]-002: [requirement text] → Domain: [...]\n```\n\nThis becomes the **requirements baseline** — the complete set of what the\narchitecture must cover.\n\n---\n",".claude/skills/architecture-review/references/3-traceability.md":"# /architecture-review — Phases 3 and 3b: Traceability Matrix and Story Linkage\n\n> Part of `/architecture-review`. `SKILL.md` names when to read this file; the settings it\n> resolved and the rules under its later headings still apply here.\n\n## Phase 3: Build the Traceability Matrix\n\n**In this file:**\n\n- Step 3b-1 — Load stories\n- Step 3b-2 — Load test files\n- Step 3b-3 — Build the extended RTM\n\nFor each technical requirement extracted in Phase 2, search the ADRs:\n\n1. Use the ADRs **already loaded in Phase 1b** — do not re-read them. Extract each\n ADR's \"GDD Requirements Addressed\" section from what is already in context.\n (If Phase 1b ran in a mode that did not load every ADR, `Grep pattern=\"## GDD\n Requirements Addressed\" glob=\"docs/architecture/adr-*.md\" output_mode=\"content\"\n -A 15` fills the gap without a full re-read.)\n2. Check if it explicitly references the requirement or its GDD\n3. Check if the ADR's decision text implicitly covers the requirement\n4. Mark coverage status:\n\n| Status | Meaning |\n|--------|---------|\n| ✅ **Covered** | An **Accepted** ADR explicitly addresses this requirement |\n| 🟡 **Covered (Proposed)** | An ADR addresses it, but that ADR is still `Proposed` |\n| ⚠️ **Partial** | An ADR partially covers this, or coverage is ambiguous |\n| ❌ **Gap** | No ADR addresses this requirement |\n| ❓ **Not assessed** | The ADR is unreadable, or has no `## Status` section |\n\n> **Read each ADR's `## Status` before marking coverage — an unaccepted decision\n> is not coverage.** If `✅` meant only that *an ADR addresses this*, with no\n> status qualification, a requirement covered entirely by `Proposed` ADRs would\n> count as covered and this review could return **PASS: All requirements\n> covered** over an architecture nobody had accepted. Four skills downstream\n> (`create-control-manifest`, `create-epics`, `create-stories`, `gate-check`)\n> require `Accepted`, so a PASS on that basis sends work forward that every one\n> of them will refuse.\n>\n> `🟡` is **not** a pass state: it caps the verdict at **CONCERNS**, and names the\n> route out — `/architecture-decision accept ADR-NNNN`. That route is the only\n> thing that moves an ADR to `Accepted`; without it, grading `Proposed` as\n> covered would be the only option, which is why it must never be graded so.\n\nBuild the full matrix:\n\n```\n## Traceability Matrix\n\n| Requirement ID | GDD | System | Requirement | ADR Coverage | Status |\n|---------------|-----|--------|-------------|--------------|--------|\n| TR-combat-001 | combat.md | Combat | Hitbox detection < 1 frame | ADR-0003 | ✅ |\n| TR-combat-002 | combat.md | Combat | Combo window timing | — | ❌ GAP |\n| TR-inventory-001 | inventory.md | Inventory | Persistent item storage | ADR-0005 | ✅ |\n```\n\nCount the totals: X covered, Y partial, Z gaps.\n\n---\n\n## Phase 3b: Story and Test Linkage (RTM mode only)\n\n*Skip this phase unless the argument is `rtm` or `full` with stories present.*\n\nThis phase extends the Phase 3 matrix to include the story that implements\neach requirement and the test that verifies it — producing the full\nRequirements Traceability Matrix (RTM).\n\n### Step 3b-1 — Load stories\n\nGlob `production/epics/**/*.md` (excluding EPIC.md index files) to establish the\ndenominator. Then collect the fields with **targeted section greps, not a full\nread of each story** — the same two-grep form `/test-evidence-review` uses for\nthis identical extraction:\n\n```\nGrep pattern=\"## Test Evidence\" glob=\"production/epics/**/story-*.md\" output_mode=\"content\" -A 8\nGrep pattern=\"TR-\" glob=\"production/epics/**/story-*.md\" output_mode=\"content\"\n```\n\n- **TR-ID** — from the second grep.\n- **Test file path** — under `## Test Evidence`, captured by the first grep's `-A 8`.\n- **Status** — from the story header; add `Grep pattern=\"^> \\*\\*Status\\*\\*\"` if not already captured.\n- **Story path and title** — from the file name and path; no read at all.\n\nFull-read a story only when its Test Evidence section is missing or ambiguous.\n\n### Step 3b-2 — Load test files\n\nGlob the engine's test root (`.claude/docs/directory-structure.md`): Godot\n`tests/unit/**/*_test.*` and `tests/integration/**/*_test.*`; Unity\n`Assets/Tests/**/*Tests.cs`; Unreal `Source/*/Private/Tests/**/*.cpp`. With no\nengine configured, say the test index could not be built rather than reading an\nempty glob as \"no tests\". Build an index: system → [test file paths].\n\nFor each test file path from Step 3b-1, confirm via Glob whether the file\nactually exists. Note MISSING if the stated path does not exist.\n\n### Step 3b-3 — Build the extended RTM\n\nFor each TR-ID in the Phase 3 matrix, add:\n- **Story**: the story file path(s) that reference this TR-ID (may be multiple)\n- **Test File**: the test file path stated in the story's Test Evidence section\n- **Test Status**: COVERED (test file exists) / MISSING (path stated but not\n found) / NONE (no test path stated, story type may be Visual/Feel/UI) /\n NO STORY (requirement has no story yet — pre-production gap)\n\nExtended matrix format:\n\n```\n## Requirements Traceability Matrix (RTM)\n\n| TR-ID | GDD | Requirement | ADR | Story | Test File | Test Status |\n|-------|-----|-------------|-----|-------|-----------|-------------|\n| TR-combat-001 | combat.md | Hitbox < 1 frame | ADR-0003 | story-001-hitbox.md | tests/unit/combat/hitbox_test.gd | COVERED |\n| TR-combat-002 | combat.md | Combo window | — | story-002-combo.md | — | NONE (Visual/Feel) |\n| TR-inventory-001 | inventory.md | Persistent storage | ADR-0005 | — | — | NO STORY |\n```\n\nRTM coverage summary:\n- COVERED: [N] — requirements with ADR + story + passing test\n- MISSING test: [N] — story exists but test file not found\n- NO STORY: [N] — requirements with ADR but no story yet\n- NO ADR: [N] — requirements without architectural coverage (from Phase 3 gaps)\n- Full chain complete (COVERED): [N/total] ([%])\n\n---\n",".claude/skills/architecture-review/references/4-conflicts.md":"# /architecture-review — Phase 4: Cross-ADR Conflict Detection\n\n> Part of `/architecture-review`. `SKILL.md` names when to read this file; the settings it\n> resolved and the rules under its later headings still apply here.\n\n## Phase 4: Cross-ADR Conflict Detection\n\nCompare every ADR against every other ADR to detect contradictions. A conflict\nexists when:\n\n- **Data ownership conflict**: Two ADRs claim exclusive ownership of the same data\n- **Integration contract conflict**: ADR-A assumes System X has interface Y, but\n ADR-B defines System X with a different interface\n- **Performance budget conflict**: ADR-A allocates N ms to physics, ADR-B allocates\n N ms to AI, together they exceed the total frame budget\n- **Dependency cycle**: ADR-A says System X initialises before Y; ADR-B says Y\n initialises before X\n- **Architecture pattern conflict**: ADR-A uses event-driven communication for a\n subsystem; ADR-B uses direct function calls to the same subsystem\n- **State management conflict**: Two ADRs define authority over the same game state\n (e.g. both Combat ADR and Character ADR claim to own the health value)\n\nFor each conflict found:\n\n```\n## Conflict: [ADR-NNNN] vs [ADR-MMMM]\nType: [Data ownership / Integration / Performance / Dependency / Pattern / State]\nADR-NNNN claims: [...]\nADR-MMMM claims: [...]\nImpact: [What breaks if both are implemented as written]\nResolution options:\n 1. [Option A]\n 2. [Option B]\n```\n\n### ADR Dependency Ordering\n\nAfter conflict detection, analyse the dependency graph across all ADRs.\n\n**Build the graph deterministically — do not trace it by hand:**\n\n```\nBash: bash .claude/scripts/adr-dep-graph.sh\n```\n\nIt collects every `Depends On` edge, finds the cycles and the order, and emits\n`ADRS:` / `EDGES:` / `NO_DEPS_SECTION:` / `UNFILLED_DEPS:` / `CYCLE:` /\n`BLOCKED_BY_CYCLE:` / `ORDER:`. A model tracing A→B→C→A across\na dozen ADRs eventually misses an edge; the algorithm cannot. It reports\nobservations, not a verdict — you apply the meaning below.\n\n**`NO_DEPS_SECTION` and `UNFILLED_DEPS` are load-bearing**: they make \"no cycles\nbecause the graph is clean\" distinguishable from \"no cycles because half the ADRs\ndeclare no dependencies, or left the template's placeholder in the row\". Report\nthe second case as a structural gap, never as a clean graph, and name each\n`UNFILLED_DEPS` ADR as unfilled: what it depends on is unknown, not none.\n\nThen interpret:\n\n1. **Topological sort**: the `ORDER:` row, as emitted — ADRs with no\n dependencies come first (Foundation), ADRs that depend on those come next, etc.\n Do not re-sort it by hand. An ADR in `NO_DEPS_SECTION` or `UNFILLED_DEPS` sits\n in it as if it depended on nothing: mark it so.\n2. **Flag unresolved dependencies**: cross the `EDGES:` list against the `## Status`\n values already scanned in Phase 1b. If ADR-A depends on an ADR that is still\n `Proposed` or does not exist, flag it:\n ```\n ⚠️ ADR-0005 depends on ADR-0002 — but ADR-0002 is still Proposed.\n ADR-0005 cannot be safely implemented until ADR-0002 is Accepted.\n ```\n3. **Cycle detection**: every `CYCLE:` line the script emitted is a\n `DEPENDENCY CYCLE` — report each one, with the edges its line shows (one of\n them is the edge to cut). A `BLOCKED_BY_CYCLE:` ADR is on no cycle: it waits\n for one to break, so list it as blocked, never as part of the cycle, and never\n suggest cutting its own edges. Do not re-derive them by hand:\n ```\n 🔴 DEPENDENCY CYCLE: ADR-0003 → ADR-0006 → ADR-0003\n This cycle must be broken before either can be implemented.\n ```\n4. **Output recommended implementation order**:\n ```\n ### Recommended ADR Implementation Order (topologically sorted)\n Foundation (no dependencies):\n 1. ADR-0001: [title]\n 2. ADR-0003: [title]\n Depends on Foundation:\n 3. ADR-0002: [title] (requires ADR-0001)\n 4. ADR-0005: [title] (requires ADR-0003)\n Feature layer:\n 5. ADR-0004: [title] (requires ADR-0002, ADR-0005)\n ```\n\n---\n",".claude/skills/architecture-review/references/5-engine.md":"# /architecture-review — Phases 5 and 5b: Engine Cross-Check and Design Revision Flags\n\n> Part of `/architecture-review`. `SKILL.md` names when to read this file; the settings it\n> resolved and the rules under its later headings still apply here.\n\n## Phase 5: Engine Compatibility Cross-Check\n\n**In this file:**\n\n- Version Consistency\n- Post-Cutoff API Consistency\n- Deprecated API Check\n- Missing Engine Compatibility Sections\n- Engine Specialist Consultation\n\nAcross all ADRs, check for engine consistency:\n\n### Version Consistency\n- Do all ADRs that mention an engine version agree on the same version?\n- If any ADR was written for an older engine version, flag it as potentially stale\n\n### Post-Cutoff API Consistency\n- Collect all \"Post-Cutoff APIs Used\" fields from all ADRs\n- For each, verify against the relevant module reference doc\n- Check that no two ADRs make contradictory assumptions about the same post-cutoff API\n\n### Deprecated API Check\n- Grep all ADRs for API names listed in `deprecated-apis.md`\n- Flag any ADR referencing a deprecated API\n\n### Missing Engine Compatibility Sections\n- List all ADRs that are missing the Engine Compatibility section entirely\n- These are blind spots — their engine assumptions are unknown\n\nOutput format:\n```\n### Engine Audit Results\nEngine: [name + version]\nADRs with Engine Compatibility section: X / Y total\n\nDeprecated API References:\n - ADR-0002: uses [deprecated API] — deprecated since [version]\n\nStale Version References:\n - ADR-0001: written for [older version] — current project version is [version]\n\nPost-Cutoff API Conflicts:\n - ADR-0004 and ADR-0007 both use [API] with incompatible assumptions\n```\n\n---\n\n### Engine Specialist Consultation\n\nAfter completing the engine audit above, spawn the **primary engine specialist** via `Agent` for a domain-expert second opinion:\n- Resolve the primary specialist: `-specialist` derived from `engine.name` in `project.yaml` (Godot→`godot-specialist`, Unity→`unity-specialist`, Unreal→`unreal-specialist`); if `engine.name` is absent or empty, read the Primary line of the `## Engine Specialists` section in `.claude/docs/technical-preferences.md`\n- If no engine is configured (neither source yields an engine), skip this consultation **Record ``Engine validation: NOT ASSESSED — no engine configured (`engine.name` unset in `project.yaml`)`` in this run's output.** A skipped check that says nothing is indistinguishable from a check that passed; the reader cannot tell engine guidance was never sought.\n- Spawn `subagent_type: [primary specialist]` with: all ADRs that contain engine-specific decisions or `Post-Cutoff APIs Used` fields, the engine reference docs, and the Phase 5 audit findings. Ask them to:\n 1. Confirm or challenge each audit finding — specialists may know of engine nuances not captured in the reference docs\n 2. Identify engine-specific anti-patterns in the ADRs that the audit may have missed (e.g., using the wrong Godot node type, Unity component coupling, Unreal subsystem misuse)\n 3. Flag ADRs that make assumptions about engine behaviour that differ from the actual pinned version\n\nIncorporate additional findings under `### Engine Specialist Findings` in the Phase 5 output. These feed into the final verdict — specialist-identified issues carry the same weight as audit-identified issues.\n\n---\n\n## Phase 5b: Design Revision Flags (Architecture → GDD Feedback)\n\nFor each **HIGH RISK engine finding** from Phase 5, check whether any GDD makes an\nassumption that the verified engine reality contradicts.\n\nSpecific cases to check:\n\n1. **Post-cutoff API behaviour differs from training-data assumptions**: If an ADR\n records a verified API behaviour that differs from the default LLM assumption,\n check all GDDs that reference the related system. Look for design rules written\n around the old (assumed) behaviour.\n\n2. **Known engine limitations in ADRs**: If an ADR records a known engine limitation\n (e.g. \"Jolt ignores HingeJoint3D damp\", \"D3D12 is now the default backend\"), check\n GDDs that design mechanics around the affected feature.\n\n3. **Deprecated API conflicts**: If Phase 5 flagged a deprecated API used in an ADR,\n check whether any GDD contains mechanics that assume the deprecated API's behaviour.\n\nFor each conflict found, record it in the GDD Revision Flags table:\n\n```\n### GDD Revision Flags (Architecture → Design Feedback)\nThese GDD assumptions conflict with verified engine behaviour or accepted ADRs.\nThe GDD should be revised before its system enters implementation.\n\n| GDD | Assumption | Reality (from ADR/engine-reference) | Action |\n|-----|-----------|--------------------------------------|--------|\n| combat.md | \"Use HingeJoint3D damp for weapon recoil\" | Jolt ignores damp — ADR-0003 | Revise GDD |\n```\n\nIf no revision flags are found, write: \"No GDD revision flags — all GDD assumptions\nare consistent with verified engine behaviour.\"\n\nBefore asking, display the proposed change inline — show the current systems-index row for each flagged GDD and the proposed updated row side by side so the user can see exactly what will change.\n\nThen use `AskUserQuestion`:\n- \"I found [N] GDD revision flag(s). May I update the systems index?\"\n - [A] Yes — apply all [N] updates to the systems index now\n - [B] Show me the full diff first, then ask again\n - [C] No — leave the systems index unchanged for now\n\nIf [A]: apply the updates. Status field must be exactly `Needs Revision` — no parentheticals\n(other skills match that exact string and parentheticals break the match).\nIf [B]: display the complete proposed systems-index section, then re-ask with `AskUserQuestion`.\n\n---\n",".claude/skills/architecture-review/references/6-document-coverage.md":"# /architecture-review — Phase 6: Architecture Document Coverage\n\n> Part of `/architecture-review`. `SKILL.md` names when to read this file; the settings it\n> resolved and the rules under its later headings still apply here.\n\n## Phase 6: Architecture Document Coverage\n\n**If `docs/architecture/architecture.md` does not exist, say so in the report** —\n`Architecture document coverage: NOT ASSESSED — no docs/architecture/architecture.md`\n— and carry it into the Phase 7 verdict per the trigger list below. Silently\nproducing no Phase 6 findings reads as an architecture document that was checked\nand found clean, which is the opposite of what happened.\n\nIf it exists, validate it against GDDs:\n\n- Does every system from `systems-index.md` appear in the architecture layers?\n- Does the data flow section cover all cross-system communication defined in GDDs?\n- Do the API boundaries support all integration requirements from GDDs?\n- Are there systems in the architecture doc that have no corresponding GDD\n (orphaned architecture)?\n\n---\n",".claude/skills/architecture-review/references/7-report.md":"# /architecture-review — Phase 7: Output the Review Report\n\n> Part of `/architecture-review`. `SKILL.md` names when to read this file; the settings it\n> resolved and the rules under its later headings still apply here.\n\n## Phase 7: Output the Review Report\n\n```\n## Architecture Review Report\nDate: [date]\nMode: [full / coverage / consistency / engine / single-gdd path/to/gdd.md]\nWorkflow: [the resolved workflow tier]\nEngine: [name + version, or \"none configured\"]\nGDDs Reviewed: [N]\nADRs Reviewed: [M]\n\n[the receipt — one Reviewed-Content-Hash line per review input, taken in\n Phase 8 when the report is written, never in this draft. Phase 1a's freshness\n check reads them, with the Mode and Workflow lines, on the next run]\n\n---\n\n### Traceability Summary\nTotal requirements: [N]\n✅ Covered: [X]\n⚠️ Partial: [Y]\n❌ Gaps: [Z]\n\n### Coverage Gaps (no ADR exists)\nFor each gap:\n ❌ TR-[id]: [GDD] → [system] → [requirement]\n Suggested ADR: \"/architecture-decision [suggested title]\"\n Domain: [Physics/Rendering/etc]\n Engine Risk: [LOW/MEDIUM/HIGH]\n\n### Cross-ADR Conflicts\n[List all conflicts from Phase 4]\n\n### ADR Dependency Order\n[Topologically sorted implementation order from Phase 4 — dependency ordering section]\n[Unresolved dependencies and cycles if any]\n\n### GDD Revision Flags\n[GDD assumptions that conflict with verified engine behaviour — from Phase 5b]\n[Or: \"None — all GDD assumptions consistent with verified engine behaviour\"]\n\n### Engine Compatibility Issues\n[List all engine issues from Phase 5]\n\n### Architecture Document Coverage\n[List missing systems and orphaned architecture from Phase 6]\n\n---\n\n### Verdict: [PASS / NOT ASSESSED / CONCERNS / FAIL]\n\nPASS: All requirements covered by **Accepted** ADRs, no conflicts, engine consistent\nNOT ASSESSED: The review could not be performed over its stated scope — name why\nCONCERNS: Some gaps, partial coverage, or coverage resting on `Proposed` ADRs,\n but no blocking conflicts\nFAIL: Critical gaps (Foundation/Core layer requirements uncovered),\n or blocking cross-ADR conflicts detected\n\n**`NOT ASSESSED` ranks above PASS and below CONCERNS and FAIL.** Emit it when:\n\n- **No ADRs exist, or none could be read.** Zero requirements traced is not full\n coverage — it is an untraced architecture, and a matrix of `❌ Gap` rows at\n least says so while an empty matrix says nothing.\n- **The requirement source is missing** — no `tr-registry.yaml` and no GDD\n requirements to trace *from*. A review with no left-hand column cannot report\n coverage; it can only report that it had nothing to compare.\n- **An ADR is unreadable or has no `## Status`**, so its rows are `❓` and their\n coverage is unknown rather than absent.\n- **Phase 6 could not run** — no `docs/architecture/architecture.md`. It must\n appear as a named `NOT ASSESSED` **line item** in the report rather than as\n absent findings. ADR traceability can still be complete, so a CONCERNS or FAIL\n finding elsewhere still stands; but in `full` mode, whose scope includes\n Phase 6, the verdict cannot be PASS — a review that could not look at part of\n its scope has not shown that part is sound, so it is NOT ASSESSED.\n- **No engine is configured** (`full` and `engine` modes) — Phase 5 has no pinned\n engine reference to audit the ADRs against, and the specialist consultation was\n skipped. Record the `Engine validation: NOT ASSESSED` line item; like Phase 6\n above, it keeps the verdict from PASS.\n\nDo not resolve any of these to PASS on the grounds that no gap was *found*. No\ngap was looked for.\n\n### Blocking Issues (must resolve before PASS)\n[List items that must be resolved — FAIL verdict only]\n\n### Required ADRs\n[Prioritised list of ADRs to create, most foundational first]\n```\n\n---\n",".claude/skills/architecture-review/references/8-write.md":"# /architecture-review — Phase 8: Write and Update Traceability Index\n\n> Part of `/architecture-review`. `SKILL.md` names when to read this file; the settings it\n> resolved and the rules under its later headings still apply here.\n\n## Phase 8: Write and Update Traceability Index\n\n**In this file:**\n\n- The receipt is taken last\n- RTM Output (rtm mode only)\n- TR Registry Update\n- Reflexion Log Update\n- Session State Update\n\nUse `AskUserQuestion` for the write approval:\n- \"Review complete. What would you like to write?\"\n - [A] Write all three files — review report (`docs/architecture/architecture-review-[date].md`), traceability index (`docs/architecture/requirements-traceability.md`), TR registry (`docs/architecture/tr-registry.yaml`)\n - [B] Write review report only — `docs/architecture/architecture-review-[date].md`\n - [C] Don't write anything yet — I need to review the findings first\n\n**A `single-gdd` run saw one system**, so in that mode [A] writes the review\nreport and only that system's share of the other two files. Name it so in the\noption: \"…update [system]'s rows in the traceability index and its TR registry\nentries\". In `requirements-traceability.md`, replace that system's matrix rows\nand recompute the Coverage Summary, keeping every other system's rows as they\nare. When the index does not exist yet, write the report and the registry only,\nand say a full review creates the index. In the TR registry, append, update and\ndeprecate only that system's entries: another system's GDD was not read, so its\nentries are never proposed for deprecation.\n\nWhen Phase 4 found a 🔴 conflict and `docs/consistency-failures.md` exists, name\nthat file in option [A] as well — \"…and append [N] conflict entr(y/ies) to\n`docs/consistency-failures.md`\". Only [A] appends there (see Reflexion Log\nUpdate); [B] writes the report and nothing else.\n\n### The receipt is taken last\n\nWrite the review report after the TR registry update and the\n`consistency-failures.md` entries, and take its receipt lines at that moment —\nnever from the Phase 7 draft. Both files are review inputs: a receipt taken\nbefore this run edited them records the old content, and the next run reads\nthis run's own edit as `CHANGED`.\n\n```\nBash: bash .claude/scripts/review-receipts.sh hash docs/architecture/adr-*.md design/gdd/*.md docs/architecture/tr-registry.yaml docs/architecture/architecture.md docs/engine-reference/[engine]/*.md docs/engine-reference/[engine]/modules/*.md project.yaml .claude/docs/technical-preferences.md docs/consistency-failures.md .claude/skills/architecture-review/SKILL.md .claude/skills/architecture-review/references/*.md\n```\n\nIt is the same list as Phase 1a's check, with `[engine]` filled in the same way.\nAn optional input that does not exist prints `not stamped, no such file` and is\nleft out; that is expected. Paste the stamp lines into the report under its\nheader, where the Phase 7 template shows them.\n\n### RTM Output (rtm mode only)\n\nFor `rtm` mode, use `AskUserQuestion`:\n- \"May I write the full Requirements Traceability Matrix?\"\n - [A] Yes — write to `docs/architecture/requirements-traceability.md`\n - [B] Not yet — show me the full RTM data first, then ask again\n\nRTM file format:\n\n```markdown\n# Requirements Traceability Matrix (RTM)\n\n> Last Updated: [date]\n> Mode: /architecture-review rtm\n> Coverage: [N]% full chain complete (GDD → ADR → Story → Test)\n\n## How to read this matrix\n\n| Column | Meaning |\n|--------|---------|\n| TR-ID | Stable requirement ID from tr-registry.yaml |\n| GDD | Source design document |\n| ADR | Architectural decision governing implementation |\n| Story | Story file that implements this requirement |\n| Test File | Automated test file path |\n| Test Status | COVERED / MISSING / NONE / NO STORY |\n\n## Full Traceability Matrix\n\n| TR-ID | GDD | Requirement | ADR | Story | Test File | Status |\n|-------|-----|-------------|-----|-------|-----------|--------|\n[Full matrix rows from Phase 3b]\n\n## Coverage Summary\n\n| Status | Count | % |\n|--------|-------|---|\n| COVERED — full chain complete | [N] | [%] |\n| MISSING test — story exists, no test | [N] | [%] |\n| NO STORY — ADR exists, not yet implemented | [N] | [%] |\n| NO ADR — architectural gap | [N] | [%] |\n| **Total requirements** | **[N]** | **100%** |\n\n## Uncovered Requirements (Priority Fix List)\n\nRequirements where the full chain is broken, prioritised by layer:\n\n### Foundation layer gaps\n[list with suggested action per gap]\n\n### Core layer gaps\n[list]\n\n### Feature / Presentation layer gaps\n[list — lower priority]\n\n## History\n\n| Date | Full Chain % | Notes |\n|------|-------------|-------|\n| [date] | [%] | Initial RTM |\n```\n\n### TR Registry Update\n\nAlso ask: \"May I update `docs/architecture/tr-registry.yaml` with new requirement\nIDs from this review?\"\n\nIf yes, read the current `docs/architecture/tr-registry.yaml` again first:\nthe review read it at the start, and another skill or session may have changed\nit since. Build the update from that fresh read, never from the earlier copy,\nand keep every entry already in it. Then:\n- **Append** any new TR-IDs that weren't in the registry before this review\n- **Update** `requirement` text and `revised` date for any entries whose GDD\n wording changed (ID stays the same)\n- **Mark** `status: deprecated` for any registry entries whose GDD requirement\n no longer exists (confirm with user before marking deprecated; in `single-gdd`\n mode, only the reviewed system's entries)\n- **Mark** `status: \"superseded-by: TR-[system]-NNN\"` for an entry whose\n requirement was split or replaced, naming the new TR-ID(s). Keep the quotes:\n unquoted, the second colon makes the file invalid YAML\n- **Never** renumber or delete existing entries\n- Update the `last_updated` and `version` fields at the top\n\nAfter writing, run `bash .claude/scripts/registry.sh validate` and fix every row\nabout an entry this write added or changed (a DUPLICATE, STATUS or LAYOUT row,\nor a PATH_MISSING row for a path it named) before you go on; name rows about\nother entries to the user rather than fixing them unasked. If the script is\nmissing or prints nothing, say the registry check did not run, then re-read the\nentries you wrote against the rules in the file's header.\n\nThis ensures all future story files can reference stable TR-IDs that persist\nacross every subsequent architecture review.\n\n### Reflexion Log Update\n\nWhen the user chose Phase 8's [A] — the option that named this file — append\nany 🔴 CONFLICT entries found in Phase 4 to `docs/consistency-failures.md` (if\nthe file exists), before writing the review report (its receipt is taken last):\n\n```markdown\n### [YYYY-MM-DD] — /architecture-review — 🔴 CONFLICT\n**Domain**: Architecture / [specific domain e.g. State Ownership, Performance]\n**Documents involved**: [ADR-NNNN] vs [ADR-MMMM]\n**What happened**: [specific conflict — what each ADR claims]\n**Resolution**: [how it was or should be resolved]\n**Pattern**: [generalised lesson for future ADR authors in this domain]\n```\n\nOnly append CONFLICT entries — do not log GAP entries (missing ADRs are expected\nbefore the architecture is complete). Do not create the file if missing — only\nappend when it already exists.\n\n### Session State Update\n\nAfter writing all approved files, silently append to\n`production/session-state/active.md`:\n\n ## Session Extract — /architecture-review [date]\n - Verdict: [PASS / NOT ASSESSED / CONCERNS / FAIL]\n - Requirements: [N] total — [X] covered, [Y] partial, [Z] gaps\n - New TR-IDs registered: [N, or \"None\"]\n - GDD revision flags: [comma-separated GDD names, or \"None\"]\n - Top ADR gaps: [top 3 gap titles from the report, or \"None\"]\n - Report: docs/architecture/architecture-review-[date].md\n\nIf `active.md` does not exist, create it with this block as the initial content.\nConfirm in conversation: \"Session state updated.\"\n\nThe traceability index — written to `docs/architecture/requirements-traceability.md`,\nthe path `/propagate-design-change` and the Pre-Production gate read; `rtm` mode\nlater extends the same file with story and test columns — uses this format:\n\n```markdown\n# Architecture Traceability Index\nLast Updated: [date]\nEngine: [name + version]\n\n## Coverage Summary\n- Total requirements: [N]\n- Covered: [X] ([%])\n- Partial: [Y]\n- Gaps: [Z]\n\n## Full Matrix\n[Complete traceability matrix from Phase 3]\n\n## Known Gaps\n[All ❌ items with suggested ADRs]\n\n## Superseded Requirements\n[Requirements whose GDD was changed after the ADR was written]\n```\n\n---\n",".claude/skills/architecture-review/references/9-handoff.md":"# /architecture-review — Phase 9: Handoff\n\n> Part of `/architecture-review`. `SKILL.md` names when to read this file; the settings it\n> resolved and the rules under its later headings still apply here.\n\n## Phase 9: Handoff\n\nAfter completing the review and writing approved files, present:\n\n1. **Immediate actions**: List the top 3 ADRs to create (highest-impact gaps first,\n Foundation layer before Feature layer)\n2. **Pre-gate checklist**: Check whether these exist via Glob and mark each ✅ or ❌:\n - the engine's test root — `tests/unit/` and `tests/integration/` (Godot), `Assets/Tests/EditMode/` and `Assets/Tests/PlayMode/` (Unity), `Source//Private/Tests/` (Unreal) — if ❌: run `/test-setup`\n - `.github/workflows/tests.yml` — if ❌: run `/test-setup`\n - `design/accessibility-requirements.md` — if ❌: run `/ux-design`\n - `design/ux/interaction-patterns.md` — if ❌: run `/ux-design`\n Present ❌ items as required steps before gate-check. Do not offer `/gate-check`\n as an option if any item is ❌ — offer the missing skill to run instead.\n3. **Rerun trigger**: \"Re-run `/architecture-review` after each new ADR is written\n to verify coverage improves\"\n\nThen close with `AskUserQuestion` tailored to the pre-gate checklist state:\n- If ADR gaps remain or any pre-gate item is ❌:\n - \"Architecture review complete. What would you like to do next?\"\n - [A] Write a missing ADR — open a fresh session and run `/architecture-decision [system]`\n - [B] Run `/test-setup` — required before gate-check (only show if test infrastructure is ❌)\n - [C] Run `/ux-design` — required before gate-check (only show if UX/accessibility files are ❌)\n - [D] Stop here for this session\n- If all pre-gate checklist items are ✅ and no blocking ADR gaps remain:\n - \"Architecture review complete. All pre-gate items confirmed. What would you like to do next?\"\n - [A] Run `/gate-check pre-production`\n - [B] Write a missing ADR — open a fresh session and run `/architecture-decision [system]`\n - [C] Stop here for this session\n\n---\n",".claude/skills/art-bible/SKILL.md":"---\nname: art-bible\ndescription: \"Author the Art Bible — visual identity gating asset production. Run before /map-systems.\"\nargument-hint: \"[--review full|lean|solo]\"\nuser-invocable: true\nallowed-tools: Read, Glob, Grep, Write, Edit, Agent, AskUserQuestion, Bash(bash \"*/.claude/skills/art-bible/../../hooks/yaml-helper.sh\" resolve_config *)\nmodel: sonnet\n---\n\n!`bash \"${CLAUDE_SKILL_DIR}/../../hooks/yaml-helper.sh\" resolve_config --keys review_mode,automation,workflow,docs.density`\n\nResolved above — use as-is; `--review` overrides `review_mode`. No block →\ndefaults in `.claude/docs/config-resolution.md`.\n\n# Art Bible\n\n\n## Phase 0: Parse Arguments and Context Check\n\n\nSee `.claude/docs/director-gates.md` for the full check pattern. Individual gate definitions live in `.claude/docs/director-gates/[gate-id].md` — the spawned agent reads its own gate file; do not read it in the parent session.\n\n\nEvery `AskUserQuestion` call follows `.claude/docs/automation-modes.md`\n(collaborative asks always · guided major-only · autonomous logs and proceeds;\n`automation_always_ask` categories always prompt).\n\n**`docs.density`** — it controls per-section *depth*, where `workflow`\ncontrols which sections exist. `modes.rigor` sets both together; set\n`docs.density` explicitly to vary depth alone: `terse` (the default, via `rigor: minimal`) = each section a bulleted list of\nconstraints + references; `balanced` = paragraphs explaining each visual choice\n(`rigor: standard`); `thorough` = full prose including style explorations, references, and\nrationale per choice. Apply it to every section you author.\n\n**`workflow`** (see `.claude/docs/workflow-modes.md`):\n- `full` — all 9 art bible sections required.\n- `standard` — required only if visual asset stories exist in the project;\n sections 1–4 are the minimum when required. `workflow_overrides.art_bible_strict:\n true` forces all 9 sections regardless of tier.\n- `minimal` — not required. Can still be run voluntarily.\n\nRead `design/gdd/game-concept.md` — or `design/game-brief.md`, the one-page brief\nthat replaces it at `rigor: minimal`. Read it by section: find the headings you need\nwith the Grep tool (pattern `^#`, content mode) and Read those ranges with offset\nand limit. If neither exists, fail with:\n> \"No game concept found. Run `/brainstorm` first — the art bible is authored after the game concept is approved.\"\n\nExtract from game-concept.md (from the brief: working title, pitch, \"Who it's for /\nwhat they feel\" line and \"Art & audio direction\" line — it has no pillars, Visual\nIdentity Anchor or platform):\n- Game title (working title)\n- Core fantasy and elevator pitch\n- Game pillars (all of them)\n- **Visual Identity Anchor** section if present (from brainstorm Phase 4 art-director output)\n- Target platform (if noted)\n\n**Retrofit mode detection**: Glob `design/art/art-bible.md`. If the file exists,\nbuild the status table **without reading the document** — you are about to author\nonly the *incomplete* sections, so loading the complete ones is loading exactly\nwhat you will not touch:\n\n```\nGrep pattern=\"^## \" path=\"design/art/art-bible.md\" output_mode=\"content\" -n\nGrep pattern=\"\\[To be designed\\]|\\[TBD\\]|\\[To be written\\]|^_?TODO\" path=\"design/art/art-bible.md\" output_mode=\"content\" -n\n```\n\n- The first grep gives the section headings and their line numbers — the gap\n between consecutive headings is that section's size.\n- The second gives placeholder markers and where they fall.\n- A section is **Complete** if it has substantive distance to the next heading and\n no placeholder marker inside it; **Placeholder** if a marker falls in its range;\n **Empty** if consecutive headings sit adjacent.\n- Where the two greps leave a section genuinely ambiguous, read *that section's*\n line range with `Read(offset, limit)` — never the whole file.\n- Build a section status table:\n\n```\nSection | Status\n--------|--------\n1. Visual Identity Statement | [Complete / Empty / Placeholder]\n2. Mood & Atmosphere | ...\n3. Shape Language | ...\n4. Color System | ...\n5. Character Design Direction | ...\n6. Environment Design Language | ...\n7. UI/HUD Visual Direction | ...\n8. Asset Standards | ...\n9. Reference Direction | ...\n```\n\n- Present this table to the user:\n > \"Found existing art bible at `design/art/art-bible.md`. [N] sections are complete, [M] need content. I'll work on the incomplete sections only — existing content will not be touched.\"\n- Only work on sections with Status: Empty or Placeholder. Do not re-author sections that are already complete.\n\nIf the file does not exist, this is a fresh authoring session. The first\napproved section creates the file from `.claude/docs/templates/art-bible.md`,\nwhose nine `## N. Name` headings are the ones retrofit mode reads — ask first:\n\"May I create `design/art/art-bible.md` from the art bible template?\" Each\napproved section then replaces its own `[To be designed]` line with `Edit`;\nkeep the headings as the template has them.\n\n**A section's approval names its write.** Every section is approved through an\n`AskUserQuestion` whose approving option is `[A] Lock this in and write it to\ndesign/art/art-bible.md` (Section 1's full option list is below). Choosing it is\nthe approval to write that section; no section is written without it, fresh or\nretrofit.\n\nExtract performance budgets and the engine for asset standard constraints: read `performance.*` and `engine.name` from `project.yaml`; for any key absent or empty (including when `project.yaml` has no `performance` or `engine` block), fall back to `.claude/docs/technical-preferences.md`.\n\n---\n\n## Phase 1: Framing\n\nPresent the session context and ask two questions before authoring anything:\n\nUse `AskUserQuestion` with two tabs:\n- Tab **\"Scope\"** — \"Which sections need to be authored today?\"\n Options: `Full bible — all 9 sections` / `Visual identity core (sections 1–4 only)` / `Asset standards only (section 8)` / `Resume — fill in missing sections`\n\n **Mark the option the resolved `workflow` tier actually requires as\n (Recommended), and say why** — the tier already decides this and the user\n should not have to know the tier table to answer:\n - `full` → **Full bible** — all 9 sections are required at this tier.\n - `standard` → **Visual identity core (sections 1–4 only)** — that is the\n documented minimum when an art bible is required at all. Say: \"Sections 1–4\n are what `standard` requires; 5–9 are available if you want them.\"\n - `minimal` → no art bible is required. Say so before asking, and offer\n sections 1–4 as the useful-if-you-want-it option rather than defaulting to 9.\n - `workflow_overrides.art_bible_strict: true` → **Full bible** regardless of tier.\n\n This is the single biggest cost lever in this skill: every authored section\n carries a specialist spawn, so authoring 9 sections where the tier requires 4\n more than doubles the run for artifacts nothing downstream will check.\n- Tab **\"References\"** — \"Do you have reference games, films, or art that define the visual direction?\"\n (Free text — let the user type specific titles. Do NOT preset options here.)\n\nIf the game-concept.md has a Visual Identity Anchor section, note it:\n> \"Found a visual identity anchor from brainstorm: '[anchor name] — [one-line rule]'. I'll use this as the foundation for the art bible.\"\n\n**Author only the sections in the chosen scope.** Phases 2–4 run only the\nsections inside it — for `Resume`, the Empty and Placeholder rows of the\nretrofit table — and skip every other section, and any phase left with none.\nPhase 6 names each section not authored this run and why.\n\n---\n\n## Phase 2: Visual Identity Foundation (Sections 1–4)\n\nThese four sections define the core visual language. **All other sections flow from them.** Author and write each to file before moving to the next.\n\n> **Spawn policy for this phase.** Section 1 is delegated on its own — it is\n> foundational and the user chooses between anchor directions before anything\n> else can build on it. Sections 2–4 are then delegated in **one** `art-director`\n> call, not three: they are the same agent receiving the same inputs (Visual\n> Identity Statement + pillars), and mood, shape and colour are interdependent —\n> an art director defines them together, not in isolation. Separate calls would\n> ask the agent to reason about colour without knowing the shape language it\n> had just written.\n>\n> **This is not reduced specialist involvement** — every section is still\n> authored by the specialist, which is the point `.claude/docs/effects-map.md`\n> makes about art-bible delegation being mandatory. It is one call instead of\n> three for the same three sections. Per-section user approval and\n> write-to-file-immediately are unchanged.\n\n### Section 1: Visual Identity Statement\n\n**Goal**: A one-line visual rule plus 2–3 supporting principles that resolve visual ambiguity.\n\nIf a visual anchor exists from game-concept.md: present it and ask:\n- \"Build directly from this anchor?\"\n- \"Revise it before expanding?\"\n- \"Start fresh with new options?\"\n\n**Agent delegation (MANDATORY)**: Spawn `art-director` via `Agent`:\n- Provide: game concept (elevator pitch, core fantasy), full pillar set, platform target, any reference games/art from Phase 1 framing, the visual anchor if it exists\n- Ask: \"Draft a Visual Identity Statement for this game. Provide: (1) a one-line visual rule that could resolve any visual decision ambiguity, (2) 2–3 supporting visual principles, each with a one-sentence design test ('when X is ambiguous, this principle says choose Y'). Anchor all principles directly in the stated pillars — each principle must serve a specific pillar. (From a one-page brief, which has no pillars, anchor them in its pitch and \"what they feel\" line.)\"\n\nPresent the art-director's draft to the user. Use `AskUserQuestion`:\n- Options: `[A] Lock this in and write it to design/art/art-bible.md` / `[B] Revise the one-liner` / `[C] Revise a supporting principle` / `[D] Describe my own direction`\n\nWrite the approved section to file immediately.\n\n### Section 2: Mood & Atmosphere\n\n**Goal**: Emotional targets by game state — specific enough for a lighting artist to work from.\n\nFor each major game state (e.g., exploration, combat, victory, defeat, menus — adapt to this game's states), define:\n- Primary emotion/mood target\n- Lighting character (time of day, color temperature, contrast level)\n- Atmospheric descriptors (3–5 adjectives)\n- Energy level (frenetic / measured / contemplative / etc.)\n\n**Agent delegation for Sections 2–4 — one call, issued here.** Spawn\n`art-director` via `Agent` with the locked Visual Identity Statement and pillar set,\nand ask for all three sections in a single brief:\n\n1. **Mood & atmosphere** — \"Define mood and atmosphere targets for each major game state in this game. Be specific — 'dark and foreboding' is not enough. Name the exact emotional target, the lighting character (warm/cool, high/low contrast, time of day direction), and at least one visual element that carries the mood. Each game state must feel visually distinct from the others.\"\n2. **Shape language** — \"Define the shape language for this game. Connect each shape principle back to the visual identity statement and a specific game pillar. Explain what these shape choices communicate to the player emotionally.\"\n3. **Colour system** — \"Design the color system for this game. Every semantic color assignment must be explained — why does this color mean danger/safety/reward in this world? Identify which color pairs might fail colorblind players and specify what backup cues are needed.\"\n\nRequire the three to be **mutually consistent** — the palette must serve the mood\ntargets and the shape hierarchy — and returned as three separately labelled\nblocks so each can be approved and written on its own.\n\nThen present **Section 2** to the user, approve it, and write it to file\nimmediately before moving to Section 3. Do not present all three at once: the\nbatching is in the delegation, not in the review.\n\n### Section 3: Shape Language\n\n**Goal**: The geometric vocabulary that makes this game's world visually coherent and distinguishable.\n\nCover:\n- Character silhouette philosophy (how readable at thumbnail size? Distinguishing trait per archetype?)\n- Environment geometry (angular/curved/organic/geometric — which dominates and why?)\n- UI shape grammar (does UI echo the world aesthetic, or is it a distinct HUD language?)\n- Hero shapes vs. supporting shapes (what draws the eye, what recedes?)\n\n**Draft source**: the Sections 2–4 delegation issued under Section 2 — use the\nshape-language block it returned. Do not spawn again.\n\nWrite the approved section to file immediately.\n\n### Section 4: Color System\n\n**Goal**: A complete, producible palette system that serves both aesthetic and communication needs.\n\nCover:\n- Primary palette (5–7 colors with roles — not just hex codes, but what each color means in this world)\n- Semantic color usage (what does red communicate? Gold? Blue? White? Establish the color vocabulary)\n- Per-biome or per-area color temperature rules (if the game has distinct areas)\n- UI palette (may differ from world palette — define the divergence explicitly)\n- Colorblind safety: which semantic colors need shape/icon/sound backup\n\n**Draft source**: the Sections 2–4 delegation issued under Section 2 — use the\ncolour-system block it returned. Do not spawn again.\n\nWrite the approved section to file immediately.\n\n---\n\n## Phase 3: Production Guides (Sections 5–8)\n\nThese sections translate the visual identity into concrete production rules. They should be specific enough that an outsourcing team can follow them without additional briefing.\n\n### Section 5: Character Design Direction\n\n**Agent delegation for Sections 5–6 — one call, issued here.** Both sections\nneed the **same agent with the same input** (`sections 1–4`), so a second call\nwould only re-send the whole visual identity. Spawn `art-director` once with\nsections 1–4 and ask for both:\n\n1. **Character design direction** — \"Cover: visual archetype for the player character (if any), distinguishing feature rules per character type (how do players tell enemies/NPCs/allies apart at a glance?), expression/pose style targets (stiff/expressive/realistic/exaggerated), and LOD philosophy (how much detail is preserved at game camera distance?).\"\n2. **Environment design language** — \"Cover: architectural style and its relationship to the world's culture/history, texture philosophy (painted vs. PBR vs. stylized — why this choice for this game?), prop density rules (sparse/dense — what drives the choice per area type?), and environmental storytelling guidelines (what visual details should tell the story without text?).\"\n\nRequire characters and environments to be **legible against each other** — a\ncharacter silhouette must read against the environment texture density the same\nbrief defines. Return two separately labelled blocks.\n\nPresent **Section 5** first, approve, write to file, then Section 6.\n\n### Section 6: Environment Design Language\n\n**Draft source**: the Sections 5–6 delegation issued under Section 5 — use the\nenvironment block it returned. Do not spawn again.\n\nWrite the approved section to file.\n\n### Section 7: UI/HUD Visual Direction\n\n**Agent delegation**: Spawn in parallel:\n- **`art-director`**: Visual style for UI — diegetic vs. screen-space HUD, typography direction (font personality, weight, size hierarchy), iconography style (flat/outlined/illustrated/photorealistic), animation feel for UI elements\n- **`ux-designer`**: UX alignment check — does the visual direction support the interaction patterns this game requires? Flag any conflicts between art direction and readability/accessibility needs.\n\nCollect both. If they conflict (e.g., art-director wants elaborate diegetic UI but ux-designer flags it would reduce combat readability), surface the conflict explicitly with both positions. Do NOT silently resolve — use `AskUserQuestion` to let the user decide.\n\nWrite the approved section to file.\n\n### Section 8: Asset Standards\n\n**Agent delegation**: Spawn in parallel:\n- **`art-director`**: File format preferences, naming convention direction, texture resolution tiers, LOD level expectations, export settings philosophy\n- **`technical-artist`**: Engine-specific hard constraints — poly count budgets per asset category, texture memory limits, material slot counts, importer constraints, anything from the performance budgets (`performance.*` in `project.yaml`, falling back to `.claude/docs/technical-preferences.md`)\n\nIf any art preference conflicts with a technical constraint (e.g., art-director wants 4K textures but performance budget requires 2K for mobile), surface the conflict explicitly with both positions — the ideal and the constrained standard, and the tradeoff. Do NOT silently resolve it — use `AskUserQuestion` to let the user pick (options: the ideal standard, the constrained standard, or document both and let per-asset judgment apply). Ambiguity in asset standards is where production costs are born.\n\nWrite the approved section to file.\n\n---\n\n## Phase 4: Reference Direction (Section 9)\n\n**Goal**: A curated reference set that is specific about what to take and what to avoid from each source.\n\n**Agent delegation**: Spawn `art-director` via `Agent` with the completed sections 1–8. Ask: \"Compile a reference direction for this game. Provide 3–5 reference sources (games, films, art styles, or specific artists). For each: name it, specify exactly what visual element to draw from it (not 'the general aesthetic' — a specific technique, color choice, or compositional rule), and specify what to explicitly avoid or diverge from (to prevent the 'trying to copy X' reading). References should be additive — no two references should be pointing in exactly the same direction.\"\n\nWrite the approved section to file.\n\n---\n\n## Phase 5: Art Director Sign-Off\n\n**Review mode check** — apply before spawning AD-ART-BIBLE:\n- `solo` → skip. Note: \"AD-ART-BIBLE skipped — Solo mode.\" Then record the skip\n (below) and proceed to Phase 6.\n- `lean` → skip (not a PHASE-GATE). Note: \"AD-ART-BIBLE skipped — Lean mode.\"\n Then record the skip (below) and proceed to Phase 6.\n- `full` → spawn as normal.\n\nOn either skip, ask \"May I record the skipped sign-off in\n`design/art/art-bible.md`'s header?\" and, on yes, replace the header's\n`> **Art Director Sign-Off (AD-ART-BIBLE)**: [Not yet reviewed]` with\n`> **Art Director Sign-Off (AD-ART-BIBLE)**: SKIPPED [date] — [solo|lean] mode`\n— the gate accepts either form as a recorded sign-off.\n\nAfter all sections are complete (or the scoped set from Phase 1 is complete), spawn `art-director` via `Agent` using gate **AD-ART-BIBLE** (`.claude/docs/director-gates/ad-art-bible.md`).\n\nPass: the art bible path (`design/art/art-bible.md`); the game pillars and core\nfantasy; the platform and performance constraints (`platform.*` and\n`performance.*` from `project.yaml`, falling back to\n`.claude/docs/technical-preferences.md`); and the visual identity anchor. When\nPhase 0 read the one-page brief, pass its pitch and \"what they feel\" line as the\npillars and fantasy, and its \"Art & audio direction\" line as the anchor.\n\nHandle verdict per standard rules in `director-gates.md`.\nOn `Revise flagged items`, or to resolve a REJECT, the section's own specialist\n— `art-director`, with `ux-designer` for Section 7 and `technical-artist` for\nSection 8 — re-drafts each flagged section, which is then presented, approved\nand written like any other section before `REVISED [date]` is recorded.\nA `NOT ASSESSED` answer is never an approval: name the missing input, then\nsupply it and re-run the gate, or record `NOT ASSESSED`.\nRecord the verdict in the art bible's status header:\n`> **Art Director Sign-Off (AD-ART-BIBLE)**: APPROVED [date] / CONCERNS (accepted) [date] / REVISED [date] / NOT ASSESSED [date] — [missing input]`\n\n---\n\n## Phase 6: Close\n\nFirst, name each of the nine sections not authored this run and why — outside\nthe chosen scope, or already complete — e.g. *\"Not authored this run: sections\n5–9 (outside the chosen scope; `standard` requires 1–4).\"* A run that stopped\nafter Section 4 must not read like a finished bible.\n\nBefore presenting next steps, check project state:\n- Does `design/gdd/systems-index.md` exist? → map-systems is done, skip that option\n- Is an engine configured — `engine.name` present in `project.yaml`, or a configured Engine field (not `[TO BE CONFIGURED]`) in `.claude/docs/technical-preferences.md`? → setup-engine is done, skip that option\n- Does `design/gdd/` contain any `*.md` files? → design-system has been run, skip that option\n- Does `design/gdd/gdd-cross-review-*.md` exist? → review-all-gdds is done\n- Do GDDs exist (check above)? → include /consistency-check option\n\nUse `AskUserQuestion` for next steps. Only include options that are genuinely next based on the state check above:\n\nAt `workflow: minimal`, the pool is `/create-stories` (no stories yet) or\n`/dev-story [next story]`, plus Stop here — the GDD/architecture pool below is\n`standard`/`full` only.\n\n**Option pool — include only if not already done:**\n- `[_] Run /map-systems — decompose the concept into systems before writing GDDs` (skip if systems-index.md exists)\n- `[_] Run /setup-engine — configure the engine (asset standards may need revisiting after engine is set)` (skip if engine configured)\n- `[_] Run /design-system — start the first GDD` (skip if any GDDs exist)\n- `[_] Run /review-all-gdds — cross-GDD consistency check (required before Technical Setup gate)` (skip if gdd-cross-review-*.md exists)\n- `[_] Run /asset-spec — generate per-asset visual specs and AI generation prompts from approved GDDs` (include if GDDs exist)\n- `[_] Run /consistency-check — scan existing GDDs against the art bible for visual direction conflicts` (include if GDDs exist)\n- `[_] Run /create-architecture — author the master architecture document (next Technical Setup step)`\n- `[_] Stop here`\n\nAssign letters A, B, C… only to the options actually included. Mark the most logical pipeline-advancing option as `(recommended)`.\n\n> **Always include** (`standard`/`full` only) `/create-architecture` and Stop here as options — these are always valid next steps once the art bible is complete.\n\n---\n\n## Collaborative Protocol\n\n**Applies in `collaborative` mode (the default).** For `guided` and\n`autonomous` modes, see `.claude/docs/automation-modes.md` — the rules below\ndescribe what collaborative mode requires, not universal behavior.\n\nEvery section follows: **Question → Options → Decision → Draft (from art-director agent) → Approval → Write to file**\n\n- Never draft a section yourself — every section's content comes from the\n relevant specialist. One delegation may cover several sections (2–4 share a\n call, as do 5–6), but no section may be written from the orchestrator's own\n judgement instead of an agent's.\n- Write each section to file immediately after approval — do not batch **the\n writes or the approvals**. Batching applies only to the delegation call; the\n user still sees, approves and commits one section at a time.\n- Surface all agent disagreements to the user — never silently resolve conflicts between art-director and technical-artist\n- The art bible is a constraint document: it restricts future decisions in exchange for visual coherence. Every section should feel like it narrows the solution space productively.\n\n---\n\n## Recommended Next Steps\n\nAfter the art bible is approved:\n- Run `/map-systems` to decompose the concept into game systems before authoring GDDs\n- Run `/setup-engine` if the engine is not yet configured (asset standards may need revisiting after engine selection)\n- Run `/design-system [first-system]` to start authoring per-system GDDs\n- Run `/consistency-check` once GDDs exist to validate them against the art bible's visual rules\n- Run `/create-architecture` to produce the master architecture document\n",".claude/skills/asset-audit/SKILL.md":"---\nname: asset-audit\ndescription: \"Audit assets against naming conventions, file size budgets, format standards. Finds orphaned assets, missing references.\"\nargument-hint: \"[category|all]\"\nuser-invocable: true\nallowed-tools: Read, Glob, Grep, Bash(stat *), Bash(file *), Bash(od *), Bash(wc *), Bash(du *)\nmodel: sonnet\n# Read-only diagnostic skill — no specialist agent delegation needed\n---\n\n# Asset Audit\n\n## Measuring file sizes and formats requires Bash\n\nThis skill's report asks for **file sizes against budgets**, **texture dimensions**\n(power-of-two), **audio sample rates**, and **last-modified times** for orphan\ndetection. None of those are obtainable from `Read`/`Glob`/`Grep` — they need\n`stat` or a binary header read, so the read-only measuring commands (`stat`,\n`file`, `od`, `wc`, `du`) are pre-approved above; list files with Glob. Anything\nelse asks first.\n\n**If you cannot take a measurement, the cell is `NOT ASSESSED`, never an\nestimate.** A size budget table filled from guesses is worse than an empty one:\nit looks like evidence. This is a live fabrication vector even on a project full\nof real assets: if the template demands tables of numbers the tool allowlist\ncannot produce, the only way to complete it is to invent them.\n\n---\n\n## Insufficient input — check this before producing any report\n\n**If the inputs this skill needs do not exist, the answer is \"could not run\" —\nnot a filled-in report.** Check first, and stop if the check fails.\n\n1. List the inputs this skill reads (data files, prior reports, profiler output,\n test results, registries, source code).\n2. For each, record `FOUND` or `ABSENT` — not \"assumed present\".\n3. If any input required for a section is ABSENT, that section is\n **`NOT ASSESSED — NO DATA`**. Do not estimate it, do not infer it from an\n adjacent artifact, and do not leave a mandated cell to be filled by whoever\n reads the template next.\n4. If **every** required input is ABSENT, stop and report\n **`NOT ASSESSED — NO DATA`** as the whole verdict, naming what was missing and\n which skill produces it.\n\n**A verdict of `NOT ASSESSED` is a success.** It is the correct, useful answer to\n\"what does the data say?\" when there is no data. The failure mode this prevents is\nspecific: a report whose verdict enum has no \"could not run\" state produces\n**false clean passes** — an asset audit returning COMPLIANT on a project with no\nassets and no standards, or a performance profile reporting \">99% headroom against\na 16.67ms budget\" with zero profiler data and no budget ever set.\n\n**Absence of evidence is never evidence of absence.** A scan that finds no\nmatches because there are no files to scan has not verified anything. Say which of\nthe two happened — a reader cannot tell from a green result.\n\n---\n\n## Phase 1: Read Standards\n\nRead the art bible's Asset Standards section (`design/art/art-bible.md`) and any\nasset standards in the relevant design docs — size budgets and format rules come\nfrom there. The naming patterns are the ones in Phase 3 below, unless the art\nbible states its own. Read the art bible by section: find the heading with\nthe Grep tool (pattern `^#`, content mode) and Read that range with offset\nand limit.\n\nIf neither states a size budget — or there is no art bible — the Size section is\n`NOT ASSESSED — no size budget set`, and the report names `/art-bible`, whose\nAsset Standards section sets budgets, formats and the naming convention.\n\n---\n\n## Phase 2: Scan Asset Directories\n\nAssets live under the engine's asset root: `assets/` on Godot, `Assets/` on\nUnity, `Content/` on Unreal. Resolve the engine and its code root per\n`.claude/docs/code-root-resolution.md`; that code root is the one Phase 3's\norphan and missing-asset searches read. If it is unresolved, stop:\n`NOT ASSESSED — engine unresolved`, naming `/setup-engine`.\n\nScan the asset root using Glob:\n\n- **Godot** — `assets/art/**/*`, `assets/audio/**/*`, `assets/vfx/**/*`,\n `assets/shaders/**/*`, `assets/data/**/*`\n- **Unity** — `Assets/**/*`, leaving out scripts (`*.cs`, `*.asmdef`) and `*.meta` files\n- **Unreal** — `Content/**/*.uasset` and `Content/**/*.umap`\n\nThe files matched are `Total assets scanned`. If there are none, the checks on\nscanned files — Naming, Size, Format, Orphaned — are\n`NOT ASSESSED — no assets under `; the missing-asset search still runs.\n\n---\n\n## Phase 3: Run Compliance Checks\n\n**Naming conventions:**\n- Art: `[category]_[name]_[variant]_[size].[ext]`\n- Audio: `[category]_[context]_[name]_[variant].[ext]`\n- All files must be lowercase with underscores\n\nThese are Godot's conventions. Unity and Unreal name assets in PascalCase, so on\nthose engines check names only against a naming rule the art bible states; with\nnone, Naming is `NOT ASSESSED — no naming rule for ` (name `/art-bible`).\n\n**File standards:**\n- Textures: Power-of-two dimensions, correct format (PNG for UI, compressed for 3D), within size budget\n- Audio: Correct sample rate, format (OGG for SFX, OGG/MP3 for music), within duration limits.\n `file` reports an audio file's format and sample rate but not its length, and no\n pre-approved tool here does; a duration budget is therefore\n `NOT ASSESSED — duration not measurable here`, naming the files it covers.\n- Data: Valid JSON/YAML, schema-compliant\n\nOn Unreal an asset file (`.uasset`, `.umap`) does not keep its source file's\nformat or dimensions, so Format is `NOT ASSESSED` there; its size is still measured.\n\n**Orphaned assets:** Search the code root for references to each asset file. Flag any with no references.\n\n**Missing assets:** Search the code root for asset references and verify the files exist.\n\nBoth searches need code: if the code root holds no source files, Orphaned and\nMissing are `NOT ASSESSED — no code to search`. On Unity and Unreal most asset\nreferences live in scenes, prefabs and other assets rather than code, so an\nasset no code names may still be in use: Orphaned is `NOT ASSESSED` there.\n\n---\n\n## Phase 4: Output Audit Report\n\n```markdown\n# Asset Audit Report -- [Category] -- [Date]\n\n## Summary\n- **Total assets scanned**: [N]\n- **Naming violations**: [N]\n- **Size violations**: [N]\n- **Format violations**: [N]\n- **Orphaned assets**: [N]\n- **Missing assets**: [N]\n- **Sections not assessed**: [none | each section and why]\n\n## Naming Violations\n| File | Expected Pattern | Issue |\n|------|-----------------|-------|\n\n## Size Violations\n| File | Budget | Actual | Overage |\n|------|--------|--------|---------|\n\n## Format Violations\n| File | Expected Format | Actual Format |\n|------|----------------|---------------|\n\n## Orphaned Assets (no code references found)\n| File | Last Modified | Size | Recommendation |\n|------|-------------|------|---------------|\n\n## Missing Assets (referenced but not found)\n| Reference Location | Expected Path |\n|-------------------|---------------|\n\n## Recommendations\n[Prioritized list of fixes, one per violation, each naming the change — the\ntarget resolution or compression for a size violation, the corrected name for a\nnaming violation, the target format for a format violation]\n\n## Verdict: [NOT ASSESSED / COMPLIANT / WARNINGS / NON-COMPLIANT]\n```\n\nChoose the verdict by the findings, first match wins:\n- **NON-COMPLIANT** — any size violation, or any asset that code references but that does not exist\n- **WARNINGS** — only naming, format or orphaned-asset findings\n- **NOT ASSESSED** — the audit did not cover its scope: no data at all (the path\n above), zero assets scanned, or any section `NOT ASSESSED` — name which. It\n ranks below the two finding verdicts, because a measured violation is more\n actionable than a gap, and above COMPLIANT\n- **COMPLIANT** — at least one asset scanned, every section assessed, no findings\n\nThis skill is read-only — it produces a report but does not write files.\n\n---\n\n## Phase 5: Next Steps\n\n- Fix naming violations using the Phase 3 patterns (or the art bible's, where it states its own).\n- If standards were missing, run `/art-bible` to write its Asset Standards section.\n- Delete confirmed orphaned assets after manual review.\n- Run `/content-audit` to cross-check asset counts against GDD-specified requirements.\n",".claude/skills/asset-spec/SKILL.md":"---\nname: asset-spec\ndescription: \"Per-asset visual specs plus AI generation prompts from GDDs and character profiles. After the art bible.\"\nargument-hint: \"[system: | level: | character:] [--review full|lean|solo]\"\nuser-invocable: true\nallowed-tools: Read, Glob, Grep, Write, Edit, Agent, AskUserQuestion, Bash(bash \"*/.claude/skills/asset-spec/../../hooks/yaml-helper.sh\" resolve_config *)\nmodel: sonnet\n---\n\n!`bash \"${CLAUDE_SKILL_DIR}/../../hooks/yaml-helper.sh\" resolve_config --keys review_mode,automation`\n\n# Asset Spec\n\n\n\nIf no argument is provided, check whether `design/assets/entity-inventory.md` exists:\n- If it exists: read it, find the first entity or screen with status \"Needed\" but no spec file yet, and use `AskUserQuestion`:\n - Prompt: \"The next unspecced item is **[name]**. Generate specs for it?\"\n - Options: `[A] Yes — spec [name]` / `[B] Pick a different item` / `[C] Stop here`\n- If no entity inventory: check `design/assets/asset-manifest.md`. If manifest exists, same flow above but reading from manifest.\n- If neither exists: **start the Entity & Screen Inventory flow** (Phase 0b below) rather than failing.\n\n---\n\nEvery `AskUserQuestion` call follows `.claude/docs/automation-modes.md`\n(collaborative asks always · guided major-only · autonomous logs and proceeds;\n`automation_always_ask` categories always prompt). **Note**: actually invoking an external image\ngenerator (calling an image API) always prompts regardless of\n`modes.automation` — it is an irreversible external action guarded\nunconditionally, independent of whether `external_calls` is listed in\n`automation_always_ask`. (Today this skill only emits generation-prompt\n*text*; the guard applies if live generation is ever wired in.)\n\n## Phase 0b: Entity & Screen Inventory (runs when no arguments and no existing inventory)\n\nThis flow produces `design/assets/entity-inventory.md` — the master list of everything\nthe game needs visually. Run once before asset spec work begins.\n\n### Step 1 — Gather from docs\nRead all available source material in parallel, each doc by section: find the\nheadings you need with the Grep tool (pattern `^#`, content mode) and Read those\nranges with offset and limit.\n- `design/gdd/systems-index.md` — extract every system listed\n- GDD asset content — do **not** full-read every GDD. The two wanted sections are\n standard headings, and named entities live in the registry:\n ```\n Grep pattern=\"## (Visual/Audio Requirements|UI Requirements)\" glob=\"design/gdd/*.md\" output_mode=\"content\" -A 25\n ```\n For named entities (characters, enemies, buildings, items), read\n `design/registry/entities.yaml` (`entities`/`items`) if it exists and has\n entries; otherwise grep the GDDs for named content. Full-read a GDD only when\n its Visual/Audio section is missing or reads `[To be designed]` (Phase 1 already\n handles that case). VFX events surface in the Visual/Audio grep context.\n- `design/art/art-bible.md` — extract: any named visual categories, asset type expectations\n- `design/narrative/` — scan for any character or world entity documents if they exist (optional — not required)\n\n### Step 2 — Build proposed inventory\nOrganize everything found into categories:\n\n```\nCharacters / Protagonists\nEnemies / Creatures\nBuildings / Structures\nEnvironment / Terrain\nItems / Props\nVFX / Particles\nUI Screens (list each screen by name)\nHUD Elements\nAudio (SFX, music — descriptions only, no generation prompts)\nOther\n```\n\nFor each item, note the source doc it was found in.\n\n### Step 3 — Present and collaborate\nPresent the full proposed inventory to the user in conversation. Then use `AskUserQuestion`:\n- Prompt: \"I found **[N] visual entities and [N] UI screens** across your GDDs and art bible. Review the list — what's missing, what's not needed?\"\n- Options:\n - `[A] Looks good — save this inventory`\n - `[B] Add items I'll describe`\n - `[C] Remove items that don't apply`\n - `[D] Both add and remove — let me edit`\n\nIf [B] or [D]: ask the user to describe additional items. Accept brief descriptions (\"a medieval keep, used as a level background\") or detailed ones — either works. Work through them collaboratively until the user is satisfied.\n\nIf [C] or [D]: ask which items to remove and why. Remove them from the list.\n\n### Step 4 — Write inventory\nAfter user approval, ask: \"May I write the entity inventory to `design/assets/entity-inventory.md`?\"\n\nWrite the file:\n\n```markdown\n# Visual Entity & Screen Inventory\n\n> Generated: [date]\n> Sources: [list of source docs read]\n\n## Entities\n\n| # | Name | Type | Description | Source | Status |\n|---|------|------|-------------|--------|--------|\n| 1 | [name] | Character / Enemy / Building / Environment / Item / Other | [brief description] | [source doc] | Needed |\n\n## UI Screens\n\n| # | Screen Name | Description | Source | Status |\n|---|-------------|-------------|--------|--------|\n| 1 | Main Menu | [description] | [source] | Needed |\n\n## HUD Elements\n\n| # | Element | Description | Source | Status |\n|---|---------|-------------|--------|--------|\n\n## Audio\n\n| # | Name | Type (SFX / Music / Ambient) | Description | Source | Status |\n|---|------|------------------------------|-------------|--------|--------|\n```\n\nAfter writing, tell the user:\n> \"Entity inventory saved. Next steps:\n> - Run `/ux-design [screen name]` for each UI screen in the inventory\n> - Run `/asset-spec system:[name]`, `level:[name]` or `character:[name]` for each\n> visual entity — whichever of the three the entity belongs to\n> - Or run `/asset-spec` again to work through the inventory one item at a time\"\n\n---\n\n## Phase 0: Parse Arguments\n\nExtract:\n- **Target type**: `system`, `level`, or `character`\n- **Target name**: the name after the colon (normalize to kebab-case)\n- **Review mode**: `--review [full|lean|solo]` if present\n\nThe effective mode is the one already resolved at the top of this skill via\n`resolve_config --keys review_mode`, which applies the full chain; with nothing\nset it follows `modes.rigor` — `solo` at `minimal` (the default), `lean` at\n`standard`, `full` at `full`. A `--review` argument overrides it for this\nrun only.\n\n**Mode behavior:**\n- `full`: spawn both `art-director` and `technical-artist` in parallel\n- `lean`: spawn `art-director` only — faster, skips technical constraint pass\n- `solo`: no agent spawning — main session writes specs from art bible rules alone. Use for simple asset categories or when speed matters more than depth.\n\n---\n\n## Phase 1: Gather Context\n\nRead all source material **before** asking the user anything. Read the art bible and\nthe GDD by section: find the headings you need with the Grep tool (pattern `^#`,\ncontent mode) and Read those ranges with offset and limit.\n\n### Required reads:\n- **Art bible**: Read `design/art/art-bible.md` — fail if missing:\n > \"No art bible found. Run `/art-bible` first — asset specs are anchored to the art bible's visual rules and asset standards.\"\n\n **Exception — the minimal path.** If there is no art bible but\n `design/game-brief.md` exists (at `rigor: minimal` no art bible is required),\n do not fail: anchor the specs in the brief's **Art & audio direction** line,\n and say so at the top of the output — \"Anchored to the brief's one-line art\n direction; there is no art bible, so colour, shape and asset-standard rules\n below are proposals, not constraints.\" Offer `/art-bible` once, as optional.\n The written spec follows the same anchor: its header reads\n `> **Art direction**: design/game-brief.md (Art & audio direction) — no art bible`\n in place of the `> **Art Bible**:` line, each asset carries\n `**Brief anchor:** [the brief line applied]` in place of the **Art Bible\n Anchors** block, and no spec cites an Art Bible section or §8 tier.\n Extract: Visual Identity Statement, Color System (semantic colors), Shape Language, Asset Standards (art bible Section 8 — dimensions, formats, polycount budgets, texture resolution tiers).\n\n- **Project config**: Read `performance.*` and `naming.*` from `project.yaml`; for any key absent or empty (including when `project.yaml` has no `performance` or `naming` block), fall back to `.claude/docs/technical-preferences.md`. Extract performance budgets and naming conventions.\n\n### Source doc reads (by target type):\n- **system**: Read `design/gdd/[target-name].md`. Extract the **Visual/Audio Requirements** section. If it doesn't exist or reads `[To be designed]`:\n > \"The Visual/Audio section of `design/gdd/[target-name].md` is empty. Either run `/design-system [target-name]` to complete the GDD, or describe the visual needs manually.\"\n Use `AskUserQuestion`: `[A] Describe needs manually` / `[B] Stop — complete the GDD first`\n- **level**: Read `design/levels/[target-name].md`. Extract art requirements, asset list, VFX needs, and the art-director's production concept specs from Step 4.\n- **character** or **entity**: Read `design/narrative/characters/[target-name].md` or search `design/narrative/` and `design/assets/entity-inventory.md` for a matching entry. Extract visual description, role, and any specified distinguishing features.\n - **If no source doc exists**: do not fail. Instead, use `AskUserQuestion`:\n - Prompt: \"No profile found for **[name]**. Describe it briefly — a sentence or two is enough.\"\n - Options: `[A] Describe it now` / `[B] Skip this entity` / `[C] Stop here`\n - If [A]: the user's description becomes the source. Brief answers produce concise specs; detailed answers produce detailed specs. Accept whatever level of detail the user provides and work from it.\n\n### Optional reads:\n- **This target's existing spec**: if `design/assets/specs/[target-name]-assets.md` exists, read it — this is a re-run, and Phase 2 proposes only what is new or changed since (Phase 5 updates the file in place).\n- **Existing manifest**: Read `design/assets/asset-manifest.md` if it exists — extract already-specced assets for this target to avoid duplicates.\n- **Related specs**: Glob `design/assets/specs/*.md` — scan for assets that could be shared (e.g., a common UI element specced for one system might apply here too).\n\n### Present context summary:\n> **Asset Spec: [Target Type] — [Target Name]**\n> - Source doc: [path] — [N] asset types identified\n> - Art bible: found — Asset Standards at Section 8\n> - Existing specs for this target: [N already specced / none]\n> - Shared assets found in other specs: [list or \"none\"]\n\n---\n\n## Phase 2: Asset Identification\n\nFrom the source doc, extract every asset type mentioned — explicit and implied.\n\n**For systems**: look for VFX events, sprite references, UI elements, audio triggers, particle effects, icon needs, and any \"visual feedback\" language.\n\n**For levels**: look for unique environment props, atmospheric VFX, lighting setups, ambient audio, skybox/background, and any area-specific materials.\n\n**For characters**: look for sprite sheets (idle, walk, attack, death), portrait/avatar, VFX attached to abilities, UI representation (icon, health bar skin).\n\nGroup assets into categories:\n- **Sprite / 2D Art** — character sprites, UI icons, tile sheets\n- **VFX / Particles** — hit effects, ambient particles, screen effects\n- **Environment** — props, tiles, backgrounds, skyboxes\n- **UI** — HUD elements, menu art, fonts (if custom)\n- **Audio** — SFX, music tracks, ambient loops *(note: audio specs are descriptions only — no generation prompts)*\n- **3D Assets** — meshes, materials (if applicable per engine)\n\nPresent the full identified list to the user. Use `AskUserQuestion`:\n- Prompt: \"I identified [N] assets across [N] categories for **[target]**. Review before speccing:\"\n- Show the grouped list in conversation text first\n- Options: `[A] Proceed — spec all of these` / `[B] Remove some assets` / `[C] Add assets I didn't catch` / `[D] Adjust categories`\n\nDo NOT proceed to Phase 3 without user confirmation of the asset list.\n\n---\n\n## Phase 3: Spec Generation\n\nSpawn specialist agents based on review mode. **Issue all `Agent` calls simultaneously — do not wait for one before starting the next.**\n\n### Full mode — spawn in parallel:\n\n**`art-director`** via `Agent`:\n- Provide: full asset list from Phase 2, art bible Visual Identity Statement, Color System, Shape Language, the source doc's visual requirements, and any reference games/art mentioned in the art bible Section 9\n- Ask: \"For each asset in this list, produce: (1) a 2–3 sentence visual description anchored to the art bible's shape language and color system — be specific enough that two different artists would produce consistent results; (2) a generation prompt ready for use with AI image tools (Midjourney/Stable Diffusion style — include style keywords, composition, color palette anchors, negative prompts); (3) which art bible rules directly govern this asset (cite by section). For audio assets, describe the sonic character instead of a generation prompt.\"\n\n**`technical-artist`** via `Agent`:\n- Provide: full asset list, art bible Asset Standards (Section 8), performance budgets (`performance.*` from `project.yaml`, else `technical-preferences.md`), engine name and version\n- Ask: \"For each asset in this list, specify: (1) exact dimensions or polycount (match the art bible Asset Standards tiers — do not invent new sizes); (2) file format and export settings; (3) naming convention (`naming.*` from `project.yaml`, else `technical-preferences.md`); (4) any engine-specific constraints this asset type must respect; (5) LOD requirements if applicable. Flag any asset type where the art bible's preferred standard conflicts with the engine's constraints.\"\n\n### Lean mode — spawn art-director only (skip technical-artist).\n\n### Solo mode — skip both. Derive specs from art bible rules alone, noting that technical constraints were not validated.\n\n**Announce every skipped agent by name in the output**, before the specs:\n\"technical-artist skipped — Lean mode: technical constraints not validated.\" /\n\"art-director and technical-artist skipped — Solo mode: specs derived in this\nsession; technical constraints not validated.\" A spec drafted without an agent\nmust not read like one an agent reviewed.\n\n**Collect both responses before Phase 4.** If any conflict exists between art-director and technical-artist (e.g., art-director specifies 4K textures but technical-artist flags the engine budget requires 512px), surface it explicitly — do NOT silently resolve.\n\n---\n\n## Phase 4: Compile and Review\n\nCombine the agent outputs into a draft spec per asset. Present all specs in conversation text using this format:\n\n```\n## ASSET-[NNN] — [Asset Name]\n\n| Field | Value |\n|-------|-------|\n| Category | [Sprite / VFX / Environment / UI / Audio / 3D] |\n| Dimensions | [e.g. 256×256px, 4-frame sprite sheet] |\n| Format | [PNG / SVG / WAV / etc.] |\n| Naming | [e.g. vfx_frost_hit_01.png] |\n| Polycount | [if 3D — e.g. <800 tris] |\n| Texture Res | [e.g. 512px — matches Art Bible §8 Tier 2] |\n\n**Visual Description:**\n[2–3 sentences. Specific enough for two artists to produce consistent results.]\n\n**Art Bible Anchors:**\n- §3 Shape Language: [relevant rule applied]\n- §4 Color System: [color role — e.g. \"uses Threat Blue per semantic color rules\"]\n\n**Generation Prompt:**\n[Ready-to-use prompt. Include: style keywords, composition notes, color palette anchors, lighting direction, negative prompts.]\n\n**Status:** Needed\n```\n\nAfter presenting all specs, use `AskUserQuestion`:\n- Prompt: \"Asset specs for **[target]** — [N] assets. Review complete?\"\n- Options: `[A] Approve all — write to file` / `[B] Revise a specific asset` / `[C] Regenerate with different direction`\n\nIf [B]: ask which asset and what to change. Revise inline and re-present. Do NOT re-spawn agents for minor text revisions — only re-spawn if the visual direction itself needs to change.\n\nIf [C]: ask what direction to change. Re-spawn the relevant agent with the updated brief.\n\n---\n\n## Phase 5: Write Spec File\n\nAfter approval, ask: \"May I write the spec to `design/assets/specs/[target-name]-assets.md`?\"\n\n**If that file already exists** (a re-run for the same target), update it in\nplace — never overwrite it wholesale. Keep its existing `ASSET-NNN` blocks and\nIDs, apply only the changes the user approved, and append new assets with the\nnext project-wide IDs. Show what changes, then ask \"May I update\n`design/assets/specs/[target-name]-assets.md`?\" instead of \"May I write\".\n\nWrite the file with:\n\n```markdown\n# Asset Specs — [Target Type]: [Target Name]\n\n> **Source**: [path to source GDD/level/character doc]\n> **Art Bible**: design/art/art-bible.md\n> **Generated**: [date]\n> **Status**: [N] assets specced / [N] approved / [N] in production / [N] done\n\n[all asset specs in ASSET-NNN format]\n```\n\nThen update `design/assets/asset-manifest.md`. If it doesn't exist, create it:\n\n```markdown\n# Asset Manifest\n\n> Last updated: [date]\n\n## Progress Summary\n\n| Total | Needed | In Progress | Done | Approved |\n|-------|--------|-------------|------|----------|\n| [N] | [N] | [N] | [N] | [N] |\n\n## Assets by Context\n\n### [Target Type]: [Target Name]\n| Asset ID | Name | Category | Status | Spec File |\n|----------|------|----------|--------|-----------|\n| ASSET-001 | [name] | [category] | Needed | design/assets/specs/[target]-assets.md |\n```\n\nIf the manifest already exists, append the new context block — on a re-run for this target, add the new rows to its existing block instead of appending a second one — and update the Progress Summary counts.\n\nAsk: \"May I update `design/assets/asset-manifest.md`?\"\n\n---\n\n## Phase 6: Close\n\nUse `AskUserQuestion`:\n- Prompt: \"Asset specs complete for **[target]**. What's next?\"\n- Options:\n - `[A] Spec another system — /asset-spec system:[next-system]`\n - `[B] Spec a level — /asset-spec level:[level-name]`\n - `[C] Spec a character — /asset-spec character:[character-name]`\n - `[D] Run /asset-audit — validate delivered assets against specs`\n - `[E] Stop here`\n\n---\n\n## Asset ID Assignment\n\nAsset IDs are assigned sequentially across the entire project — not per-context. Read the manifest before assigning IDs to find the current highest number:\n\n```\nGrep pattern=\"ASSET-\" path=\"design/assets/asset-manifest.md\"\n```\n\nStart new assets from `ASSET-[highest + 1]`. This ensures IDs are stable and unique across the whole project.\n\nIf no manifest exists yet, start from `ASSET-001`.\n\n---\n\n## Shared Asset Protocol\n\nBefore speccing an asset, check if an equivalent already exists in another context's spec:\n\n- Common UI elements (health bars, score displays) are often shared across systems\n- Generic environment props may appear in multiple levels\n- Character VFX (hit sparks, death effects) may reuse a base spec with color variants\n\nIf a match is found: reference the existing ASSET-ID rather than creating a duplicate. Note the shared usage in the manifest's referenced-by column.\n\n> \"ASSET-012 (Generic Hit Spark) already specced for Combat system. Reusing for Tower Defense — adding tower-defense to referenced-by.\"\n\n---\n\n## Error Recovery Protocol\n\nIf any spawned agent returns BLOCKED or cannot complete:\n\n1. Surface immediately: \"[AgentName]: BLOCKED — [reason]\"\n2. In `lean` mode or if `technical-artist` blocks: proceed with art-director output only — note that technical constraints were not validated\n3. In `solo` mode or if `art-director` blocks: derive descriptions from art bible rules — flag as \"Art director not consulted — verify against art bible before production\"\n4. Always produce a partial spec — never discard work because one agent blocked\n\n---\n\n## Collaborative Protocol\n\n**Applies in `collaborative` mode (the default).** For `guided` and\n`autonomous` modes, see `.claude/docs/automation-modes.md` — the rules below\ndescribe what collaborative mode requires, not universal behavior.\n\nEvery phase follows: **Identify → Confirm → Generate → Review → Approve → Write**\n\n- Never spec assets without first confirming the asset list with the user\n- Always anchor specs to the art bible — a spec that contradicts the art bible is wrong\n- Surface all agent disagreements — do not silently pick one\n- Write the spec file only after explicit approval\n- Update the manifest immediately after writing the spec\n\n---\n\n## Recommended Next Steps\n\n- Run `/asset-spec [next-context]` to continue speccing remaining systems, levels, or characters\n- Run `/asset-audit` to validate delivered assets against the written specs and identify gaps or mismatches\n",".claude/skills/balance-check/SKILL.md":"---\nname: balance-check\ndescription: \"Find balance outliers, broken progressions, degenerate strategies, economy imbalances in formulas and data. 'Check game balance'.\"\nargument-hint: \"[system-name|path-to-data-file]\"\nuser-invocable: true\nallowed-tools: Read, Glob, Grep, Write, AskUserQuestion, Bash(bash \"*/.claude/skills/balance-check/../../hooks/yaml-helper.sh\" resolve_config *)\nmodel: sonnet\n---\n\n!`bash \"${CLAUDE_SKILL_DIR}/../../hooks/yaml-helper.sh\" resolve_config --keys automation`\n\n# Balance Check\n\n\n\nEvery `AskUserQuestion` call follows `.claude/docs/automation-modes.md`\n(collaborative asks always · guided major-only · autonomous logs and proceeds;\n`automation_always_ask` categories always prompt).\n\n## Insufficient input — check this before producing any report\n\n**If the inputs this skill needs do not exist, the answer is \"could not run\" —\nnot a filled-in report.** Check first, and stop if the check fails.\n\n1. List the inputs this skill reads (data files, prior reports, profiler output,\n test results, registries, source code).\n2. For each, record `FOUND` or `ABSENT` — not \"assumed present\".\n3. If any input required for a section is ABSENT, that section is\n **`NOT ASSESSED — NO DATA`**. Do not estimate it, do not infer it from an\n adjacent artifact, and do not leave a mandated cell to be filled by whoever\n reads the template next.\n4. If **every** required input is ABSENT, stop and report\n **`NOT ASSESSED — NO DATA`** as the whole verdict, naming what was missing and\n which skill produces it.\n\n**A verdict of `NOT ASSESSED` is a success.** It is the correct, useful answer to\n\"what does the data say?\" when there is no data. The failure mode this prevents is\nspecific: a report whose verdict enum has no \"could not run\" state produces\n**false clean passes** — an asset audit returning COMPLIANT on a project with no\nassets and no standards, or a performance profile reporting \">99% headroom against\na 16.67ms budget\" with zero profiler data and no budget ever set.\n\n**Absence of evidence is never evidence of absence.** A scan that finds no\nmatches because there are no files to scan has not verified anything. Say which of\nthe two happened — a reader cannot tell from a green result.\n\n---\n\n## Phase 1: Identify Balance Domain\n\nDetermine the balance domain from `$ARGUMENTS` — the whole string, since a data-file path may contain spaces:\n\n- **Combat** → weapon/ability DPS, time-to-kill, damage type interactions\n- **Economy** → resource faucets/sinks, acquisition rates, item pricing\n- **Progression** → XP/power curves, dead zones, power spikes\n- **Loot** → rarity distribution, pity timers, inventory pressure\n- **File path given** → load that file directly and infer domain from content\n\nIf no argument, ask the user which system to check.\n\n---\n\n## Phase 2: Read Data Files\n\nRead relevant files from `assets/data/` and `design/balance/` for the identified domain.\nNote every file read — they will appear in the Data Sources section of the report.\n\n---\n\n## Phase 3: Read Design Document\n\n**Registry first.** If `design/registry/entities.yaml` exists, read it before the\nGDD. Its `constants` and `formulas` sections hold the cross-GDD named values and\noutput ranges — the balance targets — already distilled, each with a `source:`\nGDD and any `revised:` date:\n```\nGrep pattern=\"^ - name:\" path=\"design/registry/entities.yaml\" output_mode=\"content\" -A 6\n```\nTake the intended values from the registry for any constant or formula it lists\n(the `constants:` and `formulas:` blocks); these are the authoritative cross-doc\nfigures a GDD must not contradict. **If `design/registry/entities.yaml` does not\nexist or has no entries** (it ships as an empty stub until `/design-system`\npopulates it), skip this and use the GDD alone.\n\nThen read the GDD for the system from `design/gdd/` to understand intended design\ntargets, tuning knobs, and expected value ranges — for anything the registry did\nnot already supply. This is the baseline for \"correct\" behaviour. Read it by section:\nfind the headings you need with the Grep tool (pattern `^#`, content mode) and\nRead those ranges with offset and limit.\n\nIf the data files are FOUND but neither source gives targets for this domain,\nthe sections that judge against targets (Outliers Detected, and Progression\nAnalysis where the domain has a curve) are `NOT ASSESSED — NO DATA`. Each one names what was missing — the\nGDD it looked for in `design/gdd/`, and whether the registry was absent or empty\n— and names `/design-system`, which writes both.\n\n---\n\n## Phase 4: Perform Analysis\n\n**Every domain: compare each value with its target.** For each named value in the\ndata files, take its target from Phase 3 — a registry constant's `value`, a\nregistry formula's `output_range`, or the range the GDD states — and compare. A\nvalue outside its target is a row in Outliers Detected (`player_damage_base` 140\nagainst 90–110). A value with no target anywhere is neither in range nor an\noutlier: list it under Values That Need Attention as `no stated range — not judged`.\n\nThen run domain-specific checks:\n\n**Combat balance:**\n- Calculate DPS for all weapons/abilities at each power tier\n- Check time-to-kill at each tier\n- Identify any options that dominate all others (strictly better)\n- Check if defensive options can create unkillable states\n- Verify damage type/resistance interactions are balanced\n\n**Economy balance:**\n- Map all resource faucets and sinks with flow rates\n- Project resource accumulation over time\n- Check for infinite resource loops\n- Verify gold sinks scale with gold generation\n- Check if any items are never worth purchasing\n\n**Progression balance:**\n- Plot the XP curve and power curve\n- Check for dead zones (no meaningful progression for too long)\n- Check for power spikes (sudden jumps in capability)\n- Verify content gates align with expected player power\n- Check if skip/grind strategies break intended pacing\n\n**Loot balance:**\n- Calculate expected time to acquire each rarity tier\n- Check pity timer math\n- Verify no loot is strictly useless at any stage\n- Check inventory pressure vs acquisition rate\n\n---\n\n## Phase 5: Output the Analysis\n\n```\n## Balance Check: [System Name]\n\n### Data Sources Analyzed\n- [List of files read]\n\n### Health Summary: [NOT ASSESSED / HEALTHY / CONCERNS / CRITICAL ISSUES]\n\n### Outliers Detected\n| Item/Value | Expected Range | Actual | Issue |\n|-----------|---------------|--------|-------|\n\n### Degenerate Strategies Found\n- [Strategy description and why it is problematic]\n\n### Progression Analysis\n[Graph description or table showing progression curve health]\n\n### Recommendations\n| Priority | Issue | Suggested Fix | Impact |\n|----------|-------|--------------|--------|\n\n### Values That Need Attention\n[Specific values with suggested adjustments and rationale]\n```\n\nChoose the Health Summary by the worst finding, first match wins:\n- **CRITICAL ISSUES** — a degenerate strategy (one choice dominates every\n alternative), a progression that stalls or cannot be completed, or an economy\n loop with no sink\n- **CONCERNS** — outliers or curve problems a tuning pass can fix, with no\n finding of the critical kind\n- **NOT ASSESSED** — nothing to analyze (the no-data path above), a section that\n needs targets is `NOT ASSESSED — NO DATA`, or a value had no stated range to\n judge it against; name which. It ranks below the two finding verdicts, because\n a measured problem is more actionable than a gap, and above HEALTHY\n- **HEALTHY** — every value judged against a stated target, no outliers, no\n degenerate strategies, progression within the stated targets\n\n---\n\n## Phase 6: Fix & Verify Cycle\n\nAfter presenting the report, use `AskUserQuestion`:\n- Prompt: \"Balance check complete. What would you like to do next?\"\n- Options:\n - `[A] Fix highest-priority issue now — walk me through it`\n - `[B] Save report to design/balance/balance-check-[system]-[date].md`\n - `[C] Stop here — I'll review the findings manually`\n\n**Run as a subagent?** `game-designer` preloads this skill, and a subagent has\nno `AskUserQuestion`. End your reply with the question and these three options\nas a short list, and stop: whoever called you asks the user and passes the\nanswer back.\n\nIf [A]:\n- Ask which issue to address first (refer to the Recommendations table by priority row)\n- Guide the user to update the relevant data file in `assets/data/` or formula in `design/balance/`\n- After each fix, offer to re-run the relevant balance checks to verify no new outliers were introduced\n- If the fix changes a tuning knob defined in a GDD or referenced by an ADR, remind the user:\n > \"This value is defined in a design document. Run `/propagate-design-change [path]` on the affected GDD to find downstream impacts before committing.\"\n\nIf [B]:\n- Write the report to `design/balance/balance-check-[system]-[date].md` (create the directory if needed). Use the current date for [date] in YYYY-MM-DD format.\n- Confirm the file was written, then end with: \"Re-run `/balance-check` after fixes to verify.\"\n\nIf [C]:\n- Summarize open issues and end with: \"Re-run `/balance-check` after fixes to verify.\"\n",".claude/skills/brainstorm/SKILL.md":"",".claude/skills/brainstorm/references/full-concept.md":"# Full concept flow (`workflow: standard` or `full`)\n\n**In this file:** start · Phase 1 Creative discovery · Phase 2 Concept generation · Phase 3 Core loop ·\nPhase 4 Pillars and boundaries · Phase 5 Player types · Phase 6 Scope and feasibility · Phase 7\nWrite the concept · Phase 8 Next steps\n\nThe output is `design/gdd/game-concept.md`, written from the game-concept template SKILL.md names.\nAsk at each phase; never generate the whole concept silently. You facilitate, the user decides.\nWrite the analysis in your reply first, then ask with short option labels.\n\n## Start\n\n1. The text typed after the skill name may hold a genre or theme hint (`roguelike`, `cozy\n farming`). `open` or nothing: start from scratch.\n2. If `design/gdd/game-concept.md` or `design/gdd/game-pillars.md` exists, read it by section (find\n the headings with the Grep tool with pattern `^#` in content mode, then read those ranges)\n and resume or build on it instead of restarting.\n\n## Phase 1: Creative discovery\n\nStart with the person, not the game. Ask conversationally:\n- A moment in a game that moved or thrilled them, and what created it.\n- A fantasy they have always wanted in a game and never found.\n- The three games they spent the most time with, and why. Ask this as plain text, never with\n preset options: they must be able to type any game.\n- Genres they love or avoid. Then ask: challenge, relax, story or self-expression?\n\nThen ask these three questions together:\n- \"What kind of experience do you most want players to have?\" Challenge & Mastery / Story &\n Discovery / Expression & Creativity / Relaxation & Flow\n- \"What's your realistic development timeline?\" Weeks / Months / 1-2 years / Multi-year\n- \"Where are you in your dev journey?\" First game / Shipped before / Professional background\n\nSum the answers up as a **Creative Brief** of 3 to 5 sentences (emotional goals, taste,\nconstraints), read it back and confirm it.\n\n## Phase 2: Concept generation\n\nGenerate **three** distinct concepts from the brief, each in a different direction, using:\n- **Verb-first:** start from the core verb (build, fight, explore, solve, survive, manage).\n- **Mashup:** genre A + theme B; the tension is the hook (\"farming sim + cosmic horror\").\n- **Experience-first (MDA backward):** start from the aesthetic (sensation, fantasy, narrative,\n challenge, fellowship, discovery, expression, submission) and work back to mechanics.\n\nEach concept has: Working Title · Elevator Pitch (1-2 sentences, passes the 10-second test) · Core\nVerb · Core Fantasy · Unique Hook (\"like X, and also Y\") · Primary MDA Aesthetic · Estimated Scope\n(small / medium / large) · Why It Could Work (one sentence) · Biggest Risk (one sentence).\n\nPresent all three, then ask one question with these five options: \"Which concept resonates with\nyou? You can pick one, combine elements, or ask for fresh directions.\" `Concept 1 — [Title]` /\n`Concept 2 — [Title]` / `Concept 3 — [Title]` / `Combine elements across concepts` / `Generate\nfresh directions`. Ask it in every automation mode: no rule can pick the user's creative\ndirection. Do not push toward a choice.\n\n## Phase 3: Core loop\n\nFor the chosen concept, ask with options derived from the concept, each with an `I'll describe it`\noption:\n1. \"What's the primary feel of the core action?\" (3-4 options that fit the genre and tone)\n2. The concept's most important design variable (world reactivity, pacing, agency), as a question.\n\nThen work through, in the reply:\n- **30-second loop:** is the action satisfying in itself, and why (feedback, timing, depth)?\n- **5-minute loop:** what turns moments into cycles; where \"one more run\" starts; the choices made.\n- **Session loop (30-120 minutes):** a full session, its stopping points, the hook between sessions.\n- **Progression loop:** how the player grows, the long-term goal, when the game is done.\n- **Motivation (self-determination theory):** autonomy, competence, relatedness.\n\n## Phase 4: Pillars and boundaries\n\nDraft **3 to 5 pillars**, each with a name, a one-sentence definition and a design test (\"debating\nX or Y, this pillar picks __\"). Pillars should pull against each other a little. Add **3 or more\nanti-pillars**: \"We will NOT do [thing] because it would compromise [pillar].\"\n\nAsk: \"Do these pillars feel right for your game?\" `Lock these in` / `Rename or reframe one` /\n`Swap a pillar out` / `Something else`. After a revision ask: \"Pillars updated. Ready to lock these\nin?\" `Lock these in` / `Revise another pillar` / `Something else`.\n- `collaborative`: repeat until the user picks `Lock these in`.\n- `guided`: ask once, apply the revision, lock them in.\n- `autonomous`: do not ask; lock the draft in and log the decision with the alternatives.\n\n**Review mode** (from the settings block or `--review`):\n- `solo` or `lean`: print these two lines, with the mode's name, and go on to Phase 5:\n `CD-PILLARS skipped — Solo mode.` and `AD-CONCEPT-VISUAL skipped — Solo mode.`\n- `full`: hand the pillar review to the `creative-director` agent (gate CD-PILLARS; brief: the\n pillars with design tests, anti-pillars, core fantasy and hook) and the visual review to the\n `art-director` agent (gate AD-CONCEPT-VISUAL; brief: the pitch, pillars, target platform if\n known, reference games mentioned). Each reads its own gate file and returns its verdict; neither\n edits files. They are independent: hand them out together where you can, otherwise one after\n another.\n\nWith both reports, when CD-PILLARS returns APPROVE, ask these two questions together:\n- **Pillars:** the creative-director's feedback. `Lock in as-is` / `Revise [pillar]` / `Discuss\n further`.\n- **Visual anchor:** the art-director's 2-3 named directions, one option each, plus `Combine\n elements across directions` / `Describe my own direction`. On STRONG mark the dominant one\n `(Recommended)`. On CONCERNS show its reason and offer `Revise pillars` / `Describe my own\n direction`.\n\nIf CD-PILLARS returns CONCERNS or REJECT, settle the pillars first (the Pillars question alone),\nthen ask the Visual anchor question alone. NOT ASSESSED from either gate is not an approval: name\nthe missing input, supply it and run that gate again; failing that, treat CD-PILLARS NOT ASSESSED\nas CONCERNS, and with no art-director directions offer only `Describe my own direction`.\n\nThe chosen direction is the **Visual Identity Anchor**: it goes into the concept and seeds the art\nbible.\n\n## Phase 5: Player types\n\nUsing Bartle's types and the Quantic Foundry model: the primary player who will love it\n(Achievers, Explorers, Socializers, Competitors, Creators, Storytellers), the secondary appeal, who\nit is not for, and successful games that serve the same player.\n\n## Phase 6: Scope and feasibility\n\n- **Platform.** Ask: \"What platforms are you targeting?\" `PC (Steam / Epic)` / `Mobile (iOS /\n Android)` / `Console` / `Web / Browser` / `Multiple platforms`. Record it for `/setup-engine`.\n Note what the platform implies, without recommending an engine: `/setup-engine` makes that call\n against the pinned engine reference.\n- **Engine.** Ask in every automation mode, `autonomous` included: \"Do you already have an engine\n you work in?\" `Godot` / `Unity` / `Unreal Engine 5` / `No preference — help me decide`. Never\n pick an engine for the user. A named engine is recorded as their preference without second\n guessing. No preference: \"Run `/setup-engine` after this session; it walks through the choice\n with your concept and platform.\" Make no recommendation here.\n- Art pipeline and how labour-heavy it is; content scope (levels, items, hours); the MVP (the\n smallest build that tests whether the core loop is fun); the biggest technical, design and market\n risks; scope tiers (full vision, and what ships if time runs out).\n\n**Review mode** before TD-FEASIBILITY: `solo` or `lean` prints `TD-FEASIBILITY skipped — Solo\nmode.` (or `Lean mode`) and goes on to the scope tiers. `full`: after the technical risks, hand the\nfeasibility review to the `technical-director` agent (gate TD-FEASIBILITY; brief: the core loop,\nplatform, engine or \"undecided\", the technical risks). Show its report. HIGH RISK: offer to revisit\nscope. CONCERNS: note and go on. NOT ASSESSED: name the missing input and record feasibility as not\nassessed in the concept's risks, never as VIABLE.\n\n**Review mode** before PR-SCOPE: `solo` or `lean` prints `PR-SCOPE skipped — Solo mode.` (or `Lean\nmode`) and goes on to Phase 7. `full`: hand the scope review to the `producer` agent (gate PR-SCOPE;\nbrief: full vision, MVP, scope tiers, timeline, team size). It answers REALISTIC, OPTIMISTIC or\nUNREALISTIC. UNREALISTIC: ask whether to adjust the MVP or scope tiers or keep them; the user\ndecides and the concept is never rejected for it. OPTIMISTIC: show the producer's adjustments and\nask whether to apply them. NOT ASSESSED: ask for the missing input (timeline, team size) and run it\nagain, or record scope as not assessed, never as REALISTIC.\n\n## Phase 7: Write the concept\n\nFill every section of the template from the conversation, including the MDA analysis, motivation\nprofile and flow design, plus a **Visual Identity Anchor** section: the direction's name, its\none-line visual rule, 2-3 supporting principles with design tests, and the colour philosophy.\n\nThe Core Identity table's Estimated Scope matches the full-vision timeline in Scope Tiers: write\n\"Large (X–Y months, solo)\" or \"Large (X–Y months, team of N)\", not \"Large\".\n\nAsk, as its own question: \"Game concept is ready. May I write it to `design/gdd/game-concept.md`?\"\n`Yes — write it` / `Not yet — revise a section first`. Write only on an explicit yes to this\nquestion. A revision: ask which section (`Elevator Pitch` / `Core Fantasy & Unique Hook` /\n`Pillars` / `Core Loop` / `MVP Definition` / `Scope Tiers` / `Risks` / `Something else — I'll\ndescribe`), show it before and after, then ask \"Ready to write the updated concept document?\"\n`Yes — write it` / `Revise another section`.\n- `collaborative`: repeat until the yes.\n- `guided`: ask once, apply the revision and write.\n- `autonomous`: do not ask; write and log the decision.\n\nWrite the file, creating folders as needed. Never write `design/game-brief.md` at this tier.\n\n## Phase 8: Next steps\n\nList every step, in order.\n\n**Design-first** (the concept is well defined):\n1. `/setup-engine`: configure the engine and its version-aware reference docs\n2. `/art-bible`: the visual identity, before any GDD. Required before the Technical Setup gate at\n `full`; at `standard` only when the game has visual-asset stories\n3. `/design-review design/gdd/game-concept.md`: check the concept is complete\n4. The `creative-director` agent: refine the pillars\n5. `/map-systems`: the systems, their dependencies and priorities, in the systems index\n6. `/design-system`: one GDD per system from step 5\n7. `/create-architecture`: the architecture blueprint and its Required ADR list\n8. `/architecture-decision`: one ADR per decision on that list\n9. `/architecture-review`: the TR registry and traceability matrix (needed before the\n Pre-Production gate)\n10. `/gate-check`: the stage gate before Production\n\n**Prototype-first** (the core mechanic is unproven):\n1. `/setup-engine`\n2. `/prototype [core mechanic]`: is it fun, in a day at most, throwaway code\n3. PROCEED: `/art-bible`, then design-first steps 5-10 with what the prototype taught\n4. PIVOT: `/brainstorm` again with the learnings\n5. After design and architecture, `/vertical-slice` before committing to sprints\n\nThen a summary: the pitch, pillars, primary player type, engine preference, biggest risk and the\nfile path. End with the line `Verdict: COMPLETE — game concept written.`\n\nIf the conversation is getting long before Phase 7, say that anything not yet written to\n`design/gdd/game-concept.md` lives only in this conversation, and write the concept before a fresh\nsession.\n",".claude/skills/bug-report/SKILL.md":"",".claude/skills/bug-triage/SKILL.md":"",".claude/skills/changelog/SKILL.md":"",".claude/skills/code-review/SKILL.md":"",".claude/skills/consistency-check/SKILL.md":"",".claude/skills/content-audit/SKILL.md":"",".claude/skills/create-architecture/SKILL.md":"",".claude/skills/create-architecture/references/0-load-context.md":"",".claude/skills/create-architecture/references/1-layers.md":"",".claude/skills/create-architecture/references/2-module-ownership.md":"",".claude/skills/create-architecture/references/3-data-flow.md":"",".claude/skills/create-architecture/references/4-api-boundaries.md":"",".claude/skills/create-architecture/references/5-adr-audit.md":"",".claude/skills/create-architecture/references/6-missing-adrs.md":"",".claude/skills/create-architecture/references/7-write.md":"",".claude/skills/create-architecture/references/8-handoff.md":"",".claude/skills/create-control-manifest/SKILL.md":"",".claude/skills/create-epics/CONTRACT.md":"",".claude/skills/create-epics/SKILL.md":"",".claude/skills/create-epics/references/pr-epic-gate.md":"",".claude/skills/create-stories/CONTRACT.md":"",".claude/skills/create-stories/SKILL.md":"",".claude/skills/create-stories/references/qa-lead-gate.md":"",".claude/skills/day-one-patch/SKILL.md":"",".claude/skills/design-review/SKILL.md":"",".claude/skills/design-system/SKILL.md":"",".claude/skills/design-system/references/1-parse-arguments.md":"",".claude/skills/design-system/references/2-gather-context.md":"",".claude/skills/design-system/references/3-file-skeleton.md":"",".claude/skills/design-system/references/4-section-design.md":"",".claude/skills/design-system/references/5-post-design.md":"",".claude/skills/dev-story/CONTRACT.md":"",".claude/skills/dev-story/SKILL.md":"",".claude/skills/dev-story/references/engine-checks.md":"",".claude/skills/dev-story/references/version-mismatch.md":"",".claude/skills/estimate/SKILL.md":"",".claude/skills/gate-check/CONTRACT.md":"",".claude/skills/gate-check/SKILL.md":"",".claude/skills/gate-check/references/2b-workflow-tier.md":"",".claude/skills/gate-check/references/3-run-gate-check.md":"",".claude/skills/gate-check/references/4-assessment.md":"",".claude/skills/gate-check/references/5-verdict.md":"",".claude/skills/gate-check/references/6-update-stage.md":"",".claude/skills/gate-check/references/7-next-steps.md":"",".claude/skills/gate-check/references/gate-polish.md":"",".claude/skills/gate-check/references/gate-pre-production.md":"",".claude/skills/gate-check/references/gate-production.md":"",".claude/skills/gate-check/references/gate-release.md":"",".claude/skills/gate-check/references/gate-systems-design.md":"",".claude/skills/gate-check/references/gate-technical-setup.md":"",".claude/skills/help/SKILL.md":"",".claude/skills/hotfix/SKILL.md":"",".claude/skills/launch-checklist/SKILL.md":"",".claude/skills/localize/SKILL.md":"",".claude/skills/map-systems/SKILL.md":"",".claude/skills/milestone-review/SKILL.md":"",".claude/skills/onboard/SKILL.md":"",".claude/skills/patch-notes/SKILL.md":"",".claude/skills/perf-profile/SKILL.md":"",".claude/skills/playtest-report/SKILL.md":"",".claude/skills/project-stage-detect/SKILL.md":"",".claude/skills/propagate-design-change/SKILL.md":"",".claude/skills/prototype/SKILL.md":"",".claude/skills/prototype/references/1-question.md":"",".claude/skills/prototype/references/2-load-context.md":"",".claude/skills/prototype/references/3-choose-path.md":"",".claude/skills/prototype/references/4-plan.md":"",".claude/skills/prototype/references/5-implement.md":"",".claude/skills/prototype/references/6-debrief.md":"",".claude/skills/prototype/references/7-report.md":"",".claude/skills/prototype/references/8-cd-review.md":"",".claude/skills/prototype/references/9-summary.md":"",".claude/skills/prototype/references/spike-mode.md":"",".claude/skills/qa-plan/SKILL.md":"",".claude/skills/quick-design/SKILL.md":"",".claude/skills/regression-suite/SKILL.md":"",".claude/skills/release-checklist/SKILL.md":"",".claude/skills/retrospective/SKILL.md":"",".claude/skills/reverse-document/SKILL.md":"",".claude/skills/review-all-gdds/SKILL.md":"",".claude/skills/review-all-gdds/references/1-load.md":"",".claude/skills/review-all-gdds/references/2-consistency.md":"",".claude/skills/review-all-gdds/references/3-design-holism.md":"",".claude/skills/review-all-gdds/references/4-scenarios.md":"",".claude/skills/review-all-gdds/references/5-report.md":"",".claude/skills/review-all-gdds/references/6-write.md":"",".claude/skills/review-all-gdds/references/7-handoff.md":"",".claude/skills/scope-check/SKILL.md":"",".claude/skills/security-audit/SKILL.md":"",".claude/skills/settings/SKILL.md":"",".claude/skills/setup-engine/SKILL.md":"",".claude/skills/setup-engine/references/11-upgrade.md":"",".claude/skills/setup-engine/references/12-output-summary.md":"",".claude/skills/setup-engine/references/2-guided-mode.md":"",".claude/skills/setup-engine/references/3-version.md":"",".claude/skills/setup-engine/references/4-claude-md-stack.md":"",".claude/skills/setup-engine/references/5-technical-preferences.md":"",".claude/skills/setup-engine/references/5.5-project-yaml.md":"",".claude/skills/setup-engine/references/6-knowledge-gap.md":"",".claude/skills/setup-engine/references/7-reference-docs.md":"",".claude/skills/setup-engine/references/7.5-scaffold.md":"",".claude/skills/setup-engine/references/8-verify.md":"",".claude/skills/setup-engine/references/godot-language-config.md":"",".claude/skills/skill-improve/SKILL.md":"",".claude/skills/skill-test/SKILL.md":"",".claude/skills/smoke-check/SKILL.md":"",".claude/skills/smoke-check/references/1-detect-setup.md":"",".claude/skills/smoke-check/references/2-run-tests.md":"",".claude/skills/smoke-check/references/3-coverage.md":"",".claude/skills/smoke-check/references/4-manual-checks.md":"",".claude/skills/smoke-check/references/5-report.md":"",".claude/skills/smoke-check/references/6-write-gate.md":"",".claude/skills/soak-test/SKILL.md":"",".claude/skills/sprint-plan/SKILL.md":"",".claude/skills/sprint-status/SKILL.md":"",".claude/skills/start/SKILL.md":"",".claude/skills/story-done/CONTRACT.md":"",".claude/skills/story-done/SKILL.md":"",".claude/skills/story-done/references/review-gates.md":"",".claude/skills/story-done/references/sprint-next.md":"",".claude/skills/story-done/references/tech-debt-row.md":"",".claude/skills/story-readiness/CONTRACT.md":"",".claude/skills/story-readiness/SKILL.md":"",".claude/skills/story-readiness/references/qa-lead-gate.md":"",".claude/skills/team-audio/SKILL.md":"",".claude/skills/team-combat/SKILL.md":"",".claude/skills/team-level/SKILL.md":"",".claude/skills/team-live-ops/SKILL.md":"",".claude/skills/team-narrative/SKILL.md":"",".claude/skills/team-polish/SKILL.md":"",".claude/skills/team-qa/SKILL.md":"",".claude/skills/team-release/SKILL.md":"",".claude/skills/team-ui/SKILL.md":"",".claude/skills/tech-debt/SKILL.md":"",".claude/skills/test-evidence-review/SKILL.md":"",".claude/skills/test-flakiness/SKILL.md":"",".claude/skills/test-helpers/SKILL.md":"",".claude/skills/test-setup/SKILL.md":"",".claude/skills/test-setup/references/1-detect.md":"",".claude/skills/test-setup/references/2-plan.md":"",".claude/skills/test-setup/references/3-directories.md":"",".claude/skills/test-setup/references/4-ci.md":"",".claude/skills/test-setup/references/5-smoke-seed.md":"",".claude/skills/test-setup/references/6-summary.md":"",".claude/skills/ux-design/SKILL.md":"",".claude/skills/ux-design/references/2-gather-context.md":"",".claude/skills/ux-design/references/3-file-skeleton.md":"",".claude/skills/ux-design/references/4-authoring.md":"",".claude/skills/ux-design/references/5-crossref-handoff.md":"",".claude/skills/ux-design/references/sections-hud.md":"",".claude/skills/ux-design/references/sections-patterns.md":"",".claude/skills/ux-design/references/sections-ux-spec.md":"",".claude/skills/ux-review/SKILL.md":"",".claude/skills/vertical-slice/SKILL.md":"","CLAUDE.md":"# Claude Code Game Studios -- Game Studio Agent Architecture\n\nIndie game development managed through 49 coordinated Claude Code subagents.\nEach agent owns a specific domain, enforcing separation of concerns and quality.\n\n## Technology Stack\n\n- **Engine**: [CHOOSE: Godot 4 / Unity / Unreal Engine 5]\n- **Language**: [CHOOSE: GDScript / C# / C++ / Blueprint]\n- **Version Control**: Git with trunk-based development\n- **Build System**: [SPECIFY after choosing engine]\n- **Asset Pipeline**: [SPECIFY after choosing engine]\n\n> **Note**: Engine-specialist agents exist for Godot, Unity, and Unreal with\n> dedicated sub-specialists. Use the set matching your engine.\n\n## Project Structure\n\n@.claude/docs/directory-structure.md\n\n## Engine Version Reference\n\n\n@docs/engine-reference/godot/VERSION.md\n\n\n## Technical Preferences\n\n`project.yaml` at the repo root is the primary config store — engine, specialists,\nnaming, platform, performance, modes. Skills resolve it via `resolve_config`\n(see `.claude/docs/config-resolution.md`).\n\n`.claude/docs/technical-preferences.md` is the **legacy fallback**, read on demand\nwhen a key is absent from `project.yaml`. It is not imported here: before\n`/setup-engine` runs it is almost entirely `[TO BE CONFIGURED]` placeholders, and\nafter it runs `project.yaml` holds the real values.\n\n## Coordination Rules\n\n@.claude/docs/coordination-rules.md\n\n## Collaboration Protocol\n\n**User-driven collaboration, not autonomous execution.**\nEvery task follows: **Question -> Options -> Decision -> Draft -> Approval**\n\n- Agents MUST ask \"May I write this to [filepath]?\" before using Write/Edit tools\n (exempt: `active.md` appends, agent memory, a subagent's new file at the path\n its orchestrating skill named; see `.claude/rules/agent-memory.md`)\n- Agents MUST show drafts or summaries before requesting approval\n- Multi-file changes require explicit approval for the full changeset\n- No commits without user instruction\n- A skipped or dismissed question is not an answer: act on nothing, re-ask in\n plain text and wait\n- Started outside this file's folder? Warn first: hooks, deny rules and the\n ask-first mode load only when Claude Code starts here\n\nSee `docs/COLLABORATIVE-DESIGN-PRINCIPLE.md` for full protocol and examples.\n\n> **First session?** If the project has no engine configured and no game concept,\n> run `/start` to begin the guided onboarding flow.\n\n## Coding Standards\n\n@.claude/docs/coding-standards.md\n\n## Context Management\n\nRead `.claude/docs/context-management.md` on demand — it is a reference, not\nsession context. Two of its conventions are load-bearing and cited by name\nelsewhere in the repo, so they are restated here rather than lost:\n\n- **`production/session-state/active.md` is the session checkpoint.** The file is\n the memory, not the conversation. Read it first after any compaction, crash, or\n `/clear`.\n- **Helpers in `.claude/scripts/` emit observations, never verdicts.** A script\n that scores or judges will eventually contradict a mode or override it cannot\n see. (Cited by `artifact-check.sh` and `adr-dep-graph.sh`.)\n","design/CLAUDE.md":"# Design Directory\n\nWhen authoring or editing files in this directory, follow these standards.\n\n## GDD Files (`design/gdd/`)\n\nThe 8 GDD sections, in order:\n1. Overview — one-paragraph summary\n2. Player Fantasy — intended feeling and experience\n3. Detailed Rules — unambiguous mechanics\n4. Formulas — all math defined with variables\n5. Edge Cases — unusual situations handled\n6. Dependencies — other systems listed\n7. Tuning Knobs — configurable values identified\n8. Acceptance Criteria — testable success conditions\n\n**How many are REQUIRED depends on `modes.workflow`** — all 8 at `full`; 5 at\n`standard` (Overview, Detailed Rules, Edge Cases, Dependencies, Acceptance\nCriteria, plus Formulas when the system has math); none at `minimal`, where\n`design/game-brief.md` is the design record instead of a GDD. Resolve the tier\nbefore flagging a section as missing — see `.claude/docs/workflow-modes.md`.\n\n> **Three other places already encode the tier rule** —\n> `.claude/docs/coding-standards.md`, `.claude/rules/design-docs.md` and\n> `.claude/hooks/validate-commit.sh`. This file is the copy a session working in\n> `design/` reads first, so it must agree with them: demanding all 8 at\n> `minimal` warns a jam project about six sections its own configuration says it\n> does not need, which trains the user to ignore the warning.\n\n**Section-name alias:** the GDD template and `/design-system` author section 3\nas `## Detailed Design`; the standard calls it **Detailed Rules**. Same required\nsection — accept either heading, never rewrite one into the other.\n\n**File naming:** `[system-slug].md` (e.g. `movement-system.md`, `combat-system.md`)\n\n**Systems index:** `design/gdd/systems-index.md` — update when adding a new GDD.\n\n**Design order:** Foundation → Core → Feature → Presentation → Polish\n\n**Validation:** Run `/design-review [path]` after authoring any GDD.\nRun `/review-all-gdds` after completing a set of related GDDs.\n\n## Quick Specs (`design/quick-specs/`)\n\nLightweight specs for tuning changes, minor mechanics, or balance adjustments.\nUse `/quick-design` to author.\n\n## UX Specs (`design/ux/`)\n\n- Per-screen specs: `design/ux/[screen-name].md`\n- HUD design: `design/ux/hud.md`\n- Interaction pattern library: `design/ux/interaction-patterns.md`\n- Accessibility requirements: `design/accessibility-requirements.md`\n\nUse `/ux-design` to author. Validate with `/ux-review` before passing to `/team-ui`.\n\n> **Accessibility requirements sit OUTSIDE `design/ux/` on purpose.** They are a\n> project-wide standard the per-screen specs consult, not a spec for one screen.\n> `.claude/docs/workflow-catalog.yaml`, the Pre-Production, Production and Polish\n> gates, and `/architecture-review` all check `design/accessibility-requirements.md`\n> at that exact path. Do not \"tidy\" it under `design/ux/` — every one of those\n> checks would stop matching, and the Technical Setup → Pre-Production gate would\n> become unpassable. `/ux-design` states the same rule at its `accessibility` mode.\n","docs/CLAUDE.md":"# Docs Directory\n\nWhen authoring or editing files in this directory, follow these standards.\n\n## Architecture Decision Records (`docs/architecture/`)\n\nUse the ADR template: `.claude/docs/templates/architecture-decision-record.md`\n\n**Required sections:** Title, Status, Context, Decision, Consequences,\nADR Dependencies, Engine Compatibility, GDD Requirements Addressed\n\n**Status lifecycle:** `Proposed` → `Accepted` → `Superseded`\n- Never skip `Accepted` — stories referencing a `Proposed` ADR are auto-blocked\n- Use `/architecture-decision` to create ADRs through the guided flow\n\n**TR Registry:** `docs/architecture/tr-registry.yaml`\n- Stable requirement IDs (e.g. `TR-movement-001`) that link GDD requirements to stories\n- Never renumber existing IDs — only append new ones\n- Updated by `/architecture-review` Phase 8\n\n**Control Manifest:** `docs/architecture/control-manifest.md`\n- Flat programmer rules sheet: Required / Forbidden / Guardrails per layer\n- Date-stamped `Manifest Version:` in header\n- Stories embed this version; `/story-done` checks for staleness\n\n**Validation:** Run `/architecture-review` after completing a set of ADRs.\n\n## Engine Reference (`docs/engine-reference/`)\n\nVersion-pinned engine API snapshots. **Always check here before using any\nengine API** — the LLM's training data predates the pinned engine version.\n\nCurrent engine: see `docs/engine-reference//VERSION.md` (`` is `godot`, `unity` or `unreal`, matching `engine.name` in `project.yaml`)\n","docs/engine-reference/unity/plugins/addressables.md":"","docs/engine-reference/unity/plugins/cinemachine.md":"","docs/engine-reference/unity/plugins/dots-entities.md":"","docs/engine-reference/unreal/plugins/common-ui.md":"","docs/engine-reference/unreal/plugins/gameplay-ability-system.md":"","docs/engine-reference/unreal/plugins/gameplay-camera-system.md":"","docs/engine-reference/unreal/plugins/pcg.md":"","src/CLAUDE.md":"# Source Directory\n\nWhen writing or editing game code in this directory, follow these standards.\n\n## Engine Version Warning\n\nThe LLM's training data predates the pinned engine version.\n**Always check `docs/engine-reference/` before using any engine API.**\nDo not guess at post-cutoff API signatures — look them up first.\n\n## Coding Standards\n\n- All public APIs require doc comments\n- Gameplay values must be **data-driven** (external config files), never hardcoded\n- Prefer dependency injection over singletons for testability\n- Architecture decisions go in `docs/architecture/` as ADRs — **how many depends on\n `modes.workflow`**: all at `full`, critical only at `standard`, none required at\n `minimal` (the decision log carries them)\n- Commits must reference the relevant story ID or design document\n\n## File Routing\n\nMatch the engine-specialist agent to the file type being written.\n`/setup-engine` records which specialist handles code, shaders and UI in the\n`specialists` block of `project.yaml`.\n\nWhen in doubt, use `specialists.code` from `project.yaml`.\n\n## Tests\n\nTests live in `tests/` — not in `src/`.\nRun `/test-setup` to scaffold the test framework if it doesn't exist yet.\nEvery gameplay system should have unit tests covering its formulas and edge cases.\n\n## Verification-Driven Development\n\nWrite tests first when adding gameplay systems.\nFor UI changes, verify with screenshots.\nCompare expected output to actual output before marking work complete.\n","studio-tests/CLAUDE.md":"# Studio Tests — Claude Instructions\n\nThis folder is the quality assurance layer for the Claude Code Game Studios skill/agent\nframework. It is self-contained and separate from any game project.\n\n## Key files\n\n| File | Purpose |\n|------|---------|\n| `catalog.yaml` | Master registry for all 74 skills and 49 agents. Contains category, spec path, and last-test tracking fields. Always read this first when running any test command. |\n| `quality-rubric.md` | Category-specific pass/fail metrics. Read the matching `###` section for the skill's category when running `/skill-test category`. |\n| `skills/[category]/[name].md` | Behavioral spec for a skill — 5 or more test cases + protocol compliance assertions. |\n| `agents/[tier]/[name].md` | Behavioral spec for an agent — 5 or more test cases + protocol compliance assertions. |\n| `templates/skill-test-spec.md` | Template for writing new skill spec files. |\n| `templates/agent-test-spec.md` | Template for writing new agent spec files. |\n| `results/` | Written by `/skill-test spec` when results are saved. Not gitignored — add it to `.gitignore` to keep results out of commits. |\n\n## Path conventions\n\n- Skill specs: `studio-tests/skills/[category]/[name].md`\n- Agent specs: `studio-tests/agents/[tier]/[name].md`\n- Catalog: `studio-tests/catalog.yaml`\n- Rubric: `studio-tests/quality-rubric.md`\n\nThe `spec:` field in `catalog.yaml` is the authoritative path for each skill/agent spec.\nAlways read it rather than guessing the path.\n\n## Skill categories\n\n```\ngate → gate-check\nreview → design-review, architecture-review, review-all-gdds\nauthoring → design-system, quick-design, architecture-decision, art-bible,\n create-architecture, ux-design, ux-review\nreadiness → story-readiness, story-done\npipeline → create-epics, create-stories, dev-story, create-control-manifest,\n propagate-design-change, map-systems, vertical-slice\nanalysis → consistency-check, balance-check, content-audit, code-review,\n tech-debt, scope-check, estimate, perf-profile, asset-audit,\n security-audit, test-evidence-review, test-flakiness\nteam → team-combat, team-narrative, team-audio, team-level, team-ui,\n team-qa, team-release, team-polish, team-live-ops\nsprint → sprint-plan, sprint-status, milestone-review, retrospective,\n changelog, patch-notes\nutility → all remaining skills\n```\n\n## Agent tiers\n\n```\ndirectors → creative-director, technical-director, producer, art-director\nleads → lead-programmer, narrative-director, audio-director, game-designer,\n systems-designer, level-designer, qa-lead\nspecialists → gameplay-programmer, engine-programmer, network-programmer,\n ai-programmer, tools-programmer, ui-programmer, ux-designer,\n technical-artist, sound-designer, performance-analyst, prototyper,\n writer, world-builder\nengine/godot → godot-specialist, godot-gdscript-specialist, godot-csharp-specialist,\n godot-shader-specialist, godot-gdextension-specialist\nengine/unity → unity-specialist, unity-ui-specialist, unity-shader-specialist,\n unity-dots-specialist, unity-addressables-specialist\nengine/unreal → unreal-specialist, ue-gas-specialist, ue-replication-specialist,\n ue-umg-specialist, ue-blueprint-specialist\noperations → devops-engineer, release-manager, live-ops-designer,\n community-manager, analytics-engineer, economy-designer,\n localization-lead\nqa → qa-tester, security-engineer, accessibility-specialist\n```\n\nA tier is the directory a spec lives in. The rubric category is the agent's\n`category:` in `catalog.yaml` and can differ: `security-engineer` and\n`accessibility-specialist` sit in `qa/` but are rated as `specialist`.\n\n## Workflow for testing a skill or agent\n\n1. Read `catalog.yaml` to get the `spec:` path and `category:` — from the\n `skills:` entry for a skill, the `agents:` entry for an agent\n2. Read the skill at `.claude/skills/[name]/SKILL.md` and every file in its\n `references/` folder, or the agent at `.claude/agents/[name].md`\n3. Read the project `CLAUDE.md` and the files it imports with `@`: every\n subagent receives them, so a rule stated there (for example a redirect in\n `coordination-rules.md`) counts as the skill's or agent's own\n4. Read the spec at the `spec:` path\n5. Evaluate the spec's Static Assertions, each case's assertions, and its\n Protocol Compliance list\n6. Offer to write results to `results/` and update `catalog.yaml`\n\n## Fixture defaults\n\nEvery skill spec has a `## Fixture Defaults` section above its cases. A case's\nsandbox project starts from this `project.yaml` block:\n\n```yaml\nmodes:\n rigor: minimal # → workflow minimal, docs.density terse, qa.level minimal,\n # story_granularity coarse, review_mode solo, team.size individual\n automation: collaborative\n```\n\n- A setting the case's Fixture names wins over the block, and an explicit\n sub-knob (`modes.workflow`, `modes.review_mode`, `qa.level`, …) wins over the\n `rigor` preset (`.claude/docs/config-resolution.md` § Defaults).\n- A case that says `project.yaml` sets no `modes` keys, or that there is no\n `project.yaml`, runs without the block: it tests the unset defaults.\n- There is no `project.local.yaml` unless the case names one.\n- A case whose expected behaviour changes with a setting pins that setting in\n its own Fixture, with the reason — e.g. `modes.workflow: standard` (pinned:\n unset resolves to minimal, which recommends the next build instead of a\n sprint).\n\nThe block is pinned so that a change to the framework's defaults cannot\nsilently change what a case tests. A spec may set a different default in its\nown section when most of its cases need one.\n\n## Workflow for improving a skill\n\nUse `/skill-improve [name]`. It handles the full loop:\ntest → diagnose → propose fix → rewrite → retest → keep or revert.\n\n## Spec validity note\n\nSpecs in this folder assert the **correct** behavior, not whatever a skill or agent\ndoes today. A failing assertion means the skill or agent is wrong until shown\notherwise: fix it and re-run, and never weaken an assertion just so it passes.\nSpecs can be wrong too — when one asserts behavior that is itself incorrect,\ncorrect the spec toward the right behavior, not toward what the skill currently does.\n\n## This folder is deletable\n\nNothing in `.claude/` imports from here, and every other CCGS skill and agent works\nwithout it — but `/skill-test` and `/skill-improve` read it by path. Without it,\n`/skill-test static` still works, `/skill-test spec` and `/skill-test category`\nstop working, `/skill-test audit` reports that no catalog exists, and\n`/skill-improve` skips its category checks (the table in `README.md` has the detail).\n","studio-tests/skills/analysis/asset-audit.md":"","studio-tests/skills/analysis/balance-check.md":"","studio-tests/skills/analysis/code-review.md":"","studio-tests/skills/analysis/consistency-check.md":"","studio-tests/skills/analysis/content-audit.md":"","studio-tests/skills/analysis/estimate.md":"","studio-tests/skills/analysis/perf-profile.md":"","studio-tests/skills/analysis/scope-check.md":"","studio-tests/skills/analysis/security-audit.md":"","studio-tests/skills/analysis/tech-debt.md":"","studio-tests/skills/analysis/test-evidence-review.md":"","studio-tests/skills/analysis/test-flakiness.md":"","studio-tests/skills/authoring/architecture-decision.md":"","studio-tests/skills/authoring/art-bible.md":"","studio-tests/skills/authoring/create-architecture.md":"","studio-tests/skills/authoring/design-system.md":"","studio-tests/skills/authoring/quick-design.md":"","studio-tests/skills/authoring/ux-design.md":"","studio-tests/skills/authoring/ux-review.md":"","studio-tests/skills/gate/gate-check.md":"","studio-tests/skills/pipeline/create-control-manifest.md":"","studio-tests/skills/pipeline/create-epics.md":"","studio-tests/skills/pipeline/create-stories.md":"","studio-tests/skills/pipeline/dev-story.md":"","studio-tests/skills/pipeline/map-systems.md":"","studio-tests/skills/pipeline/propagate-design-change.md":"","studio-tests/skills/pipeline/vertical-slice.md":"","studio-tests/skills/readiness/story-done.md":"","studio-tests/skills/readiness/story-readiness.md":"","studio-tests/skills/review/architecture-review.md":"","studio-tests/skills/review/design-review.md":"","studio-tests/skills/review/review-all-gdds.md":"","studio-tests/skills/sprint/changelog.md":"","studio-tests/skills/sprint/milestone-review.md":"","studio-tests/skills/sprint/patch-notes.md":"","studio-tests/skills/sprint/retrospective.md":"","studio-tests/skills/sprint/sprint-plan.md":"","studio-tests/skills/sprint/sprint-status.md":"","studio-tests/skills/team/team-audio.md":"","studio-tests/skills/team/team-combat.md":"","studio-tests/skills/team/team-level.md":"","studio-tests/skills/team/team-live-ops.md":"","studio-tests/skills/team/team-narrative.md":"","studio-tests/skills/team/team-polish.md":"","studio-tests/skills/team/team-qa.md":"","studio-tests/skills/team/team-release.md":"","studio-tests/skills/team/team-ui.md":"","studio-tests/skills/utility/adopt.md":"","studio-tests/skills/utility/asset-spec.md":"","studio-tests/skills/utility/brainstorm.md":"","studio-tests/skills/utility/bug-report.md":"","studio-tests/skills/utility/bug-triage.md":"","studio-tests/skills/utility/day-one-patch.md":"","studio-tests/skills/utility/help.md":"","studio-tests/skills/utility/hotfix.md":"","studio-tests/skills/utility/launch-checklist.md":"","studio-tests/skills/utility/localize.md":"","studio-tests/skills/utility/onboard.md":"","studio-tests/skills/utility/playtest-report.md":"","studio-tests/skills/utility/project-stage-detect.md":"","studio-tests/skills/utility/prototype.md":"","studio-tests/skills/utility/qa-plan.md":"","studio-tests/skills/utility/regression-suite.md":"","studio-tests/skills/utility/release-checklist.md":"","studio-tests/skills/utility/reverse-document.md":"","studio-tests/skills/utility/settings.md":"","studio-tests/skills/utility/setup-engine.md":"","studio-tests/skills/utility/skill-improve.md":"","studio-tests/skills/utility/skill-test.md":"","studio-tests/skills/utility/smoke-check.md":"","studio-tests/skills/utility/soak-test.md":"","studio-tests/skills/utility/start.md":"","studio-tests/skills/utility/test-helpers.md":"","studio-tests/skills/utility/test-setup.md":""},"files":{".claude/agents/accessibility-specialist.md":"",".claude/agents/ai-programmer.md":"",".claude/agents/analytics-engineer.md":"",".claude/agents/art-director.md":"",".claude/agents/audio-director.md":"",".claude/agents/community-manager.md":"",".claude/agents/creative-director.md":"",".claude/agents/devops-engineer.md":"",".claude/agents/economy-designer.md":"",".claude/agents/engine-programmer.md":"",".claude/agents/game-designer.md":"",".claude/agents/gameplay-programmer.md":"",".claude/agents/godot-csharp-specialist.md":"",".claude/agents/godot-gdextension-specialist.md":"",".claude/agents/godot-gdscript-specialist.md":"",".claude/agents/godot-shader-specialist.md":"",".claude/agents/godot-specialist.md":"",".claude/agents/lead-programmer.md":"",".claude/agents/level-designer.md":"",".claude/agents/live-ops-designer.md":"",".claude/agents/localization-lead.md":"",".claude/agents/narrative-director.md":"",".claude/agents/network-programmer.md":"",".claude/agents/performance-analyst.md":"",".claude/agents/producer.md":"",".claude/agents/prototyper.md":"",".claude/agents/qa-lead.md":"",".claude/agents/qa-tester.md":"",".claude/agents/release-manager.md":"",".claude/agents/security-engineer.md":"",".claude/agents/sound-designer.md":"",".claude/agents/systems-designer.md":"",".claude/agents/technical-artist.md":"",".claude/agents/technical-director.md":"",".claude/agents/tools-programmer.md":"",".claude/agents/ue-blueprint-specialist.md":"",".claude/agents/ue-gas-specialist.md":"",".claude/agents/ue-replication-specialist.md":"",".claude/agents/ue-umg-specialist.md":"",".claude/agents/ui-programmer.md":"",".claude/agents/unity-addressables-specialist.md":"",".claude/agents/unity-dots-specialist.md":"",".claude/agents/unity-shader-specialist.md":"",".claude/agents/unity-specialist.md":"",".claude/agents/unity-ui-specialist.md":"",".claude/agents/unreal-specialist.md":"",".claude/agents/ux-designer.md":"",".claude/agents/world-builder.md":"",".claude/agents/writer.md":"",".claude/rules/agent-memory.md":"---\npaths:\n - \".claude/agent-memory/**\"\n---\n\n# Agent Memory Rules\n\n**Agent memory is one of three writes that need no \"May I write?\"** The other two\nare named in `CLAUDE.md`:\n\n- **Appends to `production/session-state/active.md`** — the session checkpoint\n the hooks and the next session rely on. An append, never a rewrite of what is\n already there.\n- **A subagent's new file at the path its orchestrating skill named.** Only a\n new file under `production/`, `docs/` or `tests/`, only at a path the skill's\n prompt names (never one you chose), and only inside a phase the user approved.\n\n`.claude/agent-memory/` is gitignored, per-agent, and never ships. Its exemption\nexists because the memory is the agent's own working notes about how to do its\njob, not a project artifact.\n\nNone of the three extends anywhere else. The Collaboration Protocol still governs\nevery other write under the code root (`src/`, `Assets/` or `Source/`),\n`design/`, `docs/`, `production/` and `assets/`: ask first, naming the path.\nWriting a memory is never a substitute for asking, and a memory must never be\nused to record something the user declined to have written.\n\n## Never record a temporary absence as a durable fact\n\nThis is the failure this file exists to prevent, and this repo is unusually\nexposed to it.\n\n**CCGS ships as a template the user clones *as their game*.** So on day one every\nagent observes the same things — no game code, no GDDs, no engine configured, no\n`tests/performance/` — and every one of those observations is **guaranteed to\nstop being true**. A memory reading *\"this repo is the framework, not a game;\nperf requests have no target\"* is accurate when written and actively harmful two\nweeks later, when it tells a future run to return BLOCKED on a project that now\nhas a build. The agent will not re-derive it; that is what memory is for.\n\nSo:\n\n- **Prefer recording a method over a state.** \"Confirm an engine project and a\n captured profile exist before profiling; return BLOCKED naming what is missing\n rather than estimating\" is durable. \"There is no game here\" is a timestamp.\n- **If you must record a state, state what invalidates it**, on the same line:\n `INVALIDATED WHEN: project.yaml declares an engine, or the code root (src/, Assets/ or Source/) contains game code.`\n A reader with no other context must be able to tell whether the note still\n holds.\n- **Never record absence of a game, of assets, of tests or of config as a\n settled property of the project.** Those are the states CCGS exists to move a\n user out of.\n\n## Disclose the write\n\nSay in your response that you recorded a memory and where. An unmentioned write\nis indistinguishable from no write, and the user cannot correct a note they do\nnot know exists — the same reason a skipped check has to announce itself\n(`.claude/rules/skill-authoring.md`, obligation 3).\n\n## Verify before you trust\n\nA recalled memory reflects what was true when it was written. If it names a file,\na path, a setting or a count, **check that it still holds before acting on it**.\nMemory is a starting point for investigation, never evidence.\n",".claude/rules/ai-code.md":"---\npaths:\n - \"src/ai/**\"\n - \"Assets/**/{AI,Ai,ai}/**/*.cs\"\n - \"Source/**/{AI,Ai,ai}/**/*.{h,cpp}\"\n---\n\n# AI Code Rules\n\n- AI update budget: 2ms per frame maximum — profile to verify\n- All AI parameters must be tunable from data files (behavior tree weights, perception ranges, timers)\n- AI must be debuggable: implement visualization hooks for all AI state (paths, perception cones, decision trees)\n- AI should telegraph intentions — players need time to read and react\n- Prefer utility-based or behavior tree approaches over hard-coded if/else chains\n- Group AI must support formation, flanking, and role assignment from data\n- All AI state machines must log transitions for debugging\n- Never trust AI input from the network without validation\n",".claude/rules/data-files.md":"---\npaths:\n - \"assets/data/**/*.json\"\n - \"Assets/**/{Data,data}/**/*.json\"\n - \"Content/**/{Data,data}/**/*.json\"\n---\n\n# Data File Rules\n\n- All JSON files must be valid JSON — broken JSON blocks the entire build pipeline\n- File naming: lowercase with underscores only, following `[system]_[name].json` pattern\n- Every data file must have a documented schema (either JSON Schema or documented in the corresponding design doc)\n- Numeric values must include comments or companion docs explaining what the numbers mean\n- Use consistent key naming: **`snake_case` for keys within JSON files**, matching\n the `[system]_[name].json` file convention one line above and the engine idiom\n every other standard in this repo uses.\n\n > **On Unity and Unreal this costs you a mapping layer — budget for it rather\n > than changing the keys.** `JsonUtility` binds by *exact field name*, and C#\n > fields are `camelCase` per `naming.variables`, so a snake_case file cannot bind\n > directly to the type that consumes it. Use a private nested DTO whose fields\n > are the wire format and which maps once into your real type, or take a\n > dependency that supports a naming policy (Newtonsoft `SnakeCaseNamingStrategy`,\n > `System.Text.Json` `JsonNamingPolicy`). Do **not** switch the file to camelCase\n > to avoid the DTO: keys are the cross-engine contract. Write the DTO and\n > document it as a wire-format boundary — that is the intended shape.\n- No orphaned data entries — every entry must be referenced by code or another data file\n- Version data files when making breaking schema changes\n- Include sensible defaults for all optional fields\n\n## Examples\n\n**Correct** naming and structure (`combat_enemies.json`):\n\n```json\n{\n \"goblin\": {\n \"base_health\": 50,\n \"base_damage\": 8,\n \"move_speed\": 3.5,\n \"loot_table\": \"loot_goblin_common\"\n },\n \"goblin_chief\": {\n \"base_health\": 150,\n \"base_damage\": 20,\n \"move_speed\": 2.8,\n \"loot_table\": \"loot_goblin_rare\"\n }\n}\n```\n\n**Incorrect** (`EnemyData.json`):\n\n```json\n{\n \"Goblin\": { \"hp\": 50 }\n}\n```\n\nViolations: uppercase filename, uppercase key, no `[system]_[name]` pattern, missing required fields.\n",".claude/rules/design-docs.md":"---\npaths:\n - \"design/gdd/**\"\n---\n\n# Design Document Rules\n\n- The 8 GDD sections are: Overview, Player Fantasy, Detailed Rules, Formulas, Edge Cases, Dependencies, Tuning Knobs, Acceptance Criteria\n- **How many are required depends on `modes.workflow`** — all 8 at `full`, 5 (+ Formulas when the system **defines numeric rules**: rates, curves, thresholds, costs, damage, drop weights — anything a balance pass would tune) at `standard`, none at `minimal` (the design record there is `design/game-brief.md`). Resolve the tier before flagging a section as missing; see `.claude/docs/workflow-modes.md`\n- **The Formulas test is what the system defines, not what it is called.** A system's `Category` in `systems-index.md` is a hint — `Gameplay`, `Economy` and `Progression` almost always qualify — never the test. Do not gate Formulas on a category token: the categories `/map-systems` writes (`Core · Gameplay · Progression · Economy · Persistence · UI · Audio · Narrative · Meta`) do not include `combat` or `AI`, which are example systems *within* `Gameplay`. Every site stating this rule must state the same test.\n- **Section-name alias**: The GDD template and `/design-system` author this section as `## Detailed Design`; the design standard calls it **Detailed Rules**. These are the SAME required section — accept either heading and never rewrite one into the other.\n- Formulas must include variable definitions, expected value ranges, and example calculations\n- Edge cases must explicitly state what happens, not just \"handle gracefully\"\n- Dependencies must be bidirectional — if system A depends on B, B's doc must mention A\n- Tuning knobs must specify safe ranges and what gameplay aspect they affect\n- Acceptance criteria must be testable — a QA tester must be able to verify pass/fail\n- No hand-waving: \"the system should feel good\" is not a valid specification\n- Balance values must link to their source formula or rationale\n- Design documents MUST be written incrementally: create skeleton first, then fill\n each section one at a time with user approval between sections. Write each\n approved section to the file immediately to persist decisions and manage context\n",".claude/rules/engine-code.md":"---\npaths:\n - \"src/core/**\"\n - \"Assets/**/{Core,core}/**/*.cs\"\n - \"Source/**/{Core,core}/**/*.{h,cpp}\"\n---\n\n# Engine Code Rules\n\n- ZERO allocations in hot paths (update loops, rendering, physics) — pre-allocate, pool, reuse\n- All engine APIs must be thread-safe OR explicitly documented as single-thread-only\n- Profile before AND after every optimization — document the measured numbers\n- Engine code must NEVER depend on gameplay code (strict dependency direction: engine <- gameplay)\n- Every public API must have usage examples in its doc comment\n- Changes to public interfaces require a deprecation period and migration guide\n- Use RAII / deterministic cleanup for all resources\n- All engine systems must support graceful degradation\n- Before writing engine API code, consult `docs/engine-reference/` for the current engine version and verify APIs against the reference docs\n\n## Examples\n\n**Correct** (zero-alloc hot path) — Godot:\n\n```gdscript\n# Pre-allocated array reused each frame\nvar _nearby_cache: Array[Node3D] = []\n\nfunc _physics_process(delta: float) -> void:\n _nearby_cache.clear() # Reuse, don't reallocate\n _spatial_grid.query_radius(position, radius, _nearby_cache)\n```\n\nUnity:\n\n```csharp\nprivate readonly Collider[] _nearbyCache = new Collider[64]; // allocated once\n\nvoid FixedUpdate()\n{\n int count = Physics.OverlapSphereNonAlloc(transform.position, radius, _nearbyCache);\n}\n```\n\nUnreal:\n\n```cpp\n// TArray member, reserved once; Reset() keeps the allocation\nvoid UProximityComponent::TickComponent(float DeltaTime, ELevelTick TickType,\n FActorComponentTickFunction* ThisTickFunction)\n{\n NearbyCache.Reset();\n SpatialGrid->QueryRadius(GetComponentLocation(), Radius, NearbyCache);\n}\n```\n\n**Incorrect** (allocating in hot path):\n\n```gdscript\nfunc _physics_process(delta: float) -> void:\n var nearby: Array[Node3D] = [] # VIOLATION: allocates every frame\n nearby = get_tree().get_nodes_in_group(\"enemies\") # VIOLATION: tree query every frame\n```\n",".claude/rules/gameplay-code.md":"---\npaths:\n - \"src/gameplay/**\"\n - \"Assets/**/{Gameplay,gameplay}/**/*.cs\"\n - \"Source/**/{Gameplay,gameplay}/**/*.{h,cpp}\"\n---\n\n# Gameplay Code Rules\n\n- ALL gameplay values MUST come from external config/data files, NEVER hardcoded\n- Use delta time for ALL time-dependent calculations (frame-rate independence)\n- NO direct references to UI code — use events for cross-system communication\n (Godot signals, C# events, Unreal delegates)\n- Every gameplay system must implement a clear interface\n- State machines must have explicit transition tables with documented states\n- Write unit tests for all gameplay logic — separate logic from presentation\n- Document which design doc each feature implements in code comments\n- No static singletons for game state — use dependency injection\n\n## Examples\n\n**Correct** (data-driven) — Godot:\n\n```gdscript\nvar damage: float = config.get_value(\"combat\", \"base_damage\", 10.0)\nvar speed: float = stats_resource.movement_speed * delta\n```\n\nUnity (values from a ScriptableObject):\n\n```csharp\nfloat damage = combatConfig.BaseDamage;\nfloat speed = stats.MovementSpeed * Time.deltaTime;\n```\n\nUnreal (values from a data asset):\n\n```cpp\nconst float Damage = CombatConfig->BaseDamage;\nconst float Speed = Stats->MovementSpeed * DeltaTime;\n```\n\n**Incorrect** (hardcoded):\n\n```gdscript\nvar damage: float = 25.0 # VIOLATION: hardcoded gameplay value\nvar speed: float = 5.0 # VIOLATION: not from config, not using delta\n```\n",".claude/rules/narrative.md":"---\npaths:\n - \"design/narrative/**\"\n---\n\n# Narrative Rules\n\n- All new lore must be cross-referenced against existing lore for contradictions\n- Every lore entry must specify canon level: Established / Provisional / Under Review\n- Character dialogue must match the voice profile defined for that character\n- World rules (what is possible/impossible) must be explicitly documented and consistent\n- Mysteries must have documented \"true answers\" even if players never learn them\n- Faction motivations, relationships, and power structures must be internally logical\n- All narrative text must be localization-ready: no idioms that don't translate, named placeholders for variables\n- No line of dialogue should exceed 120 characters for dialogue box constraints\n",".claude/rules/network-code.md":"---\npaths:\n - \"src/networking/**\"\n - \"Assets/**/{Networking,networking,Network,network}/**/*.cs\"\n - \"Source/**/{Networking,networking,Network,network}/**/*.{h,cpp}\"\n---\n\n# Network Code Rules\n\n- Server is AUTHORITATIVE for all gameplay-critical state — never trust the client\n- All network messages must be versioned for forward/backward compatibility\n- Client predicts locally, reconciles with server — implement rollback for mispredictions\n- Handle disconnection, reconnection, and host migration gracefully\n- Rate-limit all network logging to prevent log flooding\n- All networked values must specify replication strategy: reliable/unreliable, frequency, interpolation\n- Bandwidth budget: define and track per-message-type bandwidth usage\n- Security: validate all incoming packet sizes and field ranges\n",".claude/rules/prototype-code.md":"---\npaths:\n - \"prototypes/**\"\n---\n\n# Prototype Code Standards (Relaxed)\n\nPrototypes are throwaway code for validating ideas. Standards are intentionally\nrelaxed to maximize iteration speed. The goal is learning, not production quality.\n\n## What's Allowed in Prototypes\n- Hardcoded values (no need for data-driven config)\n- Minimal or no doc comments\n- Simple architecture (no dependency injection required)\n- Singletons and global state\n- Copy-pasted code (no need for abstraction)\n- Debug output left in place\n- Placeholder art and audio\n- Quick-and-dirty solutions\n\n## What's Still Required\n- Each prototype lives in its own subdirectory: `prototypes/[name]/`\n- Every prototype MUST have a `README.md` with:\n - What hypothesis is being tested\n - How to run the prototype\n - Current status (in-progress / concluded)\n - Findings (updated when prototype concludes)\n- No production code may reference or import from `prototypes/`\n- Prototypes must not modify files outside `prototypes/`\n- Prototypes must not be deployed or shipped\n\n## When a Prototype Succeeds\nIf a prototype validates a concept and the feature moves to production:\n1. The prototype code is NOT migrated directly — it is rewritten to production standards\n2. The prototype `README.md` findings inform the production design document\n3. The prototype directory is preserved for reference but never extended\n\n## Cleanup\nConcluded prototypes should be archived or deleted after findings are captured.\nNever let prototype code grow into production code through incremental \"cleanup.\"\n",".claude/rules/scene-files.md":"---\npaths:\n - \"**/*.tscn\"\n - \"**/*.tres\"\n - \"**/*.unity\"\n - \"**/*.prefab\"\n - \"Assets/**/*.asset\"\n---\n\n# Scene and Asset File Rules\n\nThe engine's editor writes these files. A hand edit that breaks one can stop a\nscene loading, or drop references without an error. Change them in the editor\nwhen you can.\n\n## Godot (`.tscn`, `.tres`, `.uid`)\n\nWhen you edit the text by hand:\n\n- Never change the `format=` value in the `[gd_scene]` or `[gd_resource]` header.\n- Never reuse an `id`: every `[ext_resource]` and `[sub_resource]` id is unique in its file.\n- Never copy a node block with its `unique_id=` (Godot 4.6+). Drop it from the copy.\n- Never invent a `uid://` value. Leave `uid=` off a new reference and let the\n editor or `godot --headless --path . --import` assign it.\n- Never hand-edit TileMapLayer or GridMap cell data. It is encoded, so change it in the editor.\n- Never edit or delete a `.uid` file, and commit it with its script or shader.\n Godot 4.4+ writes one beside each; when you move or rename the script or\n shader outside the editor, move its `.uid` with it.\n- After a hand edit, run `godot --headless --path . --import` and open or run\n the scene once to confirm it loads without errors.\n\n## Unity (`.unity`, `.prefab`, `.asset`)\n\n- Never hand-edit `.unity`, `.prefab` or `.asset` YAML while a Unity Editor is\n reachable: open on this project, or reachable through its command-line or MCP\n tools. The Editor holds its own copy, and its next save can overwrite or\n conflict with the edit. Make the change through the Editor, or hand the user\n the steps. If you cannot tell whether an Editor is reachable, treat it as reachable.\n- With no Editor reachable, keep every `fileID` and `guid` reference intact,\n never invent a GUID, never edit or delete a `.meta` file, and open the scene\n in the Editor afterwards to confirm it loads.\n",".claude/rules/shader-code.md":"---\npaths:\n - \"assets/shaders/**\"\n - \"**/*.gdshader\"\n - \"Assets/**/*.{shader,hlsl,cginc,compute,shadergraph}\"\n - \"Shaders/**\"\n - \"**/*.{usf,ush}\"\n---\n\n# Shader Code Standards\n\nAll shader files, in every engine, must follow these standards to maintain\nvisual quality, performance, and cross-platform compatibility.\n\n## Naming Conventions\n- File naming: `[type]_[category]_[name].[ext]`\n - `spatial_env_water.gdshader` (Godot)\n - `SG_Env_Water` (Unity Shader Graph)\n - `M_Env_Water` (Unreal Material)\n- Use descriptive names that indicate the material purpose\n- Prefix with the engine's shader type — Godot `spatial_`, `canvas_`, `particles_`,\n `post_`; Unity `SG_` (Shader Graph); Unreal `M_`, `MI_` (instance), `MF_` (function)\n\n## Code Quality\n- All uniforms/parameters must have descriptive names and appropriate hints\n- Group related parameters (Godot: `group_uniforms`, Unity: `[Header]`, Unreal: Category)\n- Comment non-obvious calculations (especially math-heavy sections)\n- No magic numbers — use named constants or documented uniform values\n- Include authorship and purpose comment at the top of each shader file\n\n## Performance Requirements\n- Document the target platform and complexity budget for each shader\n- Use appropriate precision: `half`/`mediump` on mobile where full precision isn't needed\n- Minimize texture samples in fragment shaders\n- Avoid dynamic branching in fragment shaders — use `step()`, `smoothstep()` and\n `mix()` (Godot, GLSL) or `lerp()` (HLSL: Unity, Unreal)\n- No texture reads inside loops\n- Two-pass approach for blur effects (horizontal then vertical)\n\n## Cross-Platform\n- Test shaders on minimum spec target hardware\n- Provide fallback/simplified versions for lower quality tiers\n- Document which render pipeline the shader targets (Forward/Deferred, URP/HDRP, Forward+/Mobile/Compatibility)\n- Do not mix shaders from different render pipelines in the same directory\n\n## Variant Management\n- Minimize shader variants — each variant is a separate compiled shader\n- Document all keywords/variants and their purpose\n- Use feature stripping where possible to reduce build size\n- Log and monitor total variant count per shader\n",".claude/rules/skill-authoring.md":"---\npaths:\n - \".claude/skills/**\"\n - \".claude/agents/**\"\n---\n\n# Skill and Gate Authoring\n\n**A check that cannot report that it did not run is not a check.**\n\nThe same shape recurs across unrelated subsystems, so treat it as the default\nrisk in any check you write, not as an unusual mistake.\n\nThe failure is always the same trade: a step that could not run produces output\nindistinguishable from a step that ran and found nothing. Nobody reading the\noutput can tell which happened, and the permissive reading is the one that gets\nbelieved, because it is the one that lets work proceed.\n\n## The five obligations\n\n### 1. Every gating verdict needs a \"could not assess\" value\n\nIf a skill emits a verdict something else depends on, its vocabulary must include\none — `NOT ASSESSED`, or the local equivalent — and the report must say *which*\nof the reasons applied. A vocabulary of three confident verdicts forces every\nunknown into a claim.\n\n**Rank it deliberately.** It must outrank the pass value: a run that could not\nassess part of its scope has not established that the scope is good. It must\n**not** outrank the failure values: a known problem is more actionable than an\nunknown, and demoting a real failure behind an access problem buries it.\n\n**`NOT ASSESSED` is not a gentler failure verdict.** \"I looked and found nothing\"\nand \"I could not look\" have different fixes — one needs work done, the other\nneeds access granted or an input classified. Collapsing them sends the reader to\nthe wrong fix.\n\n### 2. An absent value may not default to the permissive one\n\nEspecially when **nothing in the framework writes that key**. Before defaulting,\ncheck who sets it: a key with a reader and no writer takes its default branch on\nevery project that ever runs, so that branch is not an edge case — it is the\nbehaviour.\n\nOver-running a check costs minutes. Under-running one ships the category unrun.\n\n### 3. A skipped step announces itself\n\nIn the output, not only in the source. If a phase, category, or agent did not run\n— wrong engine, missing config, unavailable input, a `team.size` that collapses\nthe pipeline — the artifact must say so by name. A silent skip and a successful\none are the same artifact.\n\nA rule enforced in the body and never surfaced in the output is, to the reader,\nidentical to no rule at all.\n\n### 4. Never assert what you cannot source — and wire the gap to the verdict\n\nWhere this repo pins external facts (`docs/engine-reference/**`), do not fill a\ngap from training data. Write the gap down instead: `NOT SOURCEABLE — is\nnot covered by `.\n\n**Flagging alone is not enough.** A named gap that does not reach the verdict is\njust a comment. Wire it: a category with no sourced inputs must force obligation\n1's value, so the gap makes the pass unreachable rather than sitting beside it.\n\nA confidently wrong pattern list is worse than an absent one — it produces a scan\nthat looks thorough, finds nothing, and reads as a pass.\n\n### 5. Gates derive their covered set; they do not enumerate it\n\nAn allowlist pins what was known when it was written and is silent about\neverything added since. Derive the set from what the repo actually contains, so a\nnew skill or agent cannot ship outside coverage by simply not being on a list.\n\n**If the category is not mechanically crisp, say so in the gate and keep the\nlist.** A gate that fires on forty files does not get fixed, it gets muted — and\na muted gate is worse than a narrow one, because it reads as coverage. When you\nkeep a list, record *why* derivation failed and state the obligation to extend it.\n\nTwo further gate rules:\n\n- **Assert something that cannot be true by accident.** A check for the word\n \"unity\" is satisfied by a file path, and case-insensitively by \"community\".\n Assert a distinctive token instead.\n- **A gate you have not watched fail is not a gate.** Break the thing it guards,\n confirm it fails, restore. One mutation per tool invocation — a batch that\n times out leaves the repo holding a broken file, and `trap … EXIT` does not\n survive `SIGTERM`.\n\n## The test to apply\n\nBefore shipping a skill or gate, ask: **if this step silently did not run, what\nwould the output look like?**\n\nIf the answer is \"the same\", it is not finished.\n",".claude/rules/test-standards.md":"---\npaths:\n - \"tests/**\"\n - \"Assets/Tests/**/*.cs\"\n - \"Source/**/Tests/**/*.{h,cpp}\"\n---\n\n# Test Standards\n\n- Test naming follows the engine's language — every name says the scenario and\n the expected result:\n - **Godot (gdUnit4):** file `[system]_[feature]_test.gd`, function\n `test_[scenario]_[expected]`\n - **Unity (NUnit):** class `[System]Tests` in a file of the same name, method\n `[Scenario]_[Expected]` in PascalCase\n - **Unreal (Automation):** class `F[System][Scenario]Test` — one per test:\n each `IMPLEMENT_SIMPLE_AUTOMATION_TEST` defines its class, so a second test\n reusing a name fails to link — test name\n `.[System].[Scenario]` — the project's test command,\n `Automation RunTests .`, runs every test whose name contains\n `.` (a substring match, not a prefix). `.` is the root\n that filter in `commands.test` uses: the project name, or the distinct root\n `/setup-engine` chose when the project's name is also an engine area\n (`Audio`, `Core`, `Input`, …) — name tests under whichever it is\n- Every test must have a clear arrange/act/assert structure\n- Unit tests must not depend on external state (filesystem, network, database)\n- Integration tests must clean up after themselves\n- Performance tests must specify acceptable thresholds and fail if exceeded\n- Test data must be defined in the test or in dedicated fixtures, never shared mutable state\n- Mock external dependencies — tests should be fast and deterministic\n- Every bug fix must have a regression test that would have caught the original bug —\n and **you must watch it fail before you trust it.** Run the new test against the\n unfixed code, confirm it fails, then apply the fix and confirm it passes. A\n regression test that has only ever been seen passing is not known to test anything.\n\n > This is `.claude/rules/skill-authoring.md`'s \"a gate you have not watched fail\n > is not a gate\", applied to tests. It is written out here because stating the\n > *goal* is not enough. A regression test for an iteration-order defect can use\n > a fixture where no cell takes part in two transfers per tick — it then passes\n > against the very bug it was written for, and looks authoritative doing it. The\n > fixture, not the assertion, is what makes it useless, and only running it\n > against the unfixed code exposes that.\n\n## Examples\n\n**Correct** (proper naming + Arrange/Act/Assert) — Godot, gdUnit4:\n\n```gdscript\nextends GdUnitTestSuite\n\nfunc test_take_damage_reduces_health() -> void:\n # Arrange — auto_free: a Node left alive is an orphan (gdUnit4 exit 101)\n var health: HealthComponent = auto_free(HealthComponent.new())\n health.max_health = 100\n health.current_health = 100\n\n # Act\n health.take_damage(25)\n\n # Assert\n assert_int(health.current_health).is_equal(75)\n```\n\nUnity, NUnit (`Assets/Tests/EditMode/HealthTests.cs`):\n\n```csharp\nusing NUnit.Framework;\n\npublic class HealthTests\n{\n [Test]\n public void TakeDamage_ReducesHealth()\n {\n // Arrange\n var health = new Health(maxHealth: 100);\n\n // Act\n health.TakeDamage(25);\n\n // Assert\n Assert.AreEqual(75, health.Current);\n }\n}\n```\n\nUnreal, Automation (`Source//Private/Tests/HealthTest.cpp`):\n\n```cpp\n#include \"Misc/AutomationTest.h\"\n\n#if WITH_DEV_AUTOMATION_TESTS\n\nIMPLEMENT_SIMPLE_AUTOMATION_TEST(FHealthTakeDamageTest, \".Health.TakeDamageReducesHealth\",\n EAutomationTestFlags::EditorContext | EAutomationTestFlags::ProductFilter)\n\nbool FHealthTakeDamageTest::RunTest(const FString& Parameters)\n{\n // Arrange\n FHealthPool Health(100);\n\n // Act\n Health.TakeDamage(25);\n\n // Assert\n TestEqual(TEXT(\"health after 25 damage\"), Health.GetCurrent(), 75);\n return true;\n}\n\n#endif\n```\n\n**Incorrect**:\n\n```gdscript\nfunc test1() -> void: # VIOLATION: no descriptive name\n var h := HealthComponent.new()\n h.take_damage(25) # VIOLATION: no arrange step, no clear assert\n assert_bool(h.current_health < 100).is_true() # VIOLATION: imprecise assertion\n```\n",".claude/rules/ui-code.md":"---\npaths:\n - \"src/ui/**\"\n - \"Assets/**/{UI,Ui,ui}/**/*.cs\"\n - \"Source/**/{UI,Ui,ui}/**/*.{h,cpp}\"\n---\n\n# UI Code Rules\n\n- UI must NEVER own or directly modify game state — display only, use commands/events to request changes\n- All UI text must go through the localization system — no hardcoded user-facing strings\n- Support both keyboard/mouse AND gamepad input for all interactive elements\n- All animations must be skippable and respect user motion/accessibility preferences\n- UI sounds trigger through the audio event system, not directly\n- UI must never block the game thread\n- Scalable text and colorblind modes are mandatory, not optional\n- Test all screens at minimum and maximum supported resolutions\n",".claude/skills/adopt/SKILL.md":"---\nname: adopt\ndescription: \"Brownfield audit — do existing artifacts actually work? Numbered migration plan. Unlike /project-stage-detect, checks compliance not existence.\"\nargument-hint: \"[focus: full | gdds | adrs | stories | infra]\"\nuser-invocable: true\nallowed-tools: Read, Glob, Grep, Write, AskUserQuestion, Bash(bash \"*/.claude/skills/adopt/../../hooks/yaml-helper.sh\" resolve_config *), Bash(bash .claude/scripts/gdd-structure-check.sh *), Bash(bash .claude/scripts/migrate-v1-config.sh --dry-run*)\nmodel: sonnet\n---\n\n!`bash \"${CLAUDE_SKILL_DIR}/../../hooks/yaml-helper.sh\" resolve_config --keys review_mode,automation,automation_always_ask,workflow`\n\nResolved above — use as-is. `/adopt` also inspects `project.yaml` and the legacy\nconfig files directly when reporting and writing migration state; that raw\ninspection is deliberate and separate from the resolved values above.\n\n# Adopt — Brownfield Template Adoption\n\nThis skill audits an existing project's artifacts for **format compliance** with\nthe template's skill pipeline, then produces a prioritised migration plan.\n\n**This is not `/project-stage-detect`.**\n`/project-stage-detect` answers: *what exists?*\n`/adopt` answers: *will what exists actually work with the template's skills?*\n\nA project can have GDDs, ADRs, and stories — and every format-sensitive skill\nwill still fail silently or produce wrong results if those artifacts are in the\nwrong internal format.\n\n**Output:** `docs/adoption-plan-[date].md` — a persistent, checkable migration plan.\n\n**Argument modes:**\n\n**Audit mode:** `$ARGUMENTS` (blank = `full`)\n\n- **No argument / `full`**: Complete audit — all artifact types\n- **`gdds`**: GDD format compliance only\n- **`adrs`**: ADR format compliance only\n- **`stories`**: Story format compliance only\n- **`infra`**: Infrastructure artifact gaps only (registry, manifest, sprint-status, stage.txt)\n\n---\n\n**Automation mode**: Resolve `modes.automation` (`project.local.yaml` →\n`project.yaml` → default `collaborative`). Every `AskUserQuestion` call follows `.claude/docs/automation-modes.md`\n(collaborative asks always · guided major-only · autonomous logs and proceeds;\n`automation_always_ask` categories always prompt).\n\n**`workflow`** (per `.claude/docs/workflow-modes.md`). It scopes the Phase 2 audit and\nPhase 3 severity: `full` audits all doc types at full structure; `standard` audits\nonly the required docs/sections (optional sections are informational, not gaps);\n`minimal` is a `design/game-brief.md` format check — GDDs/ADRs/UX are not expected. See Phase 2.\n\n## Phase 1: Detect Project State\n\n**Read `references/1-detect.md` now and follow it** — this phase's steps are in that file, not here. Read it again if the conversation was compacted or resumed during this phase.\n\n## Phase 2: Format Audit\n\n**Read `references/2-format-audit.md` now and follow it** — this phase's steps are in that file, not here. Read it again if the conversation was compacted or resumed during this phase.\n\n## Phase 3: Classify and Prioritise Gaps\n\n**Read `references/3-classify.md` now and follow it** — this phase's steps are in that file, not here. Read it again if the conversation was compacted or resumed during this phase.\n\n## Phase 4: Build the Migration Plan\n\n**Read `references/4-migration-plan.md` now and follow it** — this phase's steps are in that file, not here. Read it again if the conversation was compacted or resumed during this phase.\n\n## Phase 5: Present Summary and Ask to Write\n\n**Read `references/5-summary.md` now and follow it** — this phase's steps are in that file, not here. Read it again if the conversation was compacted or resumed during this phase.\n\n## Phase 6: Write the Adoption Plan\n\n**Read `references/6-write.md` now and follow it** — this phase's steps are in that file, not here. Read it again if the conversation was compacted or resumed during this phase.\n\n## Phase 7: Offer First Action\n\n**Read `references/7-first-action.md` now and follow it** — this phase's steps are in that file, not here. Read it again if the conversation was compacted or resumed during this phase.\n\n## Collaborative Protocol\n\n**Applies in `collaborative` mode (the default).** For `guided` and\n`autonomous` modes, see `.claude/docs/automation-modes.md` — the rules below\ndescribe what collaborative mode requires, not universal behavior.\n\n1. **Read silently** — complete the full audit before presenting anything\n2. **Show the summary first** — let the user see scope before asking to write\n3. **Ask before writing** — always confirm before creating the adoption plan file\n4. **Offer, don't force** — the plan is advisory; the user decides what to fix and when\n5. **One action at a time** — after handing off the plan, offer one specific next step,\n not a list of six things to do simultaneously\n6. **Never regenerate existing artifacts** — only fill gaps in what exists;\n do not rewrite GDDs, ADRs, or stories that already have content\n",".claude/skills/adopt/references/1-detect.md":"# /adopt — Phase 1: Detect Project State\n\n> Part of `/adopt`. `SKILL.md` names when to read this file; the settings it\n> resolved and the rules under its later headings still apply here.\n\n## Phase 1: Detect Project State\n\nEmit one line before reading: `\"Scanning project artifacts...\"` — this confirms the\nskill is running during the silent read phase.\n\nThen read silently before presenting anything else.\n\n### Existence check\n- `project.stage` in `project.yaml` (fallback `production/stage.txt`) — if either is present, use that value (authoritative phase)\n- `design/gdd/game-concept.md` (or, at the minimal tier, `design/game-brief.md`) — concept exists?\n- `design/gdd/systems-index.md` — systems index exists?\n- Count GDD files: `design/gdd/*.md` (excluding game-concept.md and systems-index.md)\n- Count ADR files: `docs/architecture/adr-*.md`\n- Count story files: `production/epics/**/*.md` (excluding EPIC.md)\n- `project.yaml` (`engine.name`) / `.claude/docs/technical-preferences.md` — engine configured?\n- `docs/engine-reference/` — engine reference docs present?\n- Glob `docs/adoption-plan-*.md` — note the filename of the most recent prior plan if any exist\n\n### Infer phase (if no project.stage / stage.txt)\nUse the same heuristic as `/project-stage-detect`:\n- 10+ source files in the code root → Production\n- Stories in `production/epics/` → Pre-Production\n- ADRs exist → Technical Setup\n- systems-index.md exists → Systems Design\n- game-concept.md (or `design/game-brief.md`) exists → Concept\n- Nothing → Fresh (not a brownfield project — suggest `/start`)\n\nIf the project appears fresh (no artifacts at all), use `AskUserQuestion`:\n- \"This looks like a fresh project — no existing artifacts found. `/adopt` is for\n projects with work to migrate. What would you like to do?\"\n - \"Run `/start` — begin guided first-time onboarding\"\n - \"My artifacts are in a non-standard location — help me find them\"\n - \"Cancel\"\n\n`/start` and Cancel end this skill: say which, and stop.\n\n**If they pick \"help me find them\"**, search before asking anything else:\n\n1. Search the folder they named, if they named one; otherwise the whole\n project, skipping `.claude/`, `.git/`, `docs/engine-reference/`,\n `studio-tests/`, `node_modules/` and the engine's build and\n cache folders.\n2. Glob `**/*.md` there, then Grep the matches for the headings each artifact\n carries: a GDD has `## Overview` with `## Detailed Rules` or\n `## Detailed Design`; an ADR `## Status` with `## Decision`; a story\n `## Acceptance Criteria` with a `Status` line; a concept doc\n `## Elevator Pitch` or `## Game Pillars`; a brief `## Core loop` with\n `## MVP`.\n3. Show what was found, grouped by type, each with the place every skill reads\n it from: GDD → `design/gdd/[name].md`; ADR →\n `docs/architecture/adr-NNNN-[name].md`; story →\n `production/epics/[epic]/story-NNN-[name].md`; concept →\n `design/gdd/game-concept.md`; brief → `design/game-brief.md`. If nothing\n matched, say so, name the folders and headings searched, and offer `/start`.\n4. Ask before moving anything — a move takes the file away from its old path,\n so it is a `file_deletions` decision: \"May I move these [N] files to the\n standard folders?\" — `[A] Move them all` / `[B] Let me pick which` /\n `[C] Don't move them — I'll do it myself`. Move with `git mv` in a git\n repository (the file's history follows it), plain `mv` otherwise. Never\n overwrite a file already at the target: name the clash and skip that file.\n Files are moved, never edited.\n5. After the moves, run Phase 1 again from the top, so the audit reads the files\n where every other skill will. With [C], print the moves as a list and stop.\n\nReport: \"Detected phase: [phase]. Found: [N] GDDs, [M] ADRs, [P] stories.\"\n\n---\n",".claude/skills/adopt/references/2-format-audit.md":"# /adopt — Phase 2: Format Audit\n\n> Part of `/adopt`. `SKILL.md` names when to read this file; the settings it\n> resolved and the rules under its later headings still apply here.\n\n## Phase 2: Format Audit\n\n**In this file:**\n\n- 2a: GDD Format Audit\n- 2b: ADR Format Audit\n- 2c: systems-index.md Format Audit\n- 2d: Story Format Audit\n- 2e: Infrastructure Audit\n- 2f: Project Config Audit\n- 2g: v1.0 Migration Check\n\nFor each artifact type in scope (based on argument mode **and the resolved\nworkflow tier**), check not just that the file exists but that it contains the\ninternal structure the template requires. At `minimal`, scope the audit to\n`design/game-brief.md` — do not audit for GDDs, ADRs, or UX specs (they are not expected).\nSteps 2e (the Engine reference row only), 2f (project config) and 2g (v1.0\nmigration check) run at every tier.\n\n### 2a: GDD Format Audit\n\n**Gather section presence deterministically — do not read the GDDs to count\nheadings.** For each GDD discovered in Phase 1, pass its path explicitly to the\nstructure-check script:\n\n```\nBash: bash .claude/scripts/gdd-structure-check.sh [path-to-gdd]\n```\n\n**Pass paths one at a time; do not invoke it bare.** The no-argument form sweeps\n`design/gdd/` only, and a brownfield project's GDDs are not guaranteed to live\nthere — pass whatever paths Phase 1 found. The script prints a `PRESENT:` list\nand, when applicable, an `ABSENT:` list per file. It reports **presence only**\nand makes no REQUIRED/ADVISORY judgment (that is the tier logic below), and it\nalready accepts `## Detailed Design` as satisfying the `Detailed Rules`\nrequirement, so do not flag that alias as missing.\n\nIf the script prints `Not found:` for a path or errors, that is a **discovery\nfailure, not a format gap** — report it as \"could not audit [path]\" and do not\ncount it as a missing-sections finding.\n\n**Then apply the workflow tier** resolved above to each file's PRESENT/ABSENT\nlists. Which sections are **required** (a miss = gap) vs **advisory** (a miss =\ninformational):\n- **`full`** — all 8 sections are required.\n- **`standard`** — the 5 required (Overview, Detailed Rules, Edge Cases,\n Dependencies, Acceptance Criteria) + Formulas for any system that defines\n numeric rules (rates, curves, thresholds, costs — the system's `Category` is a\n hint, not the test); Player Fantasy and Tuning Knobs are advisory.\n- **`minimal`** — GDDs are not expected; audit `design/game-brief.md` instead,\n against `.claude/docs/templates/game-brief.md`: each of the six required fields\n present and not a placeholder; the three one-liners advisory. Any GDD that\n does exist is checked at the `standard` bar, advisorily.\n\nThe script's 8 canonical labels are: Overview, Player Fantasy, Detailed Rules,\nFormulas, Edge Cases, Dependencies, Tuning Knobs, Acceptance Criteria.\n\nA section reported PRESENT can still be an empty heading. For each GDD, also\nrecord with a targeted grep (not a full read):\n- Placeholder-only sections — the script's `PLACEHOLDER:` line names the\n present sections that hold only `[To be designed]` or nothing; a\n single-line stub body is the same in effect, so spot-check short sections.\n- The `**Status**:` header field — `Grep pattern=\"^>?[[:space:]]*\\*\\*Status\\*\\*:\"`.\n Valid values: `Draft`, `In Design`, `Designed`, `In Review`, `Approved`,\n `Implemented`, `Needs Revision`.\n\n> **The `>?` is load-bearing, and so are `Draft`/`Implemented`.** Both emitters\n> write this field inside a blockquote — `.claude/docs/templates/game-design-document.md`\n> and `/design-system` produce `> **Status**: …` — so an anchor of\n> `^\\*\\*Status\\*\\*:` matches nothing and reports *every* template-compliant GDD\n> as missing its Status. The template's own value list offers `Draft` and\n> `Implemented`, so both must count as valid.\n\n### 2b: ADR Format Audit\n\nFor each ADR file found, check for these critical sections:\n\n| Section | Impact if missing |\n|---|---|\n| `## Status` | **BLOCKING** — `/story-readiness` ADR status check silently passes everything |\n| `## ADR Dependencies` | HIGH — dependency ordering in `/architecture-review` breaks |\n| `## Engine Compatibility` | HIGH — post-cutoff API risk is unknown |\n| `## GDD Requirements Addressed` | MEDIUM — traceability matrix loses coverage |\n| `## Performance Implications` | LOW — not pipeline-critical |\n\nFor each ADR, record: which sections present, which missing, current Status value\nif the Status section exists.\n\n### 2c: systems-index.md Format Audit\n\nIf `design/gdd/systems-index.md` exists:\n\n1. **Parenthetical status values** — Grep for any Status cell containing\n parentheses: `\"Needs Revision (\"`, `\"In Progress (\"`, etc.\n These break exact-string matching in `/gate-check`, `/create-stories`,\n and `/architecture-review`. **BLOCKING.**\n\n2. **Valid status values** — check that Status column values are only from:\n `Not Started`, `In Progress`, `In Review`, `Designed`, `Approved`, `Needs Revision`\n Flag any unrecognised values.\n\n3. **Column structure** — check that the table has at minimum: System name,\n Layer, Priority, Status columns. Missing columns degrade skill functionality.\n\n### 2d: Story Format Audit\n\nFor each story file found:\n\n- **`Manifest Version:` field** — present in story header? (LOW — auto-passes if absent)\n- **TR-ID reference** — does story contain `TR-[a-z]+-[0-9]+` pattern? (MEDIUM — no staleness tracking)\n- **ADR reference** — does story reference at least one ADR? (check for `ADR-` pattern)\n- **Status field** — present and readable?\n- **Acceptance criteria** — does the story have a checkbox list (`- [ ]`)?\n\n### 2e: Infrastructure Audit\n\n| Artifact | Path | Impact if missing |\n|---|---|---|\n| TR registry | `docs/architecture/tr-registry.yaml` | HIGH — no stable requirement IDs |\n| Control manifest | `docs/architecture/control-manifest.md` | HIGH — no layer rules for stories |\n| Manifest version stamp | In manifest header: `Manifest Version:` | MEDIUM — staleness checks blind |\n| Sprint status | `production/sprint-status.yaml` | MEDIUM — `/sprint-status` falls back to markdown |\n| Stage file | `project.stage` in `project.yaml` (fallback `production/stage.txt`) | MEDIUM — phase auto-detect unreliable |\n| Engine reference | `docs/engine-reference/[engine]/VERSION.md` | HIGH — ADR engine checks blind |\n| Architecture traceability | `docs/architecture/requirements-traceability.md` | MEDIUM — no persistent matrix |\n\nAt `workflow: minimal` only the Engine reference row applies. The TR registry,\ncontrol manifest and its version stamp, sprint status, stage file and\ntraceability matrix are not on the minimal path, so their absence is not a gap.\n\n### 2f: Project Config Audit\n\nRead `project.yaml` (the primary config store) and `.claude/docs/technical-preferences.md` (legacy mirror). A setting counts as configured if EITHER source has a real value (in technical-preferences.md, `[TO BE CONFIGURED]` means unconfigured):\n- `engine.name`/`version`/`language`/`rendering`/`physics` (else the Engine/Language/Rendering/Physics fields) → HIGH if unconfigured in both (ADR skills fail)\n- `naming.*` (else Naming conventions) → MEDIUM\n- `performance.*` (else Performance budgets) → MEDIUM\n- Forbidden Patterns, Allowed Libraries (technical-preferences.md only — not migrated to project.yaml) → LOW (starts empty by design)\n\n### 2g: v1.0 Migration Check\n\nA project is a **v1.0 project needing migration** when `project.yaml` does NOT\nexist at the repo root AND at least one legacy file does: `production/stage.txt`,\n`production/review-mode.txt`, or a `.claude/docs/technical-preferences.md` with\nreal values.\n\n\"Real values\" means one of the keys the converter actually migrates — Engine,\nLanguage, Rendering, Physics, the naming, platform and performance fields,\nFramework, or the specialists. Not merely \"some bullet is filled in\": the\nshipped template ships one prose default (`- **Required Tests**: …`) that is\nnever migrated, and counting it would make every fresh clone read as a v1.0\nproject.\n\nDo not hand-migrate. Run the converter, which is deterministic and covered by\nthe framework's own test suite:\n\n```bash\nbash .claude/scripts/migrate-v1-config.sh --dry-run\n```\n\nThe dry run writes nothing; record what it lists for the report. Do not run the\nconverter during the audit — Phase 2 reads silently. The migration is\nclassified BLOCKING in Phase 3, heads the plan, and **Phase 7 offers it as the\nfirst action**: report what the dry run listed, then ask \"May I run the\nconverter? It writes `project.yaml` and `production/migration-report.md`.\" If\nthe user approves, run it without `--dry-run`. It\nwrites `project.yaml` plus `production/migration-report.md` and **deletes\nnothing** — the whole operation stays reversible with `git checkout`.\n\nThen tell the user to read `production/migration-report.md` before running:\n\n```bash\nbash .claude/scripts/migrate-v1-config.sh --finalize\n```\n\n`--finalize` deletes a legacy file only after proving its value is present in\n`project.yaml`; on mismatch it deletes nothing and exits 4. It never deletes\n`technical-preferences.md`, which still holds Forbidden Patterns and Allowed\nLibraries.\n\n**If the script refuses with exit 3**, do not work around it. Exit 3 means one\nof two things, and the message says which:\n\n- **the values DISAGREE** — two sources of truth and no way to know which the\n user edited last. Surface it and let them decide.\n- **a `production/migration-report.md` is already present** — a migration ran\n here, so these are post-migration leftovers and `--finalize` is the next step,\n not a second `migrate`.\n\nBoth files merely *existing* is not exit 3 and must not be reported as a\nconflict: `/start` writes `production/stage.txt` on every new v1.1 project as a\nmirror, so agreement is the normal state. The script says\n`the legacy files mirror it (values agree)` and exits 0 for that.\n\nClassify as **BLOCKING** in Phase 3: until migration runs, every skill reads\nconfig through the legacy fallback chain, and v1.1 settings are unavailable.\n\n---\n",".claude/skills/adopt/references/3-classify.md":"# /adopt — Phase 3: Classify and Prioritise Gaps\n\n> Part of `/adopt`. `SKILL.md` names when to read this file; the settings it\n> resolved and the rules under its later headings still apply here.\n\n## Phase 3: Classify and Prioritise Gaps\n\nOrganise every gap found across all audits into four severity tiers:\n\n**BLOCKING** — Will cause template skills to silently produce wrong results *right now*.\nExamples: ADR missing Status field, systems-index parenthetical status values,\nengine not configured when ADRs exist.\n\n**HIGH** — Will cause stories to be generated with missing safety checks, or\ninfrastructure bootstrapping will fail.\nExamples: ADRs missing Engine Compatibility, GDDs missing Acceptance Criteria\n(stories can't be generated from them), tr-registry.yaml missing.\n\n**MEDIUM** — Degrades quality and pipeline tracking but does not break functionality.\nExamples: GDDs missing Tuning Knobs or Formulas sections, stories missing TR-IDs,\nsprint-status.yaml missing.\n\n**LOW** — Retroactive improvements that are nice-to-have but not urgent.\nExamples: Stories missing Manifest Version stamps, GDDs missing Open Questions section.\n\nCount totals per tier. If zero BLOCKING and zero HIGH gaps: report that the project\nis template-compatible and only advisory improvements remain.\n\n---\n",".claude/skills/adopt/references/4-migration-plan.md":"# /adopt — Phase 4: Build the Migration Plan\n\n> Part of `/adopt`. `SKILL.md` names when to read this file; the settings it\n> resolved and the rules under its later headings still apply here.\n\n## Phase 4: Build the Migration Plan\n\nCompose a numbered, ordered action plan. Ordering rules:\n1. BLOCKING gaps first (must fix before any pipeline skill runs reliably)\n2. HIGH gaps next, infrastructure before GDD/ADR content (bootstrapping needs correct formats)\n3. MEDIUM gaps ordered: GDD gaps before ADR gaps before story gaps (stories depend on GDDs and ADRs)\n4. LOW gaps last\n\nFor each gap, produce a plan entry with:\n- A clear problem statement (one sentence, no jargon)\n- The exact command to fix it, if a skill handles it\n- Manual steps if it requires direct editing\n- A time estimate (rough: 5 min / 30 min / 1 session)\n- A checkbox `- [ ]` for tracking\n\n**Special case — systems-index parenthetical status values:**\nThis is always the first item if present. Show the exact values that need changing\nand the exact replacement text. Offer to fix this immediately before writing the plan.\n\n**Special case — ADRs missing Status field:**\nFor each affected ADR, the fix is:\n`/architecture-decision retrofit docs/architecture/adr-[NNNN]-[slug].md`\nList each ADR as a separate checkable item.\n\n**Special case — GDDs missing sections:**\nFor each affected GDD, list which sections are missing and the fix:\n`/design-system retrofit design/gdd/[filename].md`\n\n**Infrastructure bootstrap ordering** — always present in this sequence:\n1. Fix ADR formats first (registry depends on reading ADR Status fields)\n2. Run `/architecture-review` → bootstraps `tr-registry.yaml`\n3. Run `/create-control-manifest` → creates manifest with version stamp\n4. Run `/sprint-plan update` → creates `sprint-status.yaml`\n5. Run `/gate-check [phase]` (the gate into the phase the project is in; at Concept there is none — Concept is the default stage, nothing to run) → writes `project.stage` in `project.yaml` (and legacy `stage.txt`) authoritatively\n\n**At `workflow: minimal` the plan prescribes none of this sequence.** None of it\nis on the minimal path: ADRs are not expected, the brief's build order is the\nplan (no `/sprint-plan`), and nothing there runs `/gate-check`. The plan's\nStep 3 says so in one line and names the path's next step instead —\n`/create-stories` when no stories exist, else `/dev-story`.\n\n**Existing stories** — note explicitly:\n> \"Existing stories continue to work with all template skills — all new format\n> checks auto-pass when the fields are absent. They won't benefit from TR-ID\n> staleness tracking or manifest version checks until they're regenerated. This\n> is intentional: do not regenerate stories that are already in progress.\"\n\n---\n",".claude/skills/adopt/references/5-summary.md":"# /adopt — Phase 5: Present Summary and Ask to Write\n\n> Part of `/adopt`. `SKILL.md` names when to read this file; the settings it\n> resolved and the rules under its later headings still apply here.\n\n## Phase 5: Present Summary and Ask to Write\n\nPresent a compact summary before writing:\n\n```\n## Adoption Audit Summary\nPhase detected: [phase]\nEngine: [configured / NOT CONFIGURED]\nGDDs audited: [N] ([X] fully compliant, [Y] with gaps)\nADRs audited: [N] ([X] fully compliant, [Y] with gaps)\nStories audited: [N]\n\nGap counts:\n BLOCKING: [N] — template skills will malfunction without these fixes\n HIGH: [N] — unsafe to run /create-stories or /story-readiness\n MEDIUM: [N] — quality degradation\n LOW: [N] — optional improvements\n\nEstimated remediation: [X blocking items × ~Y min each = roughly Z hours]\n```\n\nBefore asking to write, show a **Gap Preview**:\n- List every BLOCKING gap as a one-line bullet describing the actual problem\n (e.g. `systems-index.md: 3 rows have parenthetical status values`,\n `adr-0002.md: missing ## Status section`). No counts — show the actual items.\n- Show HIGH / MEDIUM / LOW as counts only (e.g. `HIGH: 4, MEDIUM: 2, LOW: 1`).\n\nThis gives the user enough context to judge scope before committing to writing the file.\n\nIf a prior adoption plan was detected in Phase 1, add a note:\n> \"A previous plan exists at `docs/adoption-plan-[prior-date].md`. The new plan will\n> reflect current project state — it does not diff against the prior run.\"\n\nUse `AskUserQuestion`:\n- \"Ready to write the migration plan?\"\n - \"Yes — write `docs/adoption-plan-[date].md`\"\n - \"Show me the full plan preview first (don't write yet)\"\n - \"Cancel — I'll handle migration manually\"\n\nIf the user picks \"Show me the full plan preview\", output the complete plan as a\nfenced markdown block. Then ask again with the same three options.\n\n---\n",".claude/skills/adopt/references/6-write.md":"# /adopt — Phases 6 and 6b: Write the Adoption Plan and Report Review Mode\n\n> Part of `/adopt`. `SKILL.md` names when to read this file; the settings it\n> resolved and the rules under its later headings still apply here.\n\n## Phase 6: Write the Adoption Plan\n\n**In this file:**\n\n- Phase 6: the adoption plan template, then the write\n- Phase 6b: Report Review Mode\n\nIf approved, write `docs/adoption-plan-[date].md` with this structure:\n\n```markdown\n# Adoption Plan\n\n> **Generated**: [date]\n> **Project phase**: [phase]\n> **Engine**: [name + version, or \"Not configured\"]\n> **Template version**: v1.0+\n\nWork through these steps in order. Check off each item as you complete it.\nRe-run `/adopt` anytime to check remaining gaps.\n\n---\n\n## Step 1: Fix Blocking Gaps\n\n[One sub-section per blocking gap with problem, fix command, time estimate, checkbox]\n\n---\n\n## Step 2: Fix High-Priority Gaps\n\n[One sub-section per high gap]\n\n---\n\n## Step 3: Bootstrap Infrastructure\n\n[At `workflow: minimal`, replace 3a–3d with one line: \"Not on the minimal path —\nthe brief's build order is the plan. Next: `/create-stories` (or `/dev-story`\nonce stories exist).\"]\n\n### 3a. Register existing requirements (creates tr-registry.yaml)\nRun `/architecture-review` — even if ADRs already exist, this run bootstraps\nthe TR registry from your existing GDDs and ADRs.\n**Time**: 1 session (review can be long for large codebases)\n- [ ] tr-registry.yaml created\n\n### 3b. Create control manifest\nRun `/create-control-manifest`\n**Time**: 30 min\n- [ ] docs/architecture/control-manifest.md created\n\n### 3c. Create sprint tracking file\nRun `/sprint-plan update`\n**Time**: 5 min (if sprint plan already exists as markdown)\n- [ ] production/sprint-status.yaml created\n\n### 3d. Set authoritative project stage\nRun `/gate-check [current-phase]` (the gate into the phase the project is in;\nat Concept there is none — Concept is the default stage, nothing to run)\n**Time**: 5 min\n- [ ] `project.stage` in `project.yaml` written (legacy `production/stage.txt` also updated)\n\n---\n\n## Step 4: Medium-Priority Gaps\n\n[One sub-section per medium gap]\n\n---\n\n## Step 5: Optional Improvements\n\n[One sub-section per low gap]\n\n---\n\n## What to Expect from Existing Stories\n\nExisting stories continue to work with all template skills. New format checks\n(TR-ID validation, manifest version staleness) auto-pass when the fields are\nabsent — so nothing breaks. They won't benefit from staleness tracking until\nregenerated. Do not regenerate stories that are in progress or done.\n\n---\n\n## Re-run\n\nRun `/adopt` again after completing Step 3 to verify all blocking and high gaps\nare resolved. The new run will reflect the current state of the project.\n```\n\n---\n\n## Phase 6b: Report Review Mode\n\n**Do not write a review mode.** `modes.review_mode` is one of the six knobs\n`modes.rigor` fronts: pinning it in `project.yaml` shadows the rigor expansion, and\nthe legacy `production/review-mode.txt` sits *above* that expansion in resolution,\nso either write would freeze director-review depth for good — the rule `/start`\nand `project.yaml`'s header comment both state.\n\nReport the value the bootstrap above resolved instead: \"Review mode resolves to\n`[value]` — from `modes.rigor`, unless something pins it.\" If the user wants a\ndifferent depth, point them to changing `modes.rigor`, or to pinning it on purpose\nwith `/settings --local modes.review_mode=` (a personal override in\n`project.local.yaml`).\n\n---\n",".claude/skills/adopt/references/7-first-action.md":"# /adopt — Phase 7: Offer First Action\n\n> Part of `/adopt`. `SKILL.md` names when to read this file; the settings it\n> resolved and the rules under its later headings still apply here.\n\n## Phase 7: Offer First Action\n\nAfter writing the plan, don't stop there. Pick the single highest-priority gap\nand offer to handle it immediately using `AskUserQuestion`. Choose the first\nbranch that applies:\n\n**If Phase 2g found a v1.0 project needing migration:** offer the converter run\ndescribed there — report what the dry run listed and ask \"May I run the\nconverter? It writes `project.yaml` and `production/migration-report.md`.\"\nEvery other fix reads config through it, so it comes first.\n\n**If there are parenthetical status values in systems-index.md:**\nUse `AskUserQuestion`:\n- \"The most urgent fix is `systems-index.md` — [N] rows have parenthetical status\n values (e.g. `Needs Revision (see notes)`) that break /gate-check,\n /create-stories, and /architecture-review right now. I can fix these in-place.\"\n - \"Fix it now — edit systems-index.md\"\n - \"I'll fix it myself\"\n - \"Done — leave me with the plan\"\n\n**If ADRs are missing `## Status` (and no parenthetical issue):**\nUse `AskUserQuestion`:\n- \"The most urgent fix is adding `## Status` to [N] ADR(s): [list filenames].\n Without it, /story-readiness silently passes all ADR checks. Start with\n [first affected filename]?\"\n - \"Yes — retrofit [first affected filename] now\"\n - \"Retrofit all [N] ADRs one by one\"\n - \"I'll handle ADRs myself\"\n\n**If GDDs are missing Acceptance Criteria (and no blocking issues above):**\nUse `AskUserQuestion`:\n- \"The most urgent gap is missing Acceptance Criteria in [N] GDD(s):\n [list filenames]. Without them, /create-stories can't generate stories.\n Start with [highest-priority GDD filename]?\"\n - \"Yes — add Acceptance Criteria to [GDD filename] now\"\n - \"Do all [N] GDDs one by one\"\n - \"I'll handle GDDs myself\"\n\n**Otherwise, if any BLOCKING or HIGH gap remains** (one no branch above names —\ne.g. a missing TR registry):\nUse `AskUserQuestion`:\n- \"The most urgent remaining gap is [first BLOCKING or HIGH item in the plan] —\n [one line on what it breaks]. Start on it now?\"\n - \"Yes — start on [item]\"\n - \"Show me that plan item first\"\n - \"Done — leave me with the plan\"\n\n**If no BLOCKING or HIGH gaps exist:**\nUse `AskUserQuestion`:\n- \"No blocking gaps — this project is template-compatible. What next?\"\n - \"Walk me through the medium-priority improvements\"\n - \"Run /project-stage-detect for a broader health check\"\n - \"Done — I'll work through the plan at my own pace\"\n\n> **Adoption plan saved to `docs/adoption-plan-[date].md`.** Re-run `/adopt` at any time to re-check remaining gaps as you complete them.\n\n---\n",".claude/skills/architecture-decision/CONTRACT.md":"# /architecture-decision — Handoff Contract\n\n## Role in Pipeline\nAuthors a new Architecture Decision Record (ADR) by guiding a collaborative design session, cross-referencing the engine reference library and existing architectural stances, and writing a fully-structured ADR file to `docs/architecture/` as `Proposed`. Its `accept` mode is the only route to `Accepted`, and acceptance is what unblocks the stories and epics that depend on the decision.\n\nTwo checks inside the run emit `NOT ASSESSED` rather than passing silently, and\na reader of the resulting ADR should expect them: **engine validation** when no\nengine is configured (`engine.name` unset and no legacy fallback), and **GDD\nsync** when the referenced design docs cannot be read. A skipped check that says\nnothing is indistinguishable from a check that passed.\n\n## Inputs Required\n\n### Files That Must Exist\n| File | Required Fields / Sections | Read-Only? |\n|------|---------------------------|-----------|\n| `docs/engine-reference/[engine]/VERSION.md` | Engine name + version, LLM knowledge cutoff date, post-cutoff risk levels per domain | Yes |\n| `docs/engine-reference/[engine]/modules/[domain].md` | Domain-specific API reference (read if exists for the decision's domain) | Yes |\n| `docs/engine-reference/[engine]/breaking-changes.md` | Post-cutoff breaking changes in the relevant domain | Yes |\n| `docs/engine-reference/[engine]/deprecated-apis.md` | APIs that must not be referenced in the new ADR | Yes |\n| `docs/registry/architecture.yaml` | All existing architectural stances (state ownership, interface contracts, forbidden patterns, performance budgets) — checked for conflicts before the design begins | Yes |\n| `docs/architecture/` (existing ADRs) | Scanned to determine the next sequential ADR number | Yes |\n| `design/gdd/[system].md` (GDDs relevant to the decision) | Specific rules, formulas, performance constraints, or integration points that motivate the decision | Yes |\n| `project.yaml` | `engine.name` — derives the primary specialist (`-specialist`) to spawn for validation (Step 5.5) | Yes |\n| `.claude/docs/technical-preferences.md` | `Engine Specialists` section — legacy fallback, used only when `engine.name` is absent or empty in `project.yaml` | Yes — required only when `engine.name` is absent |\n\n### Preconditions\n- An engine must be configured (`docs/engine-reference/[engine]/VERSION.md` must exist) — if not, the skill prompts to run `/setup-engine` first\n- The title or subject of the decision must be provided by the user before Step 0 proceeds (if no argument is given, the skill asks)\n- If in **retrofit mode** (`retrofit [path]` argument), the target ADR file must already exist on disk\n- Any conflict with a registered architectural stance in `docs/registry/architecture.yaml` must be resolved or explicitly accepted as an exception before the ADR is drafted (Step 3a is a BLOCKING gate)\n\n## Outputs Produced\n\n### Files Written\n| File | Guaranteed Fields / Sections | Notes |\n|------|------------------------------|-------|\n| `docs/architecture/adr-NNNN-[slug].md` | `## Status`, `## Date`, `## Engine Compatibility` (table with engine, domain, knowledge risk, post-cutoff APIs, verification required), `## ADR Dependencies` (table with depends-on, enables, blocks, ordering note), `## Context` (problem statement, constraints, requirements), `## Decision` (+ architecture diagram + key interfaces), `## Alternatives Considered`, `## Consequences` (positive, negative), `## Risks`, `## GDD Requirements Addressed` (table), `## Performance Implications`, `## Migration Plan`, `## Validation Criteria`, `## Related` | created after user approves (\"May I write this ADR to docs/architecture/adr-NNNN-[slug].md?\") |\n| `docs/registry/architecture.yaml` | New stance entries (state ownership, interface contracts, performance budgets, forbidden patterns) derived from the ADR; existing entries marked `status: superseded_by` if overridden | appended after separate user approval (\"May I update docs/registry/architecture.yaml with these N new stances?\") |\n\n### Output Guarantees\n- The ADR number is the next sequential integer after the highest existing `adr-NNNN-*` filename in `docs/architecture/`\n- `## Status` is always present. Authoring writes `Proposed`; retrofit writes the status the user gives, except that an `Accepted` answer is written as `Proposed` and handed to acceptance mode. Only acceptance mode writes `Accepted`, after its dependency check and the user's confirmation\n- `## Engine Compatibility` is always populated using verified data from the engine reference docs — never from training data alone when the domain carries MEDIUM or HIGH risk\n- `## GDD Requirements Addressed` is always present (if no GDD motivated the decision, it documents which GDDs the decision will constrain or enable)\n- `## ADR Dependencies` is always present (fields set to \"None\" if no ordering constraints exist)\n- Engine specialist validation (Step 5.5) runs before the file is written if an engine specialist is configured; blocking issues found by the specialist cause the Decision section to be revised before saving\n\n## Immutability Rules\n- READS but does NOT modify: all existing ADR files in `docs/architecture/` (including in retrofit mode — existing sections are never touched), all GDD files in `design/gdd/`, `docs/engine-reference/**`, `project.yaml`, `.claude/docs/technical-preferences.md` (legacy fallback)\n- MODIFIES: `docs/architecture/adr-NNNN-[slug].md` (new file created; or missing sections appended in retrofit mode), `docs/registry/architecture.yaml` (append only; existing entries get `status: superseded_by` annotation, never deleted or rewritten)\n- In retrofit mode: appends only the missing sections — never modifies any section that is already present in the target ADR file\n\n## Hard Constraints (Never Violate)\n- Never sets `Status: Accepted` without explicit user confirmation — the default on creation is always `Status: Proposed`\n- **Acceptance route: `/architecture-decision accept ADR-NNNN`** — the only path that sets `Accepted`. It refuses when a dependency is still Proposed, and prompts for confirmation regardless of `modes.automation`. Retrofit mode's `Accepted` answer, for a decision already in force, is written as `Proposed` and handed to this route. Without this route acceptance would be enforced by ten skills, owned per the authority below, and reachable by nobody.\n- **Acceptance authority: the user, or `technical-director` on the user's explicit confirmation — no other agent, and not this skill on its own.** Recorded here because every consumer enforces the consequences of acceptance, and without this line nothing would say who can produce it. This narrows *who* may set the field; it does not relax the confirmation rule above.\n- Never assigns an ADR number that is already in use — always scan `docs/architecture/` first and use the next sequential number\n- Never proceeds past the architectural stance conflict check (Step 3a) if a conflict exists — surface the conflict and require resolution or explicit exception acknowledgment before drafting\n- Never references APIs listed in `docs/engine-reference/[engine]/deprecated-apis.md` in the Decision or Key Interfaces sections\n- Never writes the ADR file without asking: \"May I write this ADR to docs/architecture/adr-NNNN-[slug].md?\"\n- Never writes to `docs/registry/architecture.yaml` without a separate ask: \"May I update docs/registry/architecture.yaml with these N new stances?\"\n- In retrofit mode: never modifies any existing section — only appends absent sections\n\n## Downstream Skill Expects\n**Next skills:** `/create-epics`, `/create-stories`, `/dev-story`, `/architecture-review`\n\n### `/create-epics` reads ADRs expecting:\n- `## Status` field — value must be `Accepted` for epics to reference it\n- `## GDD Requirements Addressed` table — used to link epics to GDD traceability\n- `## Engine Compatibility` section — checked during the Technical Setup → Pre-Production gate\n\n### `/create-stories` reads ADRs expecting:\n- `### Implementation Guidelines` (under `## Decision`) — the concrete \"must / must never\" patterns programmer agents follow; the ADR template carries this subsection\n- `## ADR Dependencies` table — stories referencing a `Depends On` ADR that is still `Proposed` are automatically set `Status: Blocked`\n\n### `/dev-story` reads ADRs expecting:\n- `## Decision` (full text, verbatim — not summarized)\n- `### Implementation Guidelines` (under `## Decision`, verbatim)\n- `## Engine Compatibility` (post-cutoff API risks, verification required)\n- `## ADR Dependencies` (to detect if this ADR's dependencies are unresolved)\n\n### `/architecture-review` reads ADRs expecting:\n- All required sections present (it flags gaps)\n- `## Status` is set (required for coverage matrix)\n- `## Engine Compatibility` is stamped with the correct engine version\n\n## Known Fragile Points\n- If the ADR number scan misses a file (e.g., a file in a subdirectory of `docs/architecture/` or with a non-standard naming pattern), a duplicate number can be assigned — all ADR files must follow the `adr-NNNN-[slug].md` naming convention at the top level of `docs/architecture/`\n- Acceptance mode moves a story from `Blocked` to `Ready` only when the story file, under `production/epics/`, contains a Blocked Status line in any of the forms `/create-stories` writes (`> **Status**: Blocked`, `**Status:** Blocked`, `Status: Blocked`) and this ADR's id. A story blocked pending this ADR that never names its id is not found, and stays `Blocked` until it is updated by hand\n- The `## GDD Requirements Addressed` table is populated based on what the user tells the skill during the collaborative session; if the user does not know which GDDs motivated the decision, this table may be incomplete — `/create-epics` and `/gate-check` both rely on this linkage for traceability\n- Engine specialist validation (Step 5.5) is skipped only when **both** sources are unset — `engine.name` absent or empty in `project.yaml` **and** `.claude/docs/technical-preferences.md` still reading `[TO BE CONFIGURED]`. A project configured solely via `project.yaml` **does** get specialist validation. When both are unset, post-cutoff engine API risks are not caught before the ADR is written\n- `docs/registry/architecture.yaml` is append-only by design; if a stance entry becomes permanently invalid (not superseded by another ADR), it must be manually removed — there is no cleanup mechanism\n- In retrofit mode, if the existing ADR has sections present but empty (e.g., a `## Status` heading with no value), the skill treats the section as present and does not fill it — an empty Status is effectively invisible to downstream skills like `/story-readiness`\n",".claude/skills/architecture-decision/SKILL.md":"---\nname: architecture-decision\ndescription: \"Create an ADR documenting a technical decision: context, alternatives considered, consequences.\"\nargument-hint: \"[title | retrofit | accept ] [--review full|lean|solo]\"\nuser-invocable: true\nallowed-tools: Read, Glob, Grep, Write, Edit, Agent, AskUserQuestion, Bash(wc -c *), Bash(bash \"*/.claude/skills/architecture-decision/../../hooks/yaml-helper.sh\" resolve_config *), Bash(bash .claude/scripts/registry.sh *)\nmodel: sonnet\n---\n\n!`bash \"${CLAUDE_SKILL_DIR}/../../hooks/yaml-helper.sh\" resolve_config --keys review_mode,automation,workflow,docs.density,team.size`\n\nResolved above — use as-is; `--review` overrides `review_mode`. No block →\ndefaults in `.claude/docs/config-resolution.md`.\n\n# Architecture Decision\n\nWhen this skill is invoked:\n\n## 0. Parse Arguments — Detect Retrofit / Acceptance Mode\n\nSee `.claude/docs/director-gates.md` for the full check pattern. Individual gate definitions live in `.claude/docs/director-gates/[gate-id].md` — the spawned agent reads its own gate file; do not read it in the parent session.\n\nEvery `AskUserQuestion` call follows `.claude/docs/automation-modes.md`\n(collaborative asks always · guided major-only · autonomous logs and proceeds;\n`automation_always_ask` categories always prompt).\n\n**`team.size`**: which agents validate this ADR (orthogonal to review_mode/workflow).\n- **`individual`** (default): `technical-director` (TD-ADR) + the engine-specialist.\n- **`small`** and **`studio`**: the same two. This skill spawns no engine\n sub-specialist and no adversarial reviewer at any size.\n\n**`docs.density`** — it controls the *depth* of the ADR's prose sections, not\nwhich sections the skeleton emits (that is fixed). `modes.rigor` sets it\nalongside `workflow`; set `docs.density` explicitly to vary ADR verbosity alone:\n`terse` (the default, via `rigor: minimal`) = decision + alternatives as bullets, one line of rationale each;\n`balanced` = paragraph per section with light rationale (`rigor: standard`); `thorough` =\nfull prose with trade-offs and worked rationale in Decision, Alternatives, and\nConsequences. Apply it to the prose sections; the Engine Compatibility, ADR\nDependencies, and GDD Requirements tables are structural and stay whole at every\ndensity.\n\n**`workflow`** (see `.claude/docs/workflow-modes.md`):\n- `full` — all ADRs on the required ADR list must be completed.\n- `standard` — critical ADRs only (Foundation-layer systems).\n- `minimal` — not required. Can still be run voluntarily.\n\n**If the argument starts with `retrofit` followed by a file path**\n\n**Read `references/0-retrofit.md` now and follow it** — this phase's steps are in that file, not here. Read it again if the conversation was compacted or resumed during this phase.\n\n**If the argument starts with `accept` followed by an ADR id**\n\n**Read `references/0-accept.md` now and follow it** — this phase's steps are in that file, not here. Read it again if the conversation was compacted or resumed during this phase.\n\nIf NOT in retrofit or acceptance mode, proceed to Step 1 below (normal ADR authoring).\n\n**No-argument guard**: If no argument was provided (title is empty), ask before\nrunning Phase 0:\n\n> \"What technical decision are you documenting? Please provide a short title\n> (e.g., `event-system-architecture`, `physics-engine-choice`).\"\n\nUse the user's response as the title, then proceed to Step 1.\n\n---\n\n## 1. Load Engine Context (ALWAYS FIRST)\n\n**Read `references/1-engine-context.md` now and follow it** — this phase's steps are in that file, not here. Read it again if the conversation was compacted or resumed during this phase.\n\n## 2. Determine the next ADR number\n\nScan `docs/architecture/` for existing ADRs to find the next number.\n\n---\n\n## 3. Gather context\n\n**Read `references/3-gather-context.md` now and follow it** — this phase's steps are in that file, not here. Read it again if the conversation was compacted or resumed during this phase.\n\n## 4. Guide the decision collaboratively\n\n**Read `references/4-decide.md` now and follow it** — this phase's steps are in that file, not here. Read it again if the conversation was compacted or resumed during this phase.\n\n## 5. Generate the ADR\n\n**Read `references/5-generate.md` now and follow it** — this phase's steps are in that file, not here. Read it again if the conversation was compacted or resumed during this phase.\n\n## 6. Closing Next Steps\n\nAfter the ADR is written (and registry optionally updated), close with `AskUserQuestion`.\n\nBefore generating the widget:\n1. Read the `## Required ADRs` section of `docs/architecture/architecture.md` (by section) and list `docs/architecture/adr-*.md`: a required ADR with no file is still unwritten. Without `architecture.md`, look for ADRs flagged in technical-preferences.md or systems-index.md as prerequisites\n2. Check if all prerequisite ADRs are now written. If yes, include a \"Start writing GDDs\" option.\n3. List ALL remaining priority ADRs as individual options — not just the next one or two.\n\nWidget format:\n```\nADR-[NNNN] written and registry updated. What would you like to do next?\n[1] Write [next-priority-adr-name] — [brief description from prerequisites list]\n[2] Write [another-priority-adr] — [brief description] (include ALL remaining ones)\n[N] Start writing GDDs — run `/design-system [first-undesigned-system]` (only show if all prerequisite ADRs are written)\n[N+1] Stop here for this session\n```\n\nIf there are no remaining priority ADRs and no undesigned GDD systems, offer only \"Stop here\" and suggest running `/architecture-review` in a fresh session.\n\n**Always include this fixed notice in the closing output (do NOT omit it):**\n\n> To validate ADR coverage against your GDDs, open a **fresh Claude Code session**\n> and run `/architecture-review`.\n>\n> **Never run `/architecture-review` in the same session as `/architecture-decision`.**\n> The reviewing agent must be independent of the authoring context to give an unbiased\n> assessment. Running it here would invalidate the review.\n\n**Do NOT unblock stories here.** This ADR is `Proposed` — Step 5 guarantees it,\nand a story blocked *pending this decision* is still pending it. Unblocking on\nauthoring defeats the guard at the moment it becomes relevant: the pipeline\nappears to flow while running on decisions nobody has accepted.\n\nInstead, tell the user what is now waiting on acceptance:\n\n> \"ADR-NNNN is written and `Proposed`. [N] stories remain `Blocked` pending it.\n> Run `/architecture-decision accept ADR-NNNN` when the decision is settled —\n> that is what moves them to `Ready`.\"\n\nList the blocked stories by path so the cost of leaving it Proposed is visible.\n(Acceptance has consequences enforced across many skills and an authority\nrecorded in only a few, so the route between them must stay explicit.)\n",".claude/skills/architecture-decision/references/0-accept.md":"# /architecture-decision — Acceptance Mode\n\n> Part of `/architecture-decision`. `SKILL.md` names when to read this file; the settings it\n> resolved and the rules under its later headings still apply here.\n\n**If the argument starts with `accept` followed by an ADR id**\n\n(e.g., `/architecture-decision accept ADR-0005`):\n\nEnter **acceptance mode**. This is the *only* path in the framework that moves an\nADR from `Proposed` to `Accepted`. Authoring always produces `Proposed`\n(Step 5), while\n`/create-control-manifest`, `/create-epics`, `/create-stories` and `/gate-check`\nall require `Accepted` — so without this mode an ADR would enter a state it\nnever leaves.\n\n1. **Resolve the id to a file, then read it.** Glob\n `docs/architecture/adr-NNNN-*.md` for the given number. If **no** file matches,\n or **more than one** does, stop and say which — do not pick one. If the file\n has no `## Status` section, stop and say so; a missing Status is exactly what\n retrofit mode is for.\n2. **Check the current status.** If it is already `Accepted`, say so and stop.\n If it is `Deprecated` or `Superseded`, refuse: reviving a superseded decision\n is a new ADR, not a status edit.\n3. **Check its dependencies first.** Read `## ADR Dependencies`.\n\n **If that section is absent, empty, or reads `UNKNOWN`, do not read it as\n \"no dependencies\" — refuse and say which:**\n > \"ADR-0005's dependency section is [absent / UNKNOWN], so I cannot tell what\n > this decision rests on. An empty dependency list and an unexamined one look\n > identical here, and only one of them is safe to accept. Run\n > `/architecture-decision retrofit ` to establish it.\"\n\n A dependency check reading a field that defaults to empty is the vacuous-pass\n shape this gate exists to prevent — the check would examine nothing and report\n clean.\n\n If it depends on any ADR that is not itself `Accepted`, **refuse and name them**:\n > \"ADR-0005 depends on ADR-0002, which is still Proposed. Accept ADR-0002\n > first — an accepted decision resting on an unaccepted one is not a decision,\n > it is a deferral with a different label.\"\n This is the same dependency rule `/architecture-review` already flags; here it\n is enforced rather than reported.\n4. **Confirm with the user, always.** Per `CONTRACT.md`, acceptance authority is\n **the user, or `technical-director` on the user's explicit confirmation — no\n other agent, and never this skill on its own.** Use `AskUserQuestion`:\n - Prompt: \"Accept ADR-NNNN — [title]? This is what unblocks stories and epics\n that depend on it.\"\n - Options: `[A] Yes — accept it` / `[B] Not yet — leave it Proposed`\n **This prompt fires regardless of `modes.automation`, including `autonomous`.**\n Acceptance is the decision the whole architecture pipeline gates on; it is not\n a step to be inferred.\n5. **Find the stories this will unblock, BEFORE the prompt in step 4.** Grep\n every story for a Blocked Status line —\n `Grep pattern=\"Status\\**:\\**\\s*Blocked\" path=\"production/epics\" glob=\"**/story-*.md\" output_mode=\"files_with_matches\"`,\n which matches `> **Status**: Blocked` (the form `/create-stories` writes),\n `**Status:** Blocked` and `Status: Blocked` — and keep the files that name\n this ADR's id as the reason they are blocked. That pairing is what \"blocked\n pending this ADR\" means — a story blocked for an unrelated reason will not\n name it. Leave out a story that names this ADR only as the successor to point\n at (`point the story at ADR-NNNN`, the note for a `Deprecated` or\n `Superseded` ADR): it is still governed by the old ADR, and accepting the\n successor does not re-point it.\n > **Stories live only under `production/epics/`.** A flat top-level stories\n > directory does not exist and no skill creates one — never write or match a\n > path outside `production/epics/`. `/dev-story` matches entries *by file\n > path*, so a story recorded under any other path silently fails to match and\n > never gets picked up.\n\n Feed the count into step 4's prompt so it reads *\"3 stories become Ready\"*\n rather than a generic claim: **the user is being asked to authorise an effect, and should be\n shown the effect.** If none match, say \"no stories are waiting on this\" — that\n is useful information, not an empty result to omit.\n6. On confirmation, `Edit` the `## Status` line to `Accepted`. Leave an existing\n `## Date` as it is: it records when the ADR was written, and `/create-stories`\n stamps stories with it (or `## Last Verified`), so rewriting it on acceptance\n would make every story drafted against the Proposed ADR look out of date to\n `/dev-story`. **If that section is absent, add it** with today's date — retrofit\n mode already owns this shape, and acceptance must not fail on a template that\n predates the field.\n7. Then set each story found in step 5 from `Blocked` to `Ready`. Unblocking is a\n consequence of acceptance, never of authoring — see Step 6's note below.\n8. Report what moved: the ADR (and its `## Date`, if one was added), and every\n story that became Ready.\n",".claude/skills/architecture-decision/references/0-retrofit.md":"# /architecture-decision — Retrofit Mode\n\n> Part of `/architecture-decision`. `SKILL.md` names when to read this file; the settings it\n> resolved and the rules under its later headings still apply here.\n\n**If the argument starts with `retrofit` followed by a file path**\n\n(e.g., `/architecture-decision retrofit docs/architecture/adr-0001-event-system.md`):\n\nEnter **retrofit mode**:\n\n1. Read the existing ADR file completely. This step needs the whole ADR: read it\n in ranges by its headings (found with the Grep tool: pattern `^#`, content\n mode), since a whole-file Read over 40 KB is refused.\n2. Identify which template sections are present by scanning headings:\n - `## Status` — **BLOCKING if missing**: `/story-readiness` cannot check ADR acceptance\n - `## ADR Dependencies` — HIGH if missing: dependency ordering breaks\n - `## Engine Compatibility` — HIGH if missing: post-cutoff risk unknown. A\n present table with no **Layer** row is HIGH too: the ADR counts as critical\n wherever it is read, so at `standard` its advisory items become blockers\n - `## GDD Requirements Addressed` — MEDIUM if missing: traceability lost\n - `## Date` — MEDIUM if missing, and no `## Last Verified` either: `/create-stories`\n stamps stories with it and `/dev-story` compares against it, so without it a\n story can never tell whether the ADR changed\n3. Present to the user:\n ```\n ## Retrofit: [ADR title]\n File: [path]\n\n Sections already present (will not be touched):\n ✓ Status: [current value, or \"MISSING — will add\"]\n ✓ [section]\n\n Missing sections to add:\n ✗ Status — BLOCKING (stories cannot validate ADR acceptance without this)\n ✗ ADR Dependencies — HIGH\n ✗ Engine Compatibility — HIGH\n ```\n4. Ask: \"Shall I add the [N] missing sections? I will not modify any existing content.\"\n If no: write nothing, and report the missing sections by name.\n5. If yes:\n - For **Status**: ask the user — \"What is the current status of this decision?\"\n Options: \"Proposed\", \"Accepted\", \"Deprecated\", \"Superseded by ADR-XXXX\"\n An `Accepted` answer — a decision already in force — is not written as\n given: write `Proposed`, add the other missing sections, then run\n acceptance mode (below) on this ADR. Its dependency check, confirmation and\n story unblocking apply here too; it stays the only path that sets `Accepted`.\n - For **ADR Dependencies**: ask — \"Does this decision depend on any other ADR?\n Does it enable or block any other ADR or epic?\" Accept \"None\" for each field.\n - For **Engine Compatibility**: read the engine reference docs (same as Step 1 below)\n and ask the user to confirm the domain. Then generate the table with verified data,\n its Layer row included.\n - For a present Engine Compatibility table with no **Layer** row: find the\n layer as `references/5-generate.md` says under \"Always write the Layer row\",\n and add the row under **Domain**. It adds a row and changes none.\n - For **GDD Requirements Addressed**: ask — \"Which GDD systems motivated this decision?\n What specific requirement in each GDD does this ADR address?\"\n - Append each missing section to the ADR file using the Edit tool.\n - For **Date** (counted only when there is no `## Last Verified`): append\n `## Date` with today's date — even when it is the only missing section, the\n case `/dev-story` sends you here for — and say that it records the retrofit,\n not when the decision was made.\n - **Never modify any existing section.** Only append or fill absent sections.\n6. Suggest: \"Run `/architecture-review` to re-validate coverage now that this ADR\n has its Status and Dependencies fields.\"\n",".claude/skills/architecture-decision/references/1-engine-context.md":"# /architecture-decision — Step 1: Load Engine Context\n\n> Part of `/architecture-decision`. `SKILL.md` names when to read this file; the settings it\n> resolved and the rules under its later headings still apply here.\n\n## 1. Load Engine Context (ALWAYS FIRST)\n\nBefore doing anything else, establish the engine environment:\n\n1. Read `docs/engine-reference/[engine]/VERSION.md` to get:\n - Engine name and version\n - LLM knowledge cutoff date\n - Post-cutoff version risk levels (LOW / MEDIUM / HIGH)\n\n2. Identify the **domain** of this architecture decision from the title or\n user description. Common domains: Physics, Rendering, UI, Audio, Navigation,\n Animation, Networking, Core, Input, Scripting.\n\n3. Read the corresponding module reference if it exists:\n `docs/engine-reference/[engine]/modules/[domain].md`\n\n4. Read `docs/engine-reference/[engine]/breaking-changes.md` — flag any\n changes in the relevant domain that post-date the LLM's training cutoff.\n\n5. Read `docs/engine-reference/[engine]/deprecated-apis.md` — flag any APIs\n in the relevant domain that should not be used.\n\n6. **Display a knowledge gap warning** before proceeding if the domain carries\n MEDIUM or HIGH risk:\n\n ```\n ⚠️ ENGINE KNOWLEDGE GAP WARNING\n Engine: [name + version]\n Domain: [domain]\n Risk Level: HIGH — This version is post-LLM-cutoff.\n\n Key changes verified from engine-reference docs:\n - [Change 1 relevant to this domain]\n - [Change 2]\n\n This ADR will be cross-referenced against the engine reference library.\n Proceed with verified information only — do NOT rely solely on training data.\n ```\n\n If no engine has been configured yet, prompt: \"No engine is configured.\n Run `/setup-engine` first, or tell me which engine you are using.\"\n\n---\n",".claude/skills/architecture-decision/references/3-gather-context.md":"# /architecture-decision — Steps 3a and 3b: Gather Context\n\n> Part of `/architecture-decision`. `SKILL.md` names when to read this file; the settings it\n> resolved and the rules under its later headings still apply here.\n\n## 3. Gather context\n\n### 3a: Architecture Registry Check (BLOCKING gate) — do this FIRST\n\nRead `docs/registry/architecture.yaml`. Extract entries relevant to this ADR's\ndomain and decision (grep by system name, domain keyword, or state being touched).\nRun this before reading any existing ADR — the registry exists specifically so a\nnew ADR's author does not need to open prior ADRs to learn their binding facts\n(state ownership, interface contracts, forbidden patterns).\n\nPresent any relevant stances to the user **before** the collaborative design\nbegins, as locked constraints:\n\n```\n## Existing Architectural Stances (must not contradict)\n\nState Ownership:\n player_health → owned by health-system (ADR-0001)\n Interface: HealthComponent.current_health (read-only float)\n → If this ADR reads or writes player health, it must use this interface.\n\nInterface Contracts:\n damage_delivery → signal pattern (ADR-0003)\n Signal: damage_dealt(amount, target, is_crit)\n → If this ADR delivers or receives damage events, it must use this signal.\n\nForbidden Patterns:\n ✗ autoload_singleton_coupling (ADR-0001)\n ✗ direct_cross_system_state_write (ADR-0000)\n → The proposed approach must not use these patterns.\n```\n\nIf the user's proposed decision would contradict any registered stance, surface\nthe conflict immediately:\n\n> \"⚠️ Conflict: This ADR proposes [X], but ADR-[NNNN] established that [Y] is\n> the accepted pattern for this purpose. Proceeding without resolving this will\n> produce contradictory ADRs and inconsistent stories.\n> Options: (1) Align with the existing stance, (2) Supersede ADR-[NNNN] with\n> an explicit replacement, (3) Explain why this case is an exception.\"\n\nDo not proceed to Step 4 (collaborative design) until any conflict is resolved\nor explicitly accepted as an intentional exception.\n\n### 3b: Existing ADRs and Related GDDs — registry-scoped, never unbounded\n\nThe registry (3a) covers *what* prior decisions bind — not always *why*. If the\nregistry surfaced a directly relevant ADR and its reasoning matters here (not\njust its stated facts), read that specific ADR — never glob-and-read every\nADR in `docs/architecture/` on the chance one is relevant. Read it by section:\nfind the headings you need with the Grep tool (pattern `^#`, content mode)\nand Read those ranges with offset and limit.\n\n1. **Map its headings first** (cheap):\n ```\n Grep pattern=\"^## \" path=\"docs/architecture/[adr-file].md\" output_mode=\"content\" -n\n ```\n2. **Under ~40KB** (`Bash: wc -c \"docs/architecture/[adr-file].md\"`) — one full\n `Read` is fine; per-call overhead exceeds the savings from bounded reads at\n this size.\n3. **~40KB or larger** — bounded-read only `## Context`, `## Decision`, and\n `## Consequences` (the sections that carry reasoning, not just facts) via\n `Read(offset, limit)` from the heading map.\n\nRead GDDs the same way `/design-system` Step 2b does: only GDDs the registry\nor the ADR list names as directly relevant, and only their `## Dependencies`,\n`## Formulas`, and `## Edge Cases` sections\n(`Grep pattern=\"^## (Dependencies|Formulas|Edge Cases)\" ... -A 40`) — never a\nspeculative full read of `design/gdd/*.md` looking for anything that might\nrelate.\n\nSkip 3b entirely if the registry already answers everything this decision\nneeds — most ADRs will.\n\n---\n",".claude/skills/architecture-decision/references/4-decide.md":"# /architecture-decision — Step 4: Guide the Decision Collaboratively\n\n> Part of `/architecture-decision`. `SKILL.md` names when to read this file; the settings it\n> resolved and the rules under its later headings still apply here.\n\n## 4. Guide the decision collaboratively\n\nBefore asking anything, derive the skill's best guesses from the context already\ngathered (GDDs read, engine reference loaded, existing ADRs scanned). Then present\na **confirm/adjust** prompt using `AskUserQuestion` — not open-ended questions.\n\n**Derive assumptions first:**\n- **Problem**: Infer from the title + GDD context what decision needs to be made\n- **Alternatives**: Propose 2-3 concrete options from engine reference + GDD requirements\n- **Dependencies**: Scan existing ADRs for upstream dependencies. **If the scan is\n inconclusive, present `UNKNOWN — scan inconclusive, please confirm`, never\n `None`.** The two are not interchangeable: `None` asserts that nothing upstream\n constrains this decision, and a user confirming a prefilled list cannot tell an\n assertion from a guess. This field is load-bearing — `/architecture-review`\n flags unaccepted dependencies, `/dev-story` reads it, and the acceptance route\n in Phase 0 **refuses to accept an ADR whose dependencies are not themselves\n Accepted**. A dependency list that defaulted to empty makes that check pass\n while examining nothing. `UNKNOWN` must be resolved during the confirm/adjust\n prompt; it is a prompt state, never a value written to the file\n- **GDD linkage**: Extract which GDD systems the title directly relates to\n- **Status**: Always `Proposed` for new ADRs — never ask the user what the status is\n\n**Scope of assumptions tab**: Assumptions cover only: problem framing, alternative approaches, upstream dependencies, GDD linkage, and status. Schema design questions (e.g., \"How should spawn timing work?\", \"Should data be inline or external?\") are NOT assumptions — they are design decisions belonging to a separate step after the assumptions are confirmed. Do not include schema design questions in the assumptions AskUserQuestion widget.\n\n**After assumptions are confirmed**, if the ADR involves schema or data design choices, use a separate multi-tab `AskUserQuestion` to ask each design question independently before drafting.\n\n**Present assumptions with `AskUserQuestion`:**\n\n```\nHere's what I'm assuming before drafting:\n\nProblem: [one-sentence problem statement derived from context]\nAlternatives I'll consider:\n A) [option derived from engine reference]\n B) [option derived from GDD requirements]\n C) [option from common patterns]\nGDD systems driving this: [list derived from context]\nDependencies: [upstream ADRs if any, otherwise \"None\"]\nStatus: Proposed\n\n[A] Proceed — draft with these assumptions\n[B] Change the alternatives list\n[C] Adjust the GDD linkage\n[D] Add a performance budget constraint\n[E] Something else needs changing first\n```\n\nDo not generate the ADR until the user confirms assumptions or provides corrections.\n\n**After engine specialist and TD reviews return** (Step 5.5/5.6), if unresolved\ndecisions remain, present each one as a separate `AskUserQuestion` with the proposed\noptions as choices plus a free-text escape:\n\n```\nDecision: [specific unresolved point]\n[A] [option from specialist review]\n[B] [alternative option]\n[C] Different approach — I'll describe it\n```\n\n**ADR Dependencies** — derive from existing ADRs, then confirm:\n- Does this decision depend on any other ADR not yet Accepted?\n- Does it unlock or unblock any other ADR or epic?\n- Does it block any specific epic from starting?\n\nRecord answers in the **ADR Dependencies** section. Write \"None\" for each field if no constraints apply.\n\n---\n",".claude/skills/architecture-decision/references/5-generate.md":"# /architecture-decision — Step 5: Generate the ADR\n\n> Part of `/architecture-decision`. `SKILL.md` names when to read this file; the settings it\n> resolved and the rules under its later headings still apply here.\n\n## 5. Generate the ADR\n\n**In this file:**\n\n- The ADR template\n- 5.5 Engine Specialist Validation\n- 5.6 Technical Director Strategic Review, with the review mode check\n- 5.7 GDD Sync Check: found, none found, could not check\n- Write approval\n- Update Architecture Registry, and the registry append logic\n\nFollowing this format:\n\n```markdown\n# ADR-[NNNN]: [Title]\n\n## Status\n[Proposed | Accepted | Deprecated | Superseded by ADR-XXXX]\n\n## Date\n[Date of decision]\n\n## Last Verified\n[YYYY-MM-DD — when this ADR was last confirmed accurate against the current\nengine version and design. Update this date when you re-read and confirm it is\nstill correct, even if nothing changed.]\n\n## Decision Makers\n[Who was involved in this decision]\n\n## Summary\n[2 sentences: what problem this ADR solves, and what was decided. Written for\ntiered context loading — a skill scanning 20 ADRs uses this to decide whether to\nread the full decision. Be specific: name the system, the problem, and the\nchosen approach.]\n\n## Engine Compatibility\n\n| Field | Value |\n|-------|-------|\n| **Engine** | [e.g. Godot 4.7] |\n| **Domain** | [Physics / Rendering / UI / Audio / Navigation / Animation / Networking / Core / Input] |\n| **Layer** | [Foundation / Core / Feature / Presentation] |\n| **Knowledge Risk** | [LOW / MEDIUM / HIGH — from VERSION.md] |\n| **References Consulted** | [List engine-reference docs read, e.g. `docs/engine-reference/godot/modules/physics.md`] |\n| **Post-Cutoff APIs Used** | [Any APIs from post-LLM-cutoff versions this decision depends on, or \"None\"] |\n| **Verification Required** | [Specific behaviours to test before shipping, or \"None\"] |\n\n## ADR Dependencies\n\n| Field | Value |\n|-------|-------|\n| **Depends On** | [ADR-NNNN (must be Accepted before this can be implemented), or \"None\"] |\n| **Enables** | [ADR-NNNN (this ADR unlocks that decision), or \"None\"] |\n| **Blocks** | [Epic/Story name — cannot start until this ADR is Accepted, or \"None\"] |\n| **Ordering Note** | [Any sequencing constraint that isn't captured above] |\n\n## Context\n\n### Problem Statement\n[What problem are we solving? Why does this decision need to be made now?]\n\n### Constraints\n- [Technical constraints]\n- [Timeline constraints]\n- [Resource constraints]\n- [Compatibility requirements]\n\n### Requirements\n- [Must support X]\n- [Must perform within Y budget]\n- [Must integrate with Z]\n\n## Decision\n\n[The specific technical decision made, described in enough detail for someone\nto implement it.]\n\n### Architecture Diagram\n[ASCII diagram or description of the system architecture this creates]\n\n### Key Interfaces\n[API contracts or interface definitions this decision creates]\n\n### Implementation Guidelines\n[Specific guidance for the programmer implementing this decision — the rules a\n`/create-control-manifest` or `/dev-story` run should follow. State mandates as\n\"must / must never\" so they extract cleanly.]\n\n## Alternatives Considered\n\n### Alternative 1: [Name]\n- **Description**: [How this would work]\n- **Pros**: [Advantages]\n- **Cons**: [Disadvantages]\n- **Rejection Reason**: [Why this was not chosen]\n\n### Alternative 2: [Name]\n- **Description**: [How this would work]\n- **Pros**: [Advantages]\n- **Cons**: [Disadvantages]\n- **Rejection Reason**: [Why this was not chosen]\n\n## Consequences\n\n### Positive\n- [Good outcomes of this decision]\n\n### Negative\n- [Trade-offs and costs accepted]\n\n## Risks\n- [Things that could go wrong]\n- [Mitigation for each risk]\n\n## GDD Requirements Addressed\n\n| GDD System | Requirement | How This ADR Addresses It |\n|------------|-------------|--------------------------|\n| [system-name].md | [specific rule, formula, or performance constraint from that GDD] | [how this decision satisfies it] |\n\n## Performance Implications\n- **CPU**: [Expected impact]\n- **Memory**: [Expected impact]\n- **Load Time**: [Expected impact]\n- **Network**: [Expected impact, if applicable]\n\n## Migration Plan\n[If this changes existing code, how do we get from here to there?]\n\n## Validation Criteria\n[How will we know this decision was correct? What metrics or tests?]\n\n## Related\n- [Links to related ADRs — note if supersedes, contradicts, or depends on]\n- [Links to related design documents]\n```\n\n**Always write the Layer row.** An ADR with no Layer row counts as critical\n(Foundation) wherever it is read, so at `standard` its advisory items become\nblockers. The value is the ADR's own layer, how early in the build it must\nexist: the layer `docs/architecture/architecture.md`'s layer map gives the\nsystem this decision governs. With no layer map, or no system in it, ask the\nuser, with the four values as options. Never take it from an epic that\nreferences the ADR, and never reuse a `Domain` value (the template's note under\nEngine Compatibility says why).\n\n5.5. **Engine Specialist Validation** — Before saving, spawn the **primary engine specialist** via `Agent` to validate the drafted ADR:\n - Resolve the primary specialist: `-specialist` derived from `engine.name` in `project.yaml` (Godot→`godot-specialist`, Unity→`unity-specialist`, Unreal→`unreal-specialist`); if `engine.name` is absent or empty, read the Primary line of the `## Engine Specialists` section in `.claude/docs/technical-preferences.md`\n - If no engine is configured (neither source yields an engine), skip this step **Record ``Engine validation: NOT ASSESSED — no engine configured (`engine.name` unset in `project.yaml`)`` in this run's output.** A skipped check that says nothing is indistinguishable from a check that passed; the reader cannot tell engine guidance was never sought.\n - Spawn `subagent_type: [primary specialist]` with: the ADR's Engine Compatibility section, Decision section, Key Interfaces, and the engine reference docs path. Ask them to:\n 1. Confirm the proposed approach is idiomatic for the pinned engine version\n 2. Flag any APIs or patterns that are deprecated or changed post-training-cutoff\n 3. Identify engine-specific risks or gotchas not captured in the current ADR draft\n - If the specialist identifies a **blocking issue** (wrong API, deprecated approach, engine version incompatibility): revise the Decision and Engine Compatibility sections accordingly, then confirm the changes with the user before proceeding\n - If the specialist finds **minor notes** only: incorporate them into the ADR's Risks subsection\n\n**Review mode check** — apply before spawning TD-ADR:\n- `solo` → skip. Note: \"TD-ADR skipped — Solo mode.\" Proceed to Step 5.7 (GDD sync check).\n- `lean` → skip (not a PHASE-GATE). Note: \"TD-ADR skipped — Lean mode.\" Proceed to Step 5.7 (GDD sync check).\n- `full` → spawn as normal.\n\n5.6. **Technical Director Strategic Review** — After the engine specialist validation, spawn `technical-director` via `Agent` using gate **TD-ADR** (`.claude/docs/director-gates/td-adr.md`):\n - Pass: the ADR file path (or draft content), engine version, domain, any existing ADRs in the same domain\n - The TD validates architectural coherence (is this decision consistent with the whole system?) — distinct from the engine specialist's API-level check\n - On CONCERNS: show them to the user verbatim and ask with the standard options from `director-gates.md` — `Revise flagged items` / `Accept and proceed` / `Discuss further`. Revise the flagged Decision or Alternatives sections only on `Revise flagged items`.\n - On REJECT: show the blockers verbatim and revise the Decision or Alternatives sections before proceeding.\n - A revised draft still reaches the user through the write approval below; nothing is written before it. A `NOT ASSESSED` answer is not an approval — name the missing input (`director-gates.md`).\n\n5.7. **GDD Sync Check** — Before presenting the write approval, scan all GDDs\nreferenced in the \"GDD Requirements Addressed\" section for naming inconsistencies\nwith the ADR's Key Interfaces and Decision sections (renamed signals, API methods,\nor data types). If any are found, surface them as a **prominent warning block**\nimmediately before the write approval — not as a footnote:\n\n```\n⚠️ GDD SYNC REQUIRED\n[gdd-filename].md uses names this ADR has renamed:\n [old_name] → [new_name_from_adr]\n [old_name_2] → [new_name_2_from_adr]\nThe GDD must be updated before or alongside writing this ADR to prevent\ndevelopers reading the GDD from implementing the wrong interface.\n```\n\n**This check has three outcomes, not two.** The two above are \"found\" and \"none\nfound\"; the third is **could not check**, which must never take the silent\nbranch and render like a clean result.\n\n- **None found** — print one line, do not stay silent:\n `GDD sync: checked [N] referenced GDD(s), no naming inconsistencies.`\n A silent pass is indistinguishable from a check that never ran, and this one\n guards against developers implementing the wrong interface from a stale GDD.\n- **Could not check** — the ADR has no `GDD Requirements Addressed` section, it\n names no GDDs, or a named GDD does not exist on disk. Print:\n `GDD sync: NOT ASSESSED — [which reason, and which files]`\n Do **not** treat an ADR that references no GDDs as one whose GDDs are\n consistent. Nothing was compared.\n\nOnly the warning block itself is conditional; the check always reports.\n\n5. **Write approval** — Use `AskUserQuestion`:\n\nIf GDD sync issues were found:\n- \"ADR draft is complete. How would you like to proceed?\"\n - [A] Write ADR + update GDD in the same pass\n - [B] Write ADR only — I'll update the GDD manually\n - [C] Not yet — I need to review further\n\nIf no GDD sync issues:\n- \"ADR draft is complete. May I write it?\"\n - [A] Write ADR to `docs/architecture/adr-[NNNN]-[slug].md`\n - [B] Not yet — I need to review further\n\nIf yes to any write option, write the file, creating the directory if needed.\nFor option [A] with GDD update: also update the GDD file(s) to use the new names.\n\n6. **Update Architecture Registry**\n\nScan the written ADR for new architectural stances that should be registered:\n- State it claims ownership of\n- Interface contracts it defines (signal signatures, method APIs)\n- Performance budget it claims\n- API choices it makes explicitly\n- Patterns it bans (Consequences → Negative or explicit \"do not use X\")\n\nPresent candidates:\n```\nRegistry candidates from this ADR:\n NEW state ownership: player_stamina → stamina-system\n NEW interface contract: stamina_depleted signal\n NEW performance budget: stamina-system: 0.5ms/frame\n NEW forbidden pattern: polling stamina each frame (use signal instead)\n EXISTING (referenced_by update only): player_health → already registered ✅\n```\n\n**Registry append logic**: When writing to `docs/registry/architecture.yaml`, do NOT assume sections are empty. The file may already have entries from previous ADRs written in this session. Before each Edit call:\n1. Read the current state of `docs/registry/architecture.yaml`\n2. Find the correct section (state_ownership, interfaces, forbidden_patterns, api_decisions)\n3. If the section is still the empty list (`state_ownership: []`), replace `[]` with the first entry: the key alone on its line, the entry below it indented two spaces as in the file's commented example. An entry appended after `[]` makes the file invalid YAML. Otherwise append the new entry AFTER the last existing entry in that section\n4. If the section has entries already, use the closing content of the last entry as the `old_string` anchor, and append the new entry after it\n\n**BLOCKING — do not write to `docs/registry/architecture.yaml` without explicit user approval.**\n\nAsk using `AskUserQuestion`:\n- \"May I update `docs/registry/architecture.yaml` with these [N] new stances?\"\n - Options: \"Yes — update the registry\", \"Not yet — I want to review the candidates\", \"Skip registry update\"\n\nOnly proceed if the user selects yes. If yes: append new entries. Never modify existing entries — if a stance is\nchanging, set the old entry to `status: \"superseded_by: ADR-[NNNN]\"` and add the new entry. Keep the quotes:\nunquoted, the second colon makes the file invalid YAML.\n\nAfter writing, run `bash .claude/scripts/registry.sh validate` and fix every row about an entry this write added\nor changed (a DUPLICATE, STATUS or LAYOUT row, an UNQUOTED row (quote the value it names), or a PATH_MISSING row for a path it named) before you go on; name\nrows about other entries to the user rather than fixing them unasked. If the script is missing or prints nothing,\nsay the registry check did not run, then re-read the entries you wrote against the rules in the file's header.\n\n---\n",".claude/skills/architecture-review/SKILL.md":"---\nname: architecture-review\ndescription: \"Traceability matrix mapping GDD requirements to ADRs. Finds gaps, cross-ADR conflicts, engine compatibility. PASS/CONCERNS/NOT ASSESSED/FAIL.\"\nargument-hint: \"[focus: full | coverage | consistency | engine | rtm | single-gdd path/to/gdd.md]\"\nuser-invocable: true\nallowed-tools: Read, Glob, Grep, Write, Edit, Agent, AskUserQuestion, Bash(bash \"*/.claude/skills/architecture-review/../../hooks/yaml-helper.sh\" resolve_config *), Bash(bash .claude/scripts/review-receipts.sh check *), Bash(bash .claude/scripts/review-receipts.sh hash *), Bash(bash .claude/scripts/adr-dep-graph.sh*), Bash(bash .claude/scripts/registry.sh validate*)\nmodel: opus\n---\n\n!`bash \"${CLAUDE_SKILL_DIR}/../../hooks/yaml-helper.sh\" resolve_config --keys automation,workflow`\n\n# Architecture Review\n\nThe architecture review validates that the complete body of architectural decisions\ncovers all game design requirements, is internally consistent, and correctly targets\nthe project's pinned engine version. It is the quality gate between Technical Setup\nand Pre-Production.\n\n**Argument modes:**\n- **No argument / `full`**: Full review — all phases\n- **`coverage`**: Traceability only — which GDD requirements have no ADR\n- **`consistency`**: Cross-ADR conflict detection only\n- **`engine`**: Engine compatibility audit only\n- **`single-gdd [path]`**: Review architecture coverage for one specific GDD\n- **`rtm`**: Requirements Traceability Matrix — extends the standard matrix\n to include story file paths and test file paths; outputs\n `docs/architecture/requirements-traceability.md` with the full\n GDD requirement → ADR → Story → Test chain. Use in Production phase when\n stories and tests exist.\n\n---\n\nEvery `AskUserQuestion` call follows `.claude/docs/automation-modes.md`\n(collaborative asks always · guided major-only · autonomous logs and proceeds;\n`automation_always_ask` categories always prompt).\n\n**`workflow`** (see `.claude/docs/workflow-modes.md`):\n- `full` — full traceability matrix across all GDDs and all ADRs.\n- `standard` — reduced scope: architecture doc + critical ADRs only.\n- `minimal` — not applicable (no architecture doc required).\n\n## Phase 1: Load Everything\n\n**Read `references/1-load.md` now and follow it** — this phase's steps are in that file, not here. Read it again if the conversation was compacted or resumed during this phase.\n\n## Phase 2: Extract Technical Requirements from Every GDD\n\n**Read `references/2-extract-requirements.md` now and follow it** — this phase's steps are in that file, not here. Read it again if the conversation was compacted or resumed during this phase.\n\n## Phase 3: Build the Traceability Matrix\n\n**Read `references/3-traceability.md` now and follow it** — this phase's steps are in that file, not here. Read it again if the conversation was compacted or resumed during this phase.\n\n## Phase 4: Cross-ADR Conflict Detection\n\n**Read `references/4-conflicts.md` now and follow it** — this phase's steps are in that file, not here. Read it again if the conversation was compacted or resumed during this phase.\n\n## Phase 5: Engine Compatibility Cross-Check\n\n**Read `references/5-engine.md` now and follow it** — this phase's steps are in that file, not here. Read it again if the conversation was compacted or resumed during this phase.\n\n## Phase 6: Architecture Document Coverage\n\n**Read `references/6-document-coverage.md` now and follow it** — this phase's steps are in that file, not here. Read it again if the conversation was compacted or resumed during this phase.\n\n## Phase 7: Output the Review Report\n\n**Read `references/7-report.md` now and follow it** — this phase's steps are in that file, not here. Read it again if the conversation was compacted or resumed during this phase.\n\n## Phase 8: Write and Update Traceability Index\n\n**Read `references/8-write.md` now and follow it** — this phase's steps are in that file, not here. Read it again if the conversation was compacted or resumed during this phase.\n\n## Phase 9: Handoff\n\n**Read `references/9-handoff.md` now and follow it** — this phase's steps are in that file, not here. Read it again if the conversation was compacted or resumed during this phase.\n\n## Error Recovery Protocol\n\n**First, verify the artifact.** If the return contract named a path, check the\npath exists before treating the phase as done — **a named artifact that is not\non disk is a failed phase, however fluent the response reads.** An agent can\nburn a full phase and return a plausible preamble having written nothing, which\nis neither BLOCKED nor an error nor \"fails to complete\", so the trigger below\nnever fires. Resume it naming the unmet contract; the context is\nusually still there.\n\nIf any spawned agent returns BLOCKED, errors, or fails to complete: **surface it\nimmediately, don't proceed past a dependency it blocks, and always produce a\npartial report** (retry scope here = fewer GDDs / single-system). Full procedure:\n`.claude/docs/error-recovery-protocol.md`.\n\n---\n\n## Collaborative Protocol\n\n**Applies in `collaborative` mode (the default).** For `guided` and\n`autonomous` modes, see `.claude/docs/automation-modes.md` — the rules below\ndescribe what collaborative mode requires, not universal behavior.\n\n1. **Read silently** — do not narrate every file read\n2. **Show the matrix** — present the full traceability matrix before any write\n approval; let the user see the state\n3. **Don't guess** — if a requirement is ambiguous, ask: \"Is [X] a technical\n requirement or a design preference?\"\n4. **Draft before approval** — always show the content that will be written (the\n report, the updated ADR section, the systems-index row) inline in the conversation\n before requesting approval. Never ask to write something the user has not yet seen.\n5. **Use `AskUserQuestion` for write approvals** — plain text \"May I?\" is not\n sufficient. Use the structured tool with labeled options [A]/[B]/[C] so the\n user can choose between \"write now\", \"show full draft first\", and \"not yet\".\n Multi-file changesets must list every file and what changes, then ask once\n with grouped options — not a separate plain-text question per file.\n6. **Non-blocking** — the verdict is advisory; the user decides whether to continue\n despite CONCERNS or even FAIL findings\n",".claude/skills/architecture-review/references/1-load.md":"# /architecture-review — Phase 1: Load Everything\n\n> Part of `/architecture-review`. `SKILL.md` names when to read this file; the settings it\n> resolved and the rules under its later headings still apply here.\n\n## Phase 1: Load Everything\n\n**In this file:**\n\n- Phase 1a — L0: Summary Scan (fast, low tokens)\n- Phase 1b — L1/L2: Targeted Section Load\n- Design Documents\n- Architecture Documents\n- Engine Reference\n- Project Standards\n\n### Phase 1a — L0: Summary Scan (fast, low tokens)\n\n**Freshness check before any scan.** A prior report can stand in for this run\nonly if nothing it rests on has changed: the documents, the engine reference,\nthe project config, this skill, and the kind of review that produced it.\n\nIn `rtm` mode, skip the check and say so — *\"Freshness check: not run — rtm\nbuilds the matrix fresh, because stories and tests change without any review\ninput changing.\"*\n\nOtherwise locate the latest prior report — Glob\n`docs/architecture/architecture-review-*.md` and take the newest — and check\n**the review inputs**: every file the phases below read that can change a\nfinding or the verdict. `[engine]` is the lowercased `engine.name` from\n`project.yaml`, the value Phase 5 uses; with no engine configured, leave the two\nengine-reference paths out.\n\n```\nBash: bash .claude/scripts/review-receipts.sh check \"[latest-report]\" docs/architecture/adr-*.md design/gdd/*.md docs/architecture/tr-registry.yaml docs/architecture/architecture.md docs/engine-reference/[engine]/*.md docs/engine-reference/[engine]/modules/*.md project.yaml .claude/docs/technical-preferences.md docs/consistency-failures.md .claude/skills/architecture-review/SKILL.md .claude/skills/architecture-review/references/*.md\n```\n\nPhase 8 stamps the same list into this run's report; keep the two identical,\nand add any file a phase starts reading to both. The check also compares every\nfile the prior report stamped, named here or not, and prints `GONE:` for one\nthat no longer exists.\n\nThen read the prior report's `Mode:` and `Workflow:` lines. It **covers** this\nrun only when its Mode is this run's mode (for `single-gdd`, the same path) or\n`full`, and its Workflow is this run's resolved `workflow` or `full`. A report\nwithout those lines was written before they existed and covers nothing.\n\n- **Any `UNRESOLVED`** — check this FIRST; it disqualifies every option\n below. A glob matched no file, so that whole document class was never\n examined and the comparison covered less than it appears to. Say which\n pattern came back unresolved, and neither stand on the prior report nor\n scope a re-run from it: an ADR or GDD directory that is empty, renamed or\n misspelled is a finding about the project. Run the review as asked; its\n verdict is NOT ASSESSED for the missing class (Phase 7), never a stop with\n no report. Never read a set of `UNCHANGED` lines as\n \"everything is current\" while an `UNRESOLVED` line is present — the set\n compared was not the set requested.\n- **The prior report does not cover this run** — check this second, whatever\n the other lines say. Say why: *\"The last report was a [mode] review at\n workflow [tier]; it does not cover this run.\"* Run the review as asked.\n Never offer to stand on it or to scope a re-run from it.\n- **Everything `UNCHANGED`** — nothing this review reads has changed since\n that report; re-running reproduces it. Surface the prior report's date,\n mode and verdict and offer via `AskUserQuestion`: `[A] Stand on the prior\n report (Recommended)` / `[B] Re-run the full review anyway` — `guided`\n proceeds with [A] and notes it; `autonomous` logs via `log_decision` and\n stands on the prior report.\n- **Only GDDs or ADRs `CHANGED`/`NEW`** — name them, then scope instead of\n re-running everything: recommend `/architecture-review single-gdd [path]`\n for just the changed systems. A full re-run stays available on request, and\n a `NEW` ADR warrants one.\n- **Anything else `CHANGED`, `NEW` or `GONE`** — a deleted GDD or ADR, the TR\n registry, `architecture.md`, the engine reference, `project.yaml`,\n `technical-preferences.md`, `consistency-failures.md`, or this skill's own\n files. These reach every phase, so recommend re-running the review as\n asked, never a `single-gdd` scope, and name each input with what it\n affects — e.g. *\"The engine reference changed after the\n last report: its deprecated-API audit, which `/gate-check` reads, was made\n against the old one.\"*\n- **`RECEIPT: NONE`** — no prior report, or one written before receipts\n existed. Proceed with the full review; this run's report will carry the\n first stamps.\n\nBefore reading any full document, use Grep to extract `## Summary` sections\nfrom all GDDs and ADRs:\n\n```\nGrep pattern=\"## Summary\" glob=\"design/gdd/*.md\" output_mode=\"content\" -A 4\nGrep pattern=\"## Summary\" glob=\"docs/architecture/adr-*.md\" output_mode=\"content\" -A 3\n```\n\n**Fail open on a missing Summary.** Establish the denominator: glob\n`design/gdd/*.md` and count **N**. A scan matching fewer than N means those GDDs\npredate `## Summary` (`/design-system` emits it, but older GDDs lack it) — never\ntreat an absent Summary as a system out of scope. A zero-match scan means \"no GDD\ncarries a Summary yet\", not \"nothing to review\": full-read the unmatched set.\n\nFor `single-gdd [path]` mode: use the target GDD's summary to identify which\nADRs reference the same system (Grep ADRs for the system name), then load only\nthose ADRs' sections per Phase 1b. Skip unrelated GDDs entirely.\n\nFor `engine` mode: load ADR sections only — GDDs are not needed for engine checks.\nIn practice this is the `## Engine Compatibility` scan alone.\n\nFor `coverage` or `full` mode: proceed to Phase 1b for the full in-scope set.\n**This is a section load, not a full-file load** — see below for why, and for the\nnarrow cases that still justify escalating to a whole document.\n\n### Phase 1b — L1/L2: Targeted Section Load\n\nLoad the sections the later phases actually consume — **not whole files**. This\nskill reads the two largest document sets in the project (every GDD *and* every\nADR); at realistic sizes a full load of both exhausts the context window before\nPhase 2 starts, and most of what it loads is narrative this skill never uses.\n\n**Establish the denominator first.** Glob `design/gdd/*.md` and count **N_gdd**;\nglob `docs/architecture/adr-*.md` and count **N_adr**. Report both. A section\nscan matching fewer than the denominator means those documents lack the section —\n**never treat an absent section as an absent document.** The scan narrows the\n*read* set; it never shrinks the *in-scope* set.\n\n### Design Documents\n\nPhase 2 extracts *technical requirements* — data structures, performance\nconstraints, engine capabilities, cross-system communication, persistence,\nthreading, platform needs. Those live in a known set of sections; Overview and\nPlayer Fantasy are narrative and yield none.\n\n```\nGrep pattern=\"^## (Detailed Rules|Detailed Design|Formulas|Dependencies|Tuning Knobs|Acceptance Criteria)\" glob=\"design/gdd/*.md\" output_mode=\"content\" -A 40\n```\n\nAccept **either** `## Detailed Rules` or `## Detailed Design` — the design\nstandard and the GDD template disagree on the name and they denote the same\nrequired section. Full-read a single GDD only when a scanned section\ncross-references material outside itself, or when a GDD matched zero sections\n(it predates the template — read it whole and say so).\n\n- `design/gdd/systems-index.md` — the authoritative list of systems; read whole (small, and it is an index)\n\n### Architecture Documents\n\nPhases 3–5 need the traceability table, the decision itself, engine claims, and\nthe dependency edges — not Context, Consequences, Alternatives, Migration Plan or\nValidation Criteria, which explain *why* a decision was made.\n\n```\nGrep pattern=\"^## (Status|Decision|GDD Requirements Addressed|Engine Compatibility|ADR Dependencies|Performance Implications)\" glob=\"docs/architecture/adr-*.md\" output_mode=\"content\" -A 30\n```\n\nInterpret against **N_adr**, and distinguish the two zero-match cases — they are\nnot the same finding:\n\n| Result | Meaning | Action |\n|---|---|---|\n| N_adr matches | Normal. | Proceed on the scanned sections. |\n| Some ADRs match, some do not | Those ADRs are missing sections. | Record each as a **structural gap** in the Phase 7 report — a missing `## GDD Requirements Addressed` is itself a traceability finding. |\n| **0 matches, N_adr > 0** | **Malformed ADRs**, not \"no architecture\". | \"[N_adr] ADRs found, none carries a scannable section — run `/architecture-decision retrofit [file]` on each.\" Do **not** report zero coverage; that would read as a design failure when it is a format failure. |\n\nEscalate to a full read of one ADR only when judging a conflict needs its\nreasoning (Phase 4) — that is a per-ADR decision, not a blanket load.\n\n- `docs/architecture/architecture.md` if it exists\n\n### Engine Reference\n- `docs/engine-reference/[engine]/VERSION.md`\n- `docs/engine-reference/[engine]/breaking-changes.md`\n- `docs/engine-reference/[engine]/deprecated-apis.md`\n- **Only the module docs the in-scope ADRs actually name** — take the union of\n each ADR's `References Consulted` and `Post-Cutoff APIs Used` fields (already\n captured by the `## Engine Compatibility` scan above) and read those files.\n Reading the whole `modules/` directory loads engine subsystems the project may\n not use at all. If no ADR names any module, read none and note it: Phase 5\n cannot cross-check engine claims that were never made.\n\n### Project Standards\n- `project.yaml` — `naming.*` and `performance.*`; plus `.claude/docs/technical-preferences.md` for those keys when absent and for forbidden patterns / allowed libraries\n\nReport a count: \"Loaded [N] GDDs, [M] ADRs, engine: [name + version].\"\n\n**Also read `docs/consistency-failures.md`** if it exists. Extract entries with\nDomain matching the systems under review (Architecture, Engine, or any GDD domain\nbeing covered). Surface recurring patterns as a \"Known conflict-prone areas\" note\nat the top of the Phase 4 conflict detection output.\n\n---\n",".claude/skills/architecture-review/references/2-extract-requirements.md":"# /architecture-review — Phase 2: Extract Technical Requirements\n\n> Part of `/architecture-review`. `SKILL.md` names when to read this file; the settings it\n> resolved and the rules under its later headings still apply here.\n\n## Phase 2: Extract Technical Requirements from Every GDD\n\n### Pre-load the TR Registry\n\nBefore extracting any requirements, read `docs/architecture/tr-registry.yaml`\nif it exists. Index existing entries by `id` and by normalized `requirement`\ntext (lowercase, trimmed). This prevents ID renumbering across review runs.\n\nThen read the Technical Requirements Baseline in `docs/architecture/architecture.md`\nif it exists. `/create-architecture` numbers each requirement the registry did not\nhold as `(provisional)`, from the registry's next free ID, and ADRs written from\nthe baseline may already cite those IDs.\n\nFor each requirement you extract, the matching rule is:\n1. **Exact/near match** to an existing registry entry for the same system →\n reuse that entry's TR-ID unchanged. Update the `requirement` text in the\n registry only if the GDD wording changed (same intent, clearer phrasing) —\n add a `revised: [date]` field.\n2. **Match to a provisional baseline row** (same system, same intent) → keep that\n ID when the registry holds no entry with it, active or retired: registering it\n is what makes it permanent. When the ID is taken, assign the next available one\n and list the rename (`TR-[system]-004 (provisional) → TR-[system]-006`) in the\n report, so the ADRs and stories that cite it can be updated.\n3. **No match** → assign a new ID: next available `TR-[system]-NNN` for that\n system, starting from the highest existing sequence + 1, skipping any ID a\n provisional baseline row holds.\n4. **Ambiguous** (partial match, intent unclear) → ask the user:\n > \"Does '[new requirement text]' refer to the same requirement as\n > `TR-[system]-NNN: [existing text]'`, or is it a new requirement?\"\n User answers: \"Same requirement\" (reuse ID) or \"New requirement\" (new ID).\n\nFor any requirement with `status: deprecated` in the registry — skip it.\nIt was removed from the GDD intentionally.\n\nFor each GDD, read it and extract all **technical requirements** — things the\narchitecture must provide for the system to work. A technical requirement is any\nstatement that implies a specific architectural decision.\n\nCategories to extract:\n\n| Category | Example |\n|----------|---------|\n| **Data structures** | \"Each entity has health, max health, status effects\" → needs a component/data schema |\n| **Performance constraints** | \"Collision detection must run at 60fps with 200 entities\" → physics budget ADR |\n| **Engine capability** | \"Inverse kinematics for character animation\" → IK system ADR |\n| **Cross-system communication** | \"Damage system notifies UI and audio simultaneously\" → event/signal architecture ADR |\n| **State persistence** | \"Player progress persists between sessions\" → save system ADR |\n| **Threading/timing** | \"AI decisions happen off the main thread\" → concurrency ADR |\n| **Platform requirements** | \"Supports keyboard, gamepad, touch\" → input system ADR |\n\nFor each GDD, produce a structured list:\n\n```\nGDD: [filename]\nSystem: [system name]\nTechnical Requirements:\n TR-[GDD]-001: [requirement text] → Domain: [Physics/Rendering/etc]\n TR-[GDD]-002: [requirement text] → Domain: [...]\n```\n\nThis becomes the **requirements baseline** — the complete set of what the\narchitecture must cover.\n\n---\n",".claude/skills/architecture-review/references/3-traceability.md":"# /architecture-review — Phases 3 and 3b: Traceability Matrix and Story Linkage\n\n> Part of `/architecture-review`. `SKILL.md` names when to read this file; the settings it\n> resolved and the rules under its later headings still apply here.\n\n## Phase 3: Build the Traceability Matrix\n\n**In this file:**\n\n- Step 3b-1 — Load stories\n- Step 3b-2 — Load test files\n- Step 3b-3 — Build the extended RTM\n\nFor each technical requirement extracted in Phase 2, search the ADRs:\n\n1. Use the ADRs **already loaded in Phase 1b** — do not re-read them. Extract each\n ADR's \"GDD Requirements Addressed\" section from what is already in context.\n (If Phase 1b ran in a mode that did not load every ADR, `Grep pattern=\"## GDD\n Requirements Addressed\" glob=\"docs/architecture/adr-*.md\" output_mode=\"content\"\n -A 15` fills the gap without a full re-read.)\n2. Check if it explicitly references the requirement or its GDD\n3. Check if the ADR's decision text implicitly covers the requirement\n4. Mark coverage status:\n\n| Status | Meaning |\n|--------|---------|\n| ✅ **Covered** | An **Accepted** ADR explicitly addresses this requirement |\n| 🟡 **Covered (Proposed)** | An ADR addresses it, but that ADR is still `Proposed` |\n| ⚠️ **Partial** | An ADR partially covers this, or coverage is ambiguous |\n| ❌ **Gap** | No ADR addresses this requirement |\n| ❓ **Not assessed** | The ADR is unreadable, or has no `## Status` section |\n\n> **Read each ADR's `## Status` before marking coverage — an unaccepted decision\n> is not coverage.** If `✅` meant only that *an ADR addresses this*, with no\n> status qualification, a requirement covered entirely by `Proposed` ADRs would\n> count as covered and this review could return **PASS: All requirements\n> covered** over an architecture nobody had accepted. Four skills downstream\n> (`create-control-manifest`, `create-epics`, `create-stories`, `gate-check`)\n> require `Accepted`, so a PASS on that basis sends work forward that every one\n> of them will refuse.\n>\n> `🟡` is **not** a pass state: it caps the verdict at **CONCERNS**, and names the\n> route out — `/architecture-decision accept ADR-NNNN`. That route is the only\n> thing that moves an ADR to `Accepted`; without it, grading `Proposed` as\n> covered would be the only option, which is why it must never be graded so.\n\nBuild the full matrix:\n\n```\n## Traceability Matrix\n\n| Requirement ID | GDD | System | Requirement | ADR Coverage | Status |\n|---------------|-----|--------|-------------|--------------|--------|\n| TR-combat-001 | combat.md | Combat | Hitbox detection < 1 frame | ADR-0003 | ✅ |\n| TR-combat-002 | combat.md | Combat | Combo window timing | — | ❌ GAP |\n| TR-inventory-001 | inventory.md | Inventory | Persistent item storage | ADR-0005 | ✅ |\n```\n\nCount the totals: X covered, Y partial, Z gaps.\n\n---\n\n## Phase 3b: Story and Test Linkage (RTM mode only)\n\n*Skip this phase unless the argument is `rtm` or `full` with stories present.*\n\nThis phase extends the Phase 3 matrix to include the story that implements\neach requirement and the test that verifies it — producing the full\nRequirements Traceability Matrix (RTM).\n\n### Step 3b-1 — Load stories\n\nGlob `production/epics/**/*.md` (excluding EPIC.md index files) to establish the\ndenominator. Then collect the fields with **targeted section greps, not a full\nread of each story** — the same two-grep form `/test-evidence-review` uses for\nthis identical extraction:\n\n```\nGrep pattern=\"## Test Evidence\" glob=\"production/epics/**/story-*.md\" output_mode=\"content\" -A 8\nGrep pattern=\"TR-\" glob=\"production/epics/**/story-*.md\" output_mode=\"content\"\n```\n\n- **TR-ID** — from the second grep.\n- **Test file path** — under `## Test Evidence`, captured by the first grep's `-A 8`.\n- **Status** — from the story header; add `Grep pattern=\"^> \\*\\*Status\\*\\*\"` if not already captured.\n- **Story path and title** — from the file name and path; no read at all.\n\nFull-read a story only when its Test Evidence section is missing or ambiguous.\n\n### Step 3b-2 — Load test files\n\nGlob the engine's test root (`.claude/docs/directory-structure.md`): Godot\n`tests/unit/**/*_test.*` and `tests/integration/**/*_test.*`; Unity\n`Assets/Tests/**/*Tests.cs`; Unreal `Source/*/Private/Tests/**/*.cpp`. With no\nengine configured, say the test index could not be built rather than reading an\nempty glob as \"no tests\". Build an index: system → [test file paths].\n\nFor each test file path from Step 3b-1, confirm via Glob whether the file\nactually exists. Note MISSING if the stated path does not exist.\n\n### Step 3b-3 — Build the extended RTM\n\nFor each TR-ID in the Phase 3 matrix, add:\n- **Story**: the story file path(s) that reference this TR-ID (may be multiple)\n- **Test File**: the test file path stated in the story's Test Evidence section\n- **Test Status**: COVERED (test file exists) / MISSING (path stated but not\n found) / NONE (no test path stated, story type may be Visual/Feel/UI) /\n NO STORY (requirement has no story yet — pre-production gap)\n\nExtended matrix format:\n\n```\n## Requirements Traceability Matrix (RTM)\n\n| TR-ID | GDD | Requirement | ADR | Story | Test File | Test Status |\n|-------|-----|-------------|-----|-------|-----------|-------------|\n| TR-combat-001 | combat.md | Hitbox < 1 frame | ADR-0003 | story-001-hitbox.md | tests/unit/combat/hitbox_test.gd | COVERED |\n| TR-combat-002 | combat.md | Combo window | — | story-002-combo.md | — | NONE (Visual/Feel) |\n| TR-inventory-001 | inventory.md | Persistent storage | ADR-0005 | — | — | NO STORY |\n```\n\nRTM coverage summary:\n- COVERED: [N] — requirements with ADR + story + passing test\n- MISSING test: [N] — story exists but test file not found\n- NO STORY: [N] — requirements with ADR but no story yet\n- NO ADR: [N] — requirements without architectural coverage (from Phase 3 gaps)\n- Full chain complete (COVERED): [N/total] ([%])\n\n---\n",".claude/skills/architecture-review/references/4-conflicts.md":"# /architecture-review — Phase 4: Cross-ADR Conflict Detection\n\n> Part of `/architecture-review`. `SKILL.md` names when to read this file; the settings it\n> resolved and the rules under its later headings still apply here.\n\n## Phase 4: Cross-ADR Conflict Detection\n\nCompare every ADR against every other ADR to detect contradictions. A conflict\nexists when:\n\n- **Data ownership conflict**: Two ADRs claim exclusive ownership of the same data\n- **Integration contract conflict**: ADR-A assumes System X has interface Y, but\n ADR-B defines System X with a different interface\n- **Performance budget conflict**: ADR-A allocates N ms to physics, ADR-B allocates\n N ms to AI, together they exceed the total frame budget\n- **Dependency cycle**: ADR-A says System X initialises before Y; ADR-B says Y\n initialises before X\n- **Architecture pattern conflict**: ADR-A uses event-driven communication for a\n subsystem; ADR-B uses direct function calls to the same subsystem\n- **State management conflict**: Two ADRs define authority over the same game state\n (e.g. both Combat ADR and Character ADR claim to own the health value)\n\nFor each conflict found:\n\n```\n## Conflict: [ADR-NNNN] vs [ADR-MMMM]\nType: [Data ownership / Integration / Performance / Dependency / Pattern / State]\nADR-NNNN claims: [...]\nADR-MMMM claims: [...]\nImpact: [What breaks if both are implemented as written]\nResolution options:\n 1. [Option A]\n 2. [Option B]\n```\n\n### ADR Dependency Ordering\n\nAfter conflict detection, analyse the dependency graph across all ADRs.\n\n**Build the graph deterministically — do not trace it by hand:**\n\n```\nBash: bash .claude/scripts/adr-dep-graph.sh\n```\n\nIt collects every `Depends On` edge, finds the cycles and the order, and emits\n`ADRS:` / `EDGES:` / `NO_DEPS_SECTION:` / `UNFILLED_DEPS:` / `CYCLE:` /\n`BLOCKED_BY_CYCLE:` / `ORDER:`. A model tracing A→B→C→A across\na dozen ADRs eventually misses an edge; the algorithm cannot. It reports\nobservations, not a verdict — you apply the meaning below.\n\n**`NO_DEPS_SECTION` and `UNFILLED_DEPS` are load-bearing**: they make \"no cycles\nbecause the graph is clean\" distinguishable from \"no cycles because half the ADRs\ndeclare no dependencies, or left the template's placeholder in the row\". Report\nthe second case as a structural gap, never as a clean graph, and name each\n`UNFILLED_DEPS` ADR as unfilled: what it depends on is unknown, not none.\n\nThen interpret:\n\n1. **Topological sort**: the `ORDER:` row, as emitted — ADRs with no\n dependencies come first (Foundation), ADRs that depend on those come next, etc.\n Do not re-sort it by hand. An ADR in `NO_DEPS_SECTION` or `UNFILLED_DEPS` sits\n in it as if it depended on nothing: mark it so.\n2. **Flag unresolved dependencies**: cross the `EDGES:` list against the `## Status`\n values already scanned in Phase 1b. If ADR-A depends on an ADR that is still\n `Proposed` or does not exist, flag it:\n ```\n ⚠️ ADR-0005 depends on ADR-0002 — but ADR-0002 is still Proposed.\n ADR-0005 cannot be safely implemented until ADR-0002 is Accepted.\n ```\n3. **Cycle detection**: every `CYCLE:` line the script emitted is a\n `DEPENDENCY CYCLE` — report each one, with the edges its line shows (one of\n them is the edge to cut). A `BLOCKED_BY_CYCLE:` ADR is on no cycle: it waits\n for one to break, so list it as blocked, never as part of the cycle, and never\n suggest cutting its own edges. Do not re-derive them by hand:\n ```\n 🔴 DEPENDENCY CYCLE: ADR-0003 → ADR-0006 → ADR-0003\n This cycle must be broken before either can be implemented.\n ```\n4. **Output recommended implementation order**:\n ```\n ### Recommended ADR Implementation Order (topologically sorted)\n Foundation (no dependencies):\n 1. ADR-0001: [title]\n 2. ADR-0003: [title]\n Depends on Foundation:\n 3. ADR-0002: [title] (requires ADR-0001)\n 4. ADR-0005: [title] (requires ADR-0003)\n Feature layer:\n 5. ADR-0004: [title] (requires ADR-0002, ADR-0005)\n ```\n\n---\n",".claude/skills/architecture-review/references/5-engine.md":"# /architecture-review — Phases 5 and 5b: Engine Cross-Check and Design Revision Flags\n\n> Part of `/architecture-review`. `SKILL.md` names when to read this file; the settings it\n> resolved and the rules under its later headings still apply here.\n\n## Phase 5: Engine Compatibility Cross-Check\n\n**In this file:**\n\n- Version Consistency\n- Post-Cutoff API Consistency\n- Deprecated API Check\n- Missing Engine Compatibility Sections\n- Engine Specialist Consultation\n\nAcross all ADRs, check for engine consistency:\n\n### Version Consistency\n- Do all ADRs that mention an engine version agree on the same version?\n- If any ADR was written for an older engine version, flag it as potentially stale\n\n### Post-Cutoff API Consistency\n- Collect all \"Post-Cutoff APIs Used\" fields from all ADRs\n- For each, verify against the relevant module reference doc\n- Check that no two ADRs make contradictory assumptions about the same post-cutoff API\n\n### Deprecated API Check\n- Grep all ADRs for API names listed in `deprecated-apis.md`\n- Flag any ADR referencing a deprecated API\n\n### Missing Engine Compatibility Sections\n- List all ADRs that are missing the Engine Compatibility section entirely\n- These are blind spots — their engine assumptions are unknown\n\nOutput format:\n```\n### Engine Audit Results\nEngine: [name + version]\nADRs with Engine Compatibility section: X / Y total\n\nDeprecated API References:\n - ADR-0002: uses [deprecated API] — deprecated since [version]\n\nStale Version References:\n - ADR-0001: written for [older version] — current project version is [version]\n\nPost-Cutoff API Conflicts:\n - ADR-0004 and ADR-0007 both use [API] with incompatible assumptions\n```\n\n---\n\n### Engine Specialist Consultation\n\nAfter completing the engine audit above, spawn the **primary engine specialist** via `Agent` for a domain-expert second opinion:\n- Resolve the primary specialist: `-specialist` derived from `engine.name` in `project.yaml` (Godot→`godot-specialist`, Unity→`unity-specialist`, Unreal→`unreal-specialist`); if `engine.name` is absent or empty, read the Primary line of the `## Engine Specialists` section in `.claude/docs/technical-preferences.md`\n- If no engine is configured (neither source yields an engine), skip this consultation **Record ``Engine validation: NOT ASSESSED — no engine configured (`engine.name` unset in `project.yaml`)`` in this run's output.** A skipped check that says nothing is indistinguishable from a check that passed; the reader cannot tell engine guidance was never sought.\n- Spawn `subagent_type: [primary specialist]` with: all ADRs that contain engine-specific decisions or `Post-Cutoff APIs Used` fields, the engine reference docs, and the Phase 5 audit findings. Ask them to:\n 1. Confirm or challenge each audit finding — specialists may know of engine nuances not captured in the reference docs\n 2. Identify engine-specific anti-patterns in the ADRs that the audit may have missed (e.g., using the wrong Godot node type, Unity component coupling, Unreal subsystem misuse)\n 3. Flag ADRs that make assumptions about engine behaviour that differ from the actual pinned version\n\nIncorporate additional findings under `### Engine Specialist Findings` in the Phase 5 output. These feed into the final verdict — specialist-identified issues carry the same weight as audit-identified issues.\n\n---\n\n## Phase 5b: Design Revision Flags (Architecture → GDD Feedback)\n\nFor each **HIGH RISK engine finding** from Phase 5, check whether any GDD makes an\nassumption that the verified engine reality contradicts.\n\nSpecific cases to check:\n\n1. **Post-cutoff API behaviour differs from training-data assumptions**: If an ADR\n records a verified API behaviour that differs from the default LLM assumption,\n check all GDDs that reference the related system. Look for design rules written\n around the old (assumed) behaviour.\n\n2. **Known engine limitations in ADRs**: If an ADR records a known engine limitation\n (e.g. \"Jolt ignores HingeJoint3D damp\", \"D3D12 is now the default backend\"), check\n GDDs that design mechanics around the affected feature.\n\n3. **Deprecated API conflicts**: If Phase 5 flagged a deprecated API used in an ADR,\n check whether any GDD contains mechanics that assume the deprecated API's behaviour.\n\nFor each conflict found, record it in the GDD Revision Flags table:\n\n```\n### GDD Revision Flags (Architecture → Design Feedback)\nThese GDD assumptions conflict with verified engine behaviour or accepted ADRs.\nThe GDD should be revised before its system enters implementation.\n\n| GDD | Assumption | Reality (from ADR/engine-reference) | Action |\n|-----|-----------|--------------------------------------|--------|\n| combat.md | \"Use HingeJoint3D damp for weapon recoil\" | Jolt ignores damp — ADR-0003 | Revise GDD |\n```\n\nIf no revision flags are found, write: \"No GDD revision flags — all GDD assumptions\nare consistent with verified engine behaviour.\"\n\nBefore asking, display the proposed change inline — show the current systems-index row for each flagged GDD and the proposed updated row side by side so the user can see exactly what will change.\n\nThen use `AskUserQuestion`:\n- \"I found [N] GDD revision flag(s). May I update the systems index?\"\n - [A] Yes — apply all [N] updates to the systems index now\n - [B] Show me the full diff first, then ask again\n - [C] No — leave the systems index unchanged for now\n\nIf [A]: apply the updates. Status field must be exactly `Needs Revision` — no parentheticals\n(other skills match that exact string and parentheticals break the match).\nIf [B]: display the complete proposed systems-index section, then re-ask with `AskUserQuestion`.\n\n---\n",".claude/skills/architecture-review/references/6-document-coverage.md":"# /architecture-review — Phase 6: Architecture Document Coverage\n\n> Part of `/architecture-review`. `SKILL.md` names when to read this file; the settings it\n> resolved and the rules under its later headings still apply here.\n\n## Phase 6: Architecture Document Coverage\n\n**If `docs/architecture/architecture.md` does not exist, say so in the report** —\n`Architecture document coverage: NOT ASSESSED — no docs/architecture/architecture.md`\n— and carry it into the Phase 7 verdict per the trigger list below. Silently\nproducing no Phase 6 findings reads as an architecture document that was checked\nand found clean, which is the opposite of what happened.\n\nIf it exists, validate it against GDDs:\n\n- Does every system from `systems-index.md` appear in the architecture layers?\n- Does the data flow section cover all cross-system communication defined in GDDs?\n- Do the API boundaries support all integration requirements from GDDs?\n- Are there systems in the architecture doc that have no corresponding GDD\n (orphaned architecture)?\n\n---\n",".claude/skills/architecture-review/references/7-report.md":"# /architecture-review — Phase 7: Output the Review Report\n\n> Part of `/architecture-review`. `SKILL.md` names when to read this file; the settings it\n> resolved and the rules under its later headings still apply here.\n\n## Phase 7: Output the Review Report\n\n```\n## Architecture Review Report\nDate: [date]\nMode: [full / coverage / consistency / engine / single-gdd path/to/gdd.md]\nWorkflow: [the resolved workflow tier]\nEngine: [name + version, or \"none configured\"]\nGDDs Reviewed: [N]\nADRs Reviewed: [M]\n\n[the receipt — one Reviewed-Content-Hash line per review input, taken in\n Phase 8 when the report is written, never in this draft. Phase 1a's freshness\n check reads them, with the Mode and Workflow lines, on the next run]\n\n---\n\n### Traceability Summary\nTotal requirements: [N]\n✅ Covered: [X]\n⚠️ Partial: [Y]\n❌ Gaps: [Z]\n\n### Coverage Gaps (no ADR exists)\nFor each gap:\n ❌ TR-[id]: [GDD] → [system] → [requirement]\n Suggested ADR: \"/architecture-decision [suggested title]\"\n Domain: [Physics/Rendering/etc]\n Engine Risk: [LOW/MEDIUM/HIGH]\n\n### Cross-ADR Conflicts\n[List all conflicts from Phase 4]\n\n### ADR Dependency Order\n[Topologically sorted implementation order from Phase 4 — dependency ordering section]\n[Unresolved dependencies and cycles if any]\n\n### GDD Revision Flags\n[GDD assumptions that conflict with verified engine behaviour — from Phase 5b]\n[Or: \"None — all GDD assumptions consistent with verified engine behaviour\"]\n\n### Engine Compatibility Issues\n[List all engine issues from Phase 5]\n\n### Architecture Document Coverage\n[List missing systems and orphaned architecture from Phase 6]\n\n---\n\n### Verdict: [PASS / NOT ASSESSED / CONCERNS / FAIL]\n\nPASS: All requirements covered by **Accepted** ADRs, no conflicts, engine consistent\nNOT ASSESSED: The review could not be performed over its stated scope — name why\nCONCERNS: Some gaps, partial coverage, or coverage resting on `Proposed` ADRs,\n but no blocking conflicts\nFAIL: Critical gaps (Foundation/Core layer requirements uncovered),\n or blocking cross-ADR conflicts detected\n\n**`NOT ASSESSED` ranks above PASS and below CONCERNS and FAIL.** Emit it when:\n\n- **No ADRs exist, or none could be read.** Zero requirements traced is not full\n coverage — it is an untraced architecture, and a matrix of `❌ Gap` rows at\n least says so while an empty matrix says nothing.\n- **The requirement source is missing** — no `tr-registry.yaml` and no GDD\n requirements to trace *from*. A review with no left-hand column cannot report\n coverage; it can only report that it had nothing to compare.\n- **An ADR is unreadable or has no `## Status`**, so its rows are `❓` and their\n coverage is unknown rather than absent.\n- **Phase 6 could not run** — no `docs/architecture/architecture.md`. It must\n appear as a named `NOT ASSESSED` **line item** in the report rather than as\n absent findings. ADR traceability can still be complete, so a CONCERNS or FAIL\n finding elsewhere still stands; but in `full` mode, whose scope includes\n Phase 6, the verdict cannot be PASS — a review that could not look at part of\n its scope has not shown that part is sound, so it is NOT ASSESSED.\n- **No engine is configured** (`full` and `engine` modes) — Phase 5 has no pinned\n engine reference to audit the ADRs against, and the specialist consultation was\n skipped. Record the `Engine validation: NOT ASSESSED` line item; like Phase 6\n above, it keeps the verdict from PASS.\n\nDo not resolve any of these to PASS on the grounds that no gap was *found*. No\ngap was looked for.\n\n### Blocking Issues (must resolve before PASS)\n[List items that must be resolved — FAIL verdict only]\n\n### Required ADRs\n[Prioritised list of ADRs to create, most foundational first]\n```\n\n---\n",".claude/skills/architecture-review/references/8-write.md":"# /architecture-review — Phase 8: Write and Update Traceability Index\n\n> Part of `/architecture-review`. `SKILL.md` names when to read this file; the settings it\n> resolved and the rules under its later headings still apply here.\n\n## Phase 8: Write and Update Traceability Index\n\n**In this file:**\n\n- The receipt is taken last\n- RTM Output (rtm mode only)\n- TR Registry Update\n- Reflexion Log Update\n- Session State Update\n\nUse `AskUserQuestion` for the write approval:\n- \"Review complete. What would you like to write?\"\n - [A] Write all three files — review report (`docs/architecture/architecture-review-[date].md`), traceability index (`docs/architecture/requirements-traceability.md`), TR registry (`docs/architecture/tr-registry.yaml`)\n - [B] Write review report only — `docs/architecture/architecture-review-[date].md`\n - [C] Don't write anything yet — I need to review the findings first\n\n**A `single-gdd` run saw one system**, so in that mode [A] writes the review\nreport and only that system's share of the other two files. Name it so in the\noption: \"…update [system]'s rows in the traceability index and its TR registry\nentries\". In `requirements-traceability.md`, replace that system's matrix rows\nand recompute the Coverage Summary, keeping every other system's rows as they\nare. When the index does not exist yet, write the report and the registry only,\nand say a full review creates the index. In the TR registry, append, update and\ndeprecate only that system's entries: another system's GDD was not read, so its\nentries are never proposed for deprecation.\n\nWhen Phase 4 found a 🔴 conflict and `docs/consistency-failures.md` exists, name\nthat file in option [A] as well — \"…and append [N] conflict entr(y/ies) to\n`docs/consistency-failures.md`\". Only [A] appends there (see Reflexion Log\nUpdate); [B] writes the report and nothing else.\n\n### The receipt is taken last\n\nWrite the review report after the TR registry update and the\n`consistency-failures.md` entries, and take its receipt lines at that moment —\nnever from the Phase 7 draft. Both files are review inputs: a receipt taken\nbefore this run edited them records the old content, and the next run reads\nthis run's own edit as `CHANGED`.\n\n```\nBash: bash .claude/scripts/review-receipts.sh hash docs/architecture/adr-*.md design/gdd/*.md docs/architecture/tr-registry.yaml docs/architecture/architecture.md docs/engine-reference/[engine]/*.md docs/engine-reference/[engine]/modules/*.md project.yaml .claude/docs/technical-preferences.md docs/consistency-failures.md .claude/skills/architecture-review/SKILL.md .claude/skills/architecture-review/references/*.md\n```\n\nIt is the same list as Phase 1a's check, with `[engine]` filled in the same way.\nAn optional input that does not exist prints `not stamped, no such file` and is\nleft out; that is expected. Paste the stamp lines into the report under its\nheader, where the Phase 7 template shows them.\n\n### RTM Output (rtm mode only)\n\nFor `rtm` mode, use `AskUserQuestion`:\n- \"May I write the full Requirements Traceability Matrix?\"\n - [A] Yes — write to `docs/architecture/requirements-traceability.md`\n - [B] Not yet — show me the full RTM data first, then ask again\n\nRTM file format:\n\n```markdown\n# Requirements Traceability Matrix (RTM)\n\n> Last Updated: [date]\n> Mode: /architecture-review rtm\n> Coverage: [N]% full chain complete (GDD → ADR → Story → Test)\n\n## How to read this matrix\n\n| Column | Meaning |\n|--------|---------|\n| TR-ID | Stable requirement ID from tr-registry.yaml |\n| GDD | Source design document |\n| ADR | Architectural decision governing implementation |\n| Story | Story file that implements this requirement |\n| Test File | Automated test file path |\n| Test Status | COVERED / MISSING / NONE / NO STORY |\n\n## Full Traceability Matrix\n\n| TR-ID | GDD | Requirement | ADR | Story | Test File | Status |\n|-------|-----|-------------|-----|-------|-----------|--------|\n[Full matrix rows from Phase 3b]\n\n## Coverage Summary\n\n| Status | Count | % |\n|--------|-------|---|\n| COVERED — full chain complete | [N] | [%] |\n| MISSING test — story exists, no test | [N] | [%] |\n| NO STORY — ADR exists, not yet implemented | [N] | [%] |\n| NO ADR — architectural gap | [N] | [%] |\n| **Total requirements** | **[N]** | **100%** |\n\n## Uncovered Requirements (Priority Fix List)\n\nRequirements where the full chain is broken, prioritised by layer:\n\n### Foundation layer gaps\n[list with suggested action per gap]\n\n### Core layer gaps\n[list]\n\n### Feature / Presentation layer gaps\n[list — lower priority]\n\n## History\n\n| Date | Full Chain % | Notes |\n|------|-------------|-------|\n| [date] | [%] | Initial RTM |\n```\n\n### TR Registry Update\n\nAlso ask: \"May I update `docs/architecture/tr-registry.yaml` with new requirement\nIDs from this review?\"\n\nIf yes, read the current `docs/architecture/tr-registry.yaml` again first:\nthe review read it at the start, and another skill or session may have changed\nit since. Build the update from that fresh read, never from the earlier copy,\nand keep every entry already in it. Then:\n- **Append** any new TR-IDs that weren't in the registry before this review\n- **Update** `requirement` text and `revised` date for any entries whose GDD\n wording changed (ID stays the same)\n- **Mark** `status: deprecated` for any registry entries whose GDD requirement\n no longer exists (confirm with user before marking deprecated; in `single-gdd`\n mode, only the reviewed system's entries)\n- **Mark** `status: \"superseded-by: TR-[system]-NNN\"` for an entry whose\n requirement was split or replaced, naming the new TR-ID(s). Keep the quotes:\n unquoted, the second colon makes the file invalid YAML\n- **Never** renumber or delete existing entries\n- Update the `last_updated` and `version` fields at the top\n\nAfter writing, run `bash .claude/scripts/registry.sh validate` and fix every row\nabout an entry this write added or changed (a DUPLICATE, STATUS or LAYOUT row,\nor a PATH_MISSING row for a path it named) before you go on; name rows about\nother entries to the user rather than fixing them unasked. If the script is\nmissing or prints nothing, say the registry check did not run, then re-read the\nentries you wrote against the rules in the file's header.\n\nThis ensures all future story files can reference stable TR-IDs that persist\nacross every subsequent architecture review.\n\n### Reflexion Log Update\n\nWhen the user chose Phase 8's [A] — the option that named this file — append\nany 🔴 CONFLICT entries found in Phase 4 to `docs/consistency-failures.md` (if\nthe file exists), before writing the review report (its receipt is taken last):\n\n```markdown\n### [YYYY-MM-DD] — /architecture-review — 🔴 CONFLICT\n**Domain**: Architecture / [specific domain e.g. State Ownership, Performance]\n**Documents involved**: [ADR-NNNN] vs [ADR-MMMM]\n**What happened**: [specific conflict — what each ADR claims]\n**Resolution**: [how it was or should be resolved]\n**Pattern**: [generalised lesson for future ADR authors in this domain]\n```\n\nOnly append CONFLICT entries — do not log GAP entries (missing ADRs are expected\nbefore the architecture is complete). Do not create the file if missing — only\nappend when it already exists.\n\n### Session State Update\n\nAfter writing all approved files, silently append to\n`production/session-state/active.md`:\n\n ## Session Extract — /architecture-review [date]\n - Verdict: [PASS / NOT ASSESSED / CONCERNS / FAIL]\n - Requirements: [N] total — [X] covered, [Y] partial, [Z] gaps\n - New TR-IDs registered: [N, or \"None\"]\n - GDD revision flags: [comma-separated GDD names, or \"None\"]\n - Top ADR gaps: [top 3 gap titles from the report, or \"None\"]\n - Report: docs/architecture/architecture-review-[date].md\n\nIf `active.md` does not exist, create it with this block as the initial content.\nConfirm in conversation: \"Session state updated.\"\n\nThe traceability index — written to `docs/architecture/requirements-traceability.md`,\nthe path `/propagate-design-change` and the Pre-Production gate read; `rtm` mode\nlater extends the same file with story and test columns — uses this format:\n\n```markdown\n# Architecture Traceability Index\nLast Updated: [date]\nEngine: [name + version]\n\n## Coverage Summary\n- Total requirements: [N]\n- Covered: [X] ([%])\n- Partial: [Y]\n- Gaps: [Z]\n\n## Full Matrix\n[Complete traceability matrix from Phase 3]\n\n## Known Gaps\n[All ❌ items with suggested ADRs]\n\n## Superseded Requirements\n[Requirements whose GDD was changed after the ADR was written]\n```\n\n---\n",".claude/skills/architecture-review/references/9-handoff.md":"# /architecture-review — Phase 9: Handoff\n\n> Part of `/architecture-review`. `SKILL.md` names when to read this file; the settings it\n> resolved and the rules under its later headings still apply here.\n\n## Phase 9: Handoff\n\nAfter completing the review and writing approved files, present:\n\n1. **Immediate actions**: List the top 3 ADRs to create (highest-impact gaps first,\n Foundation layer before Feature layer)\n2. **Pre-gate checklist**: Check whether these exist via Glob and mark each ✅ or ❌:\n - the engine's test root — `tests/unit/` and `tests/integration/` (Godot), `Assets/Tests/EditMode/` and `Assets/Tests/PlayMode/` (Unity), `Source//Private/Tests/` (Unreal) — if ❌: run `/test-setup`\n - `.github/workflows/tests.yml` — if ❌: run `/test-setup`\n - `design/accessibility-requirements.md` — if ❌: run `/ux-design`\n - `design/ux/interaction-patterns.md` — if ❌: run `/ux-design`\n Present ❌ items as required steps before gate-check. Do not offer `/gate-check`\n as an option if any item is ❌ — offer the missing skill to run instead.\n3. **Rerun trigger**: \"Re-run `/architecture-review` after each new ADR is written\n to verify coverage improves\"\n\nThen close with `AskUserQuestion` tailored to the pre-gate checklist state:\n- If ADR gaps remain or any pre-gate item is ❌:\n - \"Architecture review complete. What would you like to do next?\"\n - [A] Write a missing ADR — open a fresh session and run `/architecture-decision [system]`\n - [B] Run `/test-setup` — required before gate-check (only show if test infrastructure is ❌)\n - [C] Run `/ux-design` — required before gate-check (only show if UX/accessibility files are ❌)\n - [D] Stop here for this session\n- If all pre-gate checklist items are ✅ and no blocking ADR gaps remain:\n - \"Architecture review complete. All pre-gate items confirmed. What would you like to do next?\"\n - [A] Run `/gate-check pre-production`\n - [B] Write a missing ADR — open a fresh session and run `/architecture-decision [system]`\n - [C] Stop here for this session\n\n---\n",".claude/skills/art-bible/SKILL.md":"---\nname: art-bible\ndescription: \"Author the Art Bible — visual identity gating asset production. Run before /map-systems.\"\nargument-hint: \"[--review full|lean|solo]\"\nuser-invocable: true\nallowed-tools: Read, Glob, Grep, Write, Edit, Agent, AskUserQuestion, Bash(bash \"*/.claude/skills/art-bible/../../hooks/yaml-helper.sh\" resolve_config *)\nmodel: sonnet\n---\n\n!`bash \"${CLAUDE_SKILL_DIR}/../../hooks/yaml-helper.sh\" resolve_config --keys review_mode,automation,workflow,docs.density`\n\nResolved above — use as-is; `--review` overrides `review_mode`. No block →\ndefaults in `.claude/docs/config-resolution.md`.\n\n# Art Bible\n\n\n## Phase 0: Parse Arguments and Context Check\n\n\nSee `.claude/docs/director-gates.md` for the full check pattern. Individual gate definitions live in `.claude/docs/director-gates/[gate-id].md` — the spawned agent reads its own gate file; do not read it in the parent session.\n\n\nEvery `AskUserQuestion` call follows `.claude/docs/automation-modes.md`\n(collaborative asks always · guided major-only · autonomous logs and proceeds;\n`automation_always_ask` categories always prompt).\n\n**`docs.density`** — it controls per-section *depth*, where `workflow`\ncontrols which sections exist. `modes.rigor` sets both together; set\n`docs.density` explicitly to vary depth alone: `terse` (the default, via `rigor: minimal`) = each section a bulleted list of\nconstraints + references; `balanced` = paragraphs explaining each visual choice\n(`rigor: standard`); `thorough` = full prose including style explorations, references, and\nrationale per choice. Apply it to every section you author.\n\n**`workflow`** (see `.claude/docs/workflow-modes.md`):\n- `full` — all 9 art bible sections required.\n- `standard` — required only if visual asset stories exist in the project;\n sections 1–4 are the minimum when required. `workflow_overrides.art_bible_strict:\n true` forces all 9 sections regardless of tier.\n- `minimal` — not required. Can still be run voluntarily.\n\nRead `design/gdd/game-concept.md` — or `design/game-brief.md`, the one-page brief\nthat replaces it at `rigor: minimal`. Read it by section: find the headings you need\nwith the Grep tool (pattern `^#`, content mode) and Read those ranges with offset\nand limit. If neither exists, fail with:\n> \"No game concept found. Run `/brainstorm` first — the art bible is authored after the game concept is approved.\"\n\nExtract from game-concept.md (from the brief: working title, pitch, \"Who it's for /\nwhat they feel\" line and \"Art & audio direction\" line — it has no pillars, Visual\nIdentity Anchor or platform):\n- Game title (working title)\n- Core fantasy and elevator pitch\n- Game pillars (all of them)\n- **Visual Identity Anchor** section if present (from brainstorm Phase 4 art-director output)\n- Target platform (if noted)\n\n**Retrofit mode detection**: Glob `design/art/art-bible.md`. If the file exists,\nbuild the status table **without reading the document** — you are about to author\nonly the *incomplete* sections, so loading the complete ones is loading exactly\nwhat you will not touch:\n\n```\nGrep pattern=\"^## \" path=\"design/art/art-bible.md\" output_mode=\"content\" -n\nGrep pattern=\"\\[To be designed\\]|\\[TBD\\]|\\[To be written\\]|^_?TODO\" path=\"design/art/art-bible.md\" output_mode=\"content\" -n\n```\n\n- The first grep gives the section headings and their line numbers — the gap\n between consecutive headings is that section's size.\n- The second gives placeholder markers and where they fall.\n- A section is **Complete** if it has substantive distance to the next heading and\n no placeholder marker inside it; **Placeholder** if a marker falls in its range;\n **Empty** if consecutive headings sit adjacent.\n- Where the two greps leave a section genuinely ambiguous, read *that section's*\n line range with `Read(offset, limit)` — never the whole file.\n- Build a section status table:\n\n```\nSection | Status\n--------|--------\n1. Visual Identity Statement | [Complete / Empty / Placeholder]\n2. Mood & Atmosphere | ...\n3. Shape Language | ...\n4. Color System | ...\n5. Character Design Direction | ...\n6. Environment Design Language | ...\n7. UI/HUD Visual Direction | ...\n8. Asset Standards | ...\n9. Reference Direction | ...\n```\n\n- Present this table to the user:\n > \"Found existing art bible at `design/art/art-bible.md`. [N] sections are complete, [M] need content. I'll work on the incomplete sections only — existing content will not be touched.\"\n- Only work on sections with Status: Empty or Placeholder. Do not re-author sections that are already complete.\n\nIf the file does not exist, this is a fresh authoring session. The first\napproved section creates the file from `.claude/docs/templates/art-bible.md`,\nwhose nine `## N. Name` headings are the ones retrofit mode reads — ask first:\n\"May I create `design/art/art-bible.md` from the art bible template?\" Each\napproved section then replaces its own `[To be designed]` line with `Edit`;\nkeep the headings as the template has them.\n\n**A section's approval names its write.** Every section is approved through an\n`AskUserQuestion` whose approving option is `[A] Lock this in and write it to\ndesign/art/art-bible.md` (Section 1's full option list is below). Choosing it is\nthe approval to write that section; no section is written without it, fresh or\nretrofit.\n\nExtract performance budgets and the engine for asset standard constraints: read `performance.*` and `engine.name` from `project.yaml`; for any key absent or empty (including when `project.yaml` has no `performance` or `engine` block), fall back to `.claude/docs/technical-preferences.md`.\n\n---\n\n## Phase 1: Framing\n\nPresent the session context and ask two questions before authoring anything:\n\nUse `AskUserQuestion` with two tabs:\n- Tab **\"Scope\"** — \"Which sections need to be authored today?\"\n Options: `Full bible — all 9 sections` / `Visual identity core (sections 1–4 only)` / `Asset standards only (section 8)` / `Resume — fill in missing sections`\n\n **Mark the option the resolved `workflow` tier actually requires as\n (Recommended), and say why** — the tier already decides this and the user\n should not have to know the tier table to answer:\n - `full` → **Full bible** — all 9 sections are required at this tier.\n - `standard` → **Visual identity core (sections 1–4 only)** — that is the\n documented minimum when an art bible is required at all. Say: \"Sections 1–4\n are what `standard` requires; 5–9 are available if you want them.\"\n - `minimal` → no art bible is required. Say so before asking, and offer\n sections 1–4 as the useful-if-you-want-it option rather than defaulting to 9.\n - `workflow_overrides.art_bible_strict: true` → **Full bible** regardless of tier.\n\n This is the single biggest cost lever in this skill: every authored section\n carries a specialist spawn, so authoring 9 sections where the tier requires 4\n more than doubles the run for artifacts nothing downstream will check.\n- Tab **\"References\"** — \"Do you have reference games, films, or art that define the visual direction?\"\n (Free text — let the user type specific titles. Do NOT preset options here.)\n\nIf the game-concept.md has a Visual Identity Anchor section, note it:\n> \"Found a visual identity anchor from brainstorm: '[anchor name] — [one-line rule]'. I'll use this as the foundation for the art bible.\"\n\n**Author only the sections in the chosen scope.** Phases 2–4 run only the\nsections inside it — for `Resume`, the Empty and Placeholder rows of the\nretrofit table — and skip every other section, and any phase left with none.\nPhase 6 names each section not authored this run and why.\n\n---\n\n## Phase 2: Visual Identity Foundation (Sections 1–4)\n\nThese four sections define the core visual language. **All other sections flow from them.** Author and write each to file before moving to the next.\n\n> **Spawn policy for this phase.** Section 1 is delegated on its own — it is\n> foundational and the user chooses between anchor directions before anything\n> else can build on it. Sections 2–4 are then delegated in **one** `art-director`\n> call, not three: they are the same agent receiving the same inputs (Visual\n> Identity Statement + pillars), and mood, shape and colour are interdependent —\n> an art director defines them together, not in isolation. Separate calls would\n> ask the agent to reason about colour without knowing the shape language it\n> had just written.\n>\n> **This is not reduced specialist involvement** — every section is still\n> authored by the specialist, which is the point `.claude/docs/effects-map.md`\n> makes about art-bible delegation being mandatory. It is one call instead of\n> three for the same three sections. Per-section user approval and\n> write-to-file-immediately are unchanged.\n\n### Section 1: Visual Identity Statement\n\n**Goal**: A one-line visual rule plus 2–3 supporting principles that resolve visual ambiguity.\n\nIf a visual anchor exists from game-concept.md: present it and ask:\n- \"Build directly from this anchor?\"\n- \"Revise it before expanding?\"\n- \"Start fresh with new options?\"\n\n**Agent delegation (MANDATORY)**: Spawn `art-director` via `Agent`:\n- Provide: game concept (elevator pitch, core fantasy), full pillar set, platform target, any reference games/art from Phase 1 framing, the visual anchor if it exists\n- Ask: \"Draft a Visual Identity Statement for this game. Provide: (1) a one-line visual rule that could resolve any visual decision ambiguity, (2) 2–3 supporting visual principles, each with a one-sentence design test ('when X is ambiguous, this principle says choose Y'). Anchor all principles directly in the stated pillars — each principle must serve a specific pillar. (From a one-page brief, which has no pillars, anchor them in its pitch and \"what they feel\" line.)\"\n\nPresent the art-director's draft to the user. Use `AskUserQuestion`:\n- Options: `[A] Lock this in and write it to design/art/art-bible.md` / `[B] Revise the one-liner` / `[C] Revise a supporting principle` / `[D] Describe my own direction`\n\nWrite the approved section to file immediately.\n\n### Section 2: Mood & Atmosphere\n\n**Goal**: Emotional targets by game state — specific enough for a lighting artist to work from.\n\nFor each major game state (e.g., exploration, combat, victory, defeat, menus — adapt to this game's states), define:\n- Primary emotion/mood target\n- Lighting character (time of day, color temperature, contrast level)\n- Atmospheric descriptors (3–5 adjectives)\n- Energy level (frenetic / measured / contemplative / etc.)\n\n**Agent delegation for Sections 2–4 — one call, issued here.** Spawn\n`art-director` via `Agent` with the locked Visual Identity Statement and pillar set,\nand ask for all three sections in a single brief:\n\n1. **Mood & atmosphere** — \"Define mood and atmosphere targets for each major game state in this game. Be specific — 'dark and foreboding' is not enough. Name the exact emotional target, the lighting character (warm/cool, high/low contrast, time of day direction), and at least one visual element that carries the mood. Each game state must feel visually distinct from the others.\"\n2. **Shape language** — \"Define the shape language for this game. Connect each shape principle back to the visual identity statement and a specific game pillar. Explain what these shape choices communicate to the player emotionally.\"\n3. **Colour system** — \"Design the color system for this game. Every semantic color assignment must be explained — why does this color mean danger/safety/reward in this world? Identify which color pairs might fail colorblind players and specify what backup cues are needed.\"\n\nRequire the three to be **mutually consistent** — the palette must serve the mood\ntargets and the shape hierarchy — and returned as three separately labelled\nblocks so each can be approved and written on its own.\n\nThen present **Section 2** to the user, approve it, and write it to file\nimmediately before moving to Section 3. Do not present all three at once: the\nbatching is in the delegation, not in the review.\n\n### Section 3: Shape Language\n\n**Goal**: The geometric vocabulary that makes this game's world visually coherent and distinguishable.\n\nCover:\n- Character silhouette philosophy (how readable at thumbnail size? Distinguishing trait per archetype?)\n- Environment geometry (angular/curved/organic/geometric — which dominates and why?)\n- UI shape grammar (does UI echo the world aesthetic, or is it a distinct HUD language?)\n- Hero shapes vs. supporting shapes (what draws the eye, what recedes?)\n\n**Draft source**: the Sections 2–4 delegation issued under Section 2 — use the\nshape-language block it returned. Do not spawn again.\n\nWrite the approved section to file immediately.\n\n### Section 4: Color System\n\n**Goal**: A complete, producible palette system that serves both aesthetic and communication needs.\n\nCover:\n- Primary palette (5–7 colors with roles — not just hex codes, but what each color means in this world)\n- Semantic color usage (what does red communicate? Gold? Blue? White? Establish the color vocabulary)\n- Per-biome or per-area color temperature rules (if the game has distinct areas)\n- UI palette (may differ from world palette — define the divergence explicitly)\n- Colorblind safety: which semantic colors need shape/icon/sound backup\n\n**Draft source**: the Sections 2–4 delegation issued under Section 2 — use the\ncolour-system block it returned. Do not spawn again.\n\nWrite the approved section to file immediately.\n\n---\n\n## Phase 3: Production Guides (Sections 5–8)\n\nThese sections translate the visual identity into concrete production rules. They should be specific enough that an outsourcing team can follow them without additional briefing.\n\n### Section 5: Character Design Direction\n\n**Agent delegation for Sections 5–6 — one call, issued here.** Both sections\nneed the **same agent with the same input** (`sections 1–4`), so a second call\nwould only re-send the whole visual identity. Spawn `art-director` once with\nsections 1–4 and ask for both:\n\n1. **Character design direction** — \"Cover: visual archetype for the player character (if any), distinguishing feature rules per character type (how do players tell enemies/NPCs/allies apart at a glance?), expression/pose style targets (stiff/expressive/realistic/exaggerated), and LOD philosophy (how much detail is preserved at game camera distance?).\"\n2. **Environment design language** — \"Cover: architectural style and its relationship to the world's culture/history, texture philosophy (painted vs. PBR vs. stylized — why this choice for this game?), prop density rules (sparse/dense — what drives the choice per area type?), and environmental storytelling guidelines (what visual details should tell the story without text?).\"\n\nRequire characters and environments to be **legible against each other** — a\ncharacter silhouette must read against the environment texture density the same\nbrief defines. Return two separately labelled blocks.\n\nPresent **Section 5** first, approve, write to file, then Section 6.\n\n### Section 6: Environment Design Language\n\n**Draft source**: the Sections 5–6 delegation issued under Section 5 — use the\nenvironment block it returned. Do not spawn again.\n\nWrite the approved section to file.\n\n### Section 7: UI/HUD Visual Direction\n\n**Agent delegation**: Spawn in parallel:\n- **`art-director`**: Visual style for UI — diegetic vs. screen-space HUD, typography direction (font personality, weight, size hierarchy), iconography style (flat/outlined/illustrated/photorealistic), animation feel for UI elements\n- **`ux-designer`**: UX alignment check — does the visual direction support the interaction patterns this game requires? Flag any conflicts between art direction and readability/accessibility needs.\n\nCollect both. If they conflict (e.g., art-director wants elaborate diegetic UI but ux-designer flags it would reduce combat readability), surface the conflict explicitly with both positions. Do NOT silently resolve — use `AskUserQuestion` to let the user decide.\n\nWrite the approved section to file.\n\n### Section 8: Asset Standards\n\n**Agent delegation**: Spawn in parallel:\n- **`art-director`**: File format preferences, naming convention direction, texture resolution tiers, LOD level expectations, export settings philosophy\n- **`technical-artist`**: Engine-specific hard constraints — poly count budgets per asset category, texture memory limits, material slot counts, importer constraints, anything from the performance budgets (`performance.*` in `project.yaml`, falling back to `.claude/docs/technical-preferences.md`)\n\nIf any art preference conflicts with a technical constraint (e.g., art-director wants 4K textures but performance budget requires 2K for mobile), surface the conflict explicitly with both positions — the ideal and the constrained standard, and the tradeoff. Do NOT silently resolve it — use `AskUserQuestion` to let the user pick (options: the ideal standard, the constrained standard, or document both and let per-asset judgment apply). Ambiguity in asset standards is where production costs are born.\n\nWrite the approved section to file.\n\n---\n\n## Phase 4: Reference Direction (Section 9)\n\n**Goal**: A curated reference set that is specific about what to take and what to avoid from each source.\n\n**Agent delegation**: Spawn `art-director` via `Agent` with the completed sections 1–8. Ask: \"Compile a reference direction for this game. Provide 3–5 reference sources (games, films, art styles, or specific artists). For each: name it, specify exactly what visual element to draw from it (not 'the general aesthetic' — a specific technique, color choice, or compositional rule), and specify what to explicitly avoid or diverge from (to prevent the 'trying to copy X' reading). References should be additive — no two references should be pointing in exactly the same direction.\"\n\nWrite the approved section to file.\n\n---\n\n## Phase 5: Art Director Sign-Off\n\n**Review mode check** — apply before spawning AD-ART-BIBLE:\n- `solo` → skip. Note: \"AD-ART-BIBLE skipped — Solo mode.\" Then record the skip\n (below) and proceed to Phase 6.\n- `lean` → skip (not a PHASE-GATE). Note: \"AD-ART-BIBLE skipped — Lean mode.\"\n Then record the skip (below) and proceed to Phase 6.\n- `full` → spawn as normal.\n\nOn either skip, ask \"May I record the skipped sign-off in\n`design/art/art-bible.md`'s header?\" and, on yes, replace the header's\n`> **Art Director Sign-Off (AD-ART-BIBLE)**: [Not yet reviewed]` with\n`> **Art Director Sign-Off (AD-ART-BIBLE)**: SKIPPED [date] — [solo|lean] mode`\n— the gate accepts either form as a recorded sign-off.\n\nAfter all sections are complete (or the scoped set from Phase 1 is complete), spawn `art-director` via `Agent` using gate **AD-ART-BIBLE** (`.claude/docs/director-gates/ad-art-bible.md`).\n\nPass: the art bible path (`design/art/art-bible.md`); the game pillars and core\nfantasy; the platform and performance constraints (`platform.*` and\n`performance.*` from `project.yaml`, falling back to\n`.claude/docs/technical-preferences.md`); and the visual identity anchor. When\nPhase 0 read the one-page brief, pass its pitch and \"what they feel\" line as the\npillars and fantasy, and its \"Art & audio direction\" line as the anchor.\n\nHandle verdict per standard rules in `director-gates.md`.\nOn `Revise flagged items`, or to resolve a REJECT, the section's own specialist\n— `art-director`, with `ux-designer` for Section 7 and `technical-artist` for\nSection 8 — re-drafts each flagged section, which is then presented, approved\nand written like any other section before `REVISED [date]` is recorded.\nA `NOT ASSESSED` answer is never an approval: name the missing input, then\nsupply it and re-run the gate, or record `NOT ASSESSED`.\nRecord the verdict in the art bible's status header:\n`> **Art Director Sign-Off (AD-ART-BIBLE)**: APPROVED [date] / CONCERNS (accepted) [date] / REVISED [date] / NOT ASSESSED [date] — [missing input]`\n\n---\n\n## Phase 6: Close\n\nFirst, name each of the nine sections not authored this run and why — outside\nthe chosen scope, or already complete — e.g. *\"Not authored this run: sections\n5–9 (outside the chosen scope; `standard` requires 1–4).\"* A run that stopped\nafter Section 4 must not read like a finished bible.\n\nBefore presenting next steps, check project state:\n- Does `design/gdd/systems-index.md` exist? → map-systems is done, skip that option\n- Is an engine configured — `engine.name` present in `project.yaml`, or a configured Engine field (not `[TO BE CONFIGURED]`) in `.claude/docs/technical-preferences.md`? → setup-engine is done, skip that option\n- Does `design/gdd/` contain any `*.md` files? → design-system has been run, skip that option\n- Does `design/gdd/gdd-cross-review-*.md` exist? → review-all-gdds is done\n- Do GDDs exist (check above)? → include /consistency-check option\n\nUse `AskUserQuestion` for next steps. Only include options that are genuinely next based on the state check above:\n\nAt `workflow: minimal`, the pool is `/create-stories` (no stories yet) or\n`/dev-story [next story]`, plus Stop here — the GDD/architecture pool below is\n`standard`/`full` only.\n\n**Option pool — include only if not already done:**\n- `[_] Run /map-systems — decompose the concept into systems before writing GDDs` (skip if systems-index.md exists)\n- `[_] Run /setup-engine — configure the engine (asset standards may need revisiting after engine is set)` (skip if engine configured)\n- `[_] Run /design-system — start the first GDD` (skip if any GDDs exist)\n- `[_] Run /review-all-gdds — cross-GDD consistency check (required before Technical Setup gate)` (skip if gdd-cross-review-*.md exists)\n- `[_] Run /asset-spec — generate per-asset visual specs and AI generation prompts from approved GDDs` (include if GDDs exist)\n- `[_] Run /consistency-check — scan existing GDDs against the art bible for visual direction conflicts` (include if GDDs exist)\n- `[_] Run /create-architecture — author the master architecture document (next Technical Setup step)`\n- `[_] Stop here`\n\nAssign letters A, B, C… only to the options actually included. Mark the most logical pipeline-advancing option as `(recommended)`.\n\n> **Always include** (`standard`/`full` only) `/create-architecture` and Stop here as options — these are always valid next steps once the art bible is complete.\n\n---\n\n## Collaborative Protocol\n\n**Applies in `collaborative` mode (the default).** For `guided` and\n`autonomous` modes, see `.claude/docs/automation-modes.md` — the rules below\ndescribe what collaborative mode requires, not universal behavior.\n\nEvery section follows: **Question → Options → Decision → Draft (from art-director agent) → Approval → Write to file**\n\n- Never draft a section yourself — every section's content comes from the\n relevant specialist. One delegation may cover several sections (2–4 share a\n call, as do 5–6), but no section may be written from the orchestrator's own\n judgement instead of an agent's.\n- Write each section to file immediately after approval — do not batch **the\n writes or the approvals**. Batching applies only to the delegation call; the\n user still sees, approves and commits one section at a time.\n- Surface all agent disagreements to the user — never silently resolve conflicts between art-director and technical-artist\n- The art bible is a constraint document: it restricts future decisions in exchange for visual coherence. Every section should feel like it narrows the solution space productively.\n\n---\n\n## Recommended Next Steps\n\nAfter the art bible is approved:\n- Run `/map-systems` to decompose the concept into game systems before authoring GDDs\n- Run `/setup-engine` if the engine is not yet configured (asset standards may need revisiting after engine selection)\n- Run `/design-system [first-system]` to start authoring per-system GDDs\n- Run `/consistency-check` once GDDs exist to validate them against the art bible's visual rules\n- Run `/create-architecture` to produce the master architecture document\n",".claude/skills/asset-audit/SKILL.md":"---\nname: asset-audit\ndescription: \"Audit assets against naming conventions, file size budgets, format standards. Finds orphaned assets, missing references.\"\nargument-hint: \"[category|all]\"\nuser-invocable: true\nallowed-tools: Read, Glob, Grep, Bash(stat *), Bash(file *), Bash(od *), Bash(wc *), Bash(du *)\nmodel: sonnet\n# Read-only diagnostic skill — no specialist agent delegation needed\n---\n\n# Asset Audit\n\n## Measuring file sizes and formats requires Bash\n\nThis skill's report asks for **file sizes against budgets**, **texture dimensions**\n(power-of-two), **audio sample rates**, and **last-modified times** for orphan\ndetection. None of those are obtainable from `Read`/`Glob`/`Grep` — they need\n`stat` or a binary header read, so the read-only measuring commands (`stat`,\n`file`, `od`, `wc`, `du`) are pre-approved above; list files with Glob. Anything\nelse asks first.\n\n**If you cannot take a measurement, the cell is `NOT ASSESSED`, never an\nestimate.** A size budget table filled from guesses is worse than an empty one:\nit looks like evidence. This is a live fabrication vector even on a project full\nof real assets: if the template demands tables of numbers the tool allowlist\ncannot produce, the only way to complete it is to invent them.\n\n---\n\n## Insufficient input — check this before producing any report\n\n**If the inputs this skill needs do not exist, the answer is \"could not run\" —\nnot a filled-in report.** Check first, and stop if the check fails.\n\n1. List the inputs this skill reads (data files, prior reports, profiler output,\n test results, registries, source code).\n2. For each, record `FOUND` or `ABSENT` — not \"assumed present\".\n3. If any input required for a section is ABSENT, that section is\n **`NOT ASSESSED — NO DATA`**. Do not estimate it, do not infer it from an\n adjacent artifact, and do not leave a mandated cell to be filled by whoever\n reads the template next.\n4. If **every** required input is ABSENT, stop and report\n **`NOT ASSESSED — NO DATA`** as the whole verdict, naming what was missing and\n which skill produces it.\n\n**A verdict of `NOT ASSESSED` is a success.** It is the correct, useful answer to\n\"what does the data say?\" when there is no data. The failure mode this prevents is\nspecific: a report whose verdict enum has no \"could not run\" state produces\n**false clean passes** — an asset audit returning COMPLIANT on a project with no\nassets and no standards, or a performance profile reporting \">99% headroom against\na 16.67ms budget\" with zero profiler data and no budget ever set.\n\n**Absence of evidence is never evidence of absence.** A scan that finds no\nmatches because there are no files to scan has not verified anything. Say which of\nthe two happened — a reader cannot tell from a green result.\n\n---\n\n## Phase 1: Read Standards\n\nRead the art bible's Asset Standards section (`design/art/art-bible.md`) and any\nasset standards in the relevant design docs — size budgets and format rules come\nfrom there. The naming patterns are the ones in Phase 3 below, unless the art\nbible states its own. Read the art bible by section: find the heading with\nthe Grep tool (pattern `^#`, content mode) and Read that range with offset\nand limit.\n\nIf neither states a size budget — or there is no art bible — the Size section is\n`NOT ASSESSED — no size budget set`, and the report names `/art-bible`, whose\nAsset Standards section sets budgets, formats and the naming convention.\n\n---\n\n## Phase 2: Scan Asset Directories\n\nAssets live under the engine's asset root: `assets/` on Godot, `Assets/` on\nUnity, `Content/` on Unreal. Resolve the engine and its code root per\n`.claude/docs/code-root-resolution.md`; that code root is the one Phase 3's\norphan and missing-asset searches read. If it is unresolved, stop:\n`NOT ASSESSED — engine unresolved`, naming `/setup-engine`.\n\nScan the asset root using Glob:\n\n- **Godot** — `assets/art/**/*`, `assets/audio/**/*`, `assets/vfx/**/*`,\n `assets/shaders/**/*`, `assets/data/**/*`\n- **Unity** — `Assets/**/*`, leaving out scripts (`*.cs`, `*.asmdef`) and `*.meta` files\n- **Unreal** — `Content/**/*.uasset` and `Content/**/*.umap`\n\nThe files matched are `Total assets scanned`. If there are none, the checks on\nscanned files — Naming, Size, Format, Orphaned — are\n`NOT ASSESSED — no assets under `; the missing-asset search still runs.\n\n---\n\n## Phase 3: Run Compliance Checks\n\n**Naming conventions:**\n- Art: `[category]_[name]_[variant]_[size].[ext]`\n- Audio: `[category]_[context]_[name]_[variant].[ext]`\n- All files must be lowercase with underscores\n\nThese are Godot's conventions. Unity and Unreal name assets in PascalCase, so on\nthose engines check names only against a naming rule the art bible states; with\nnone, Naming is `NOT ASSESSED — no naming rule for ` (name `/art-bible`).\n\n**File standards:**\n- Textures: Power-of-two dimensions, correct format (PNG for UI, compressed for 3D), within size budget\n- Audio: Correct sample rate, format (OGG for SFX, OGG/MP3 for music), within duration limits.\n `file` reports an audio file's format and sample rate but not its length, and no\n pre-approved tool here does; a duration budget is therefore\n `NOT ASSESSED — duration not measurable here`, naming the files it covers.\n- Data: Valid JSON/YAML, schema-compliant\n\nOn Unreal an asset file (`.uasset`, `.umap`) does not keep its source file's\nformat or dimensions, so Format is `NOT ASSESSED` there; its size is still measured.\n\n**Orphaned assets:** Search the code root for references to each asset file. Flag any with no references.\n\n**Missing assets:** Search the code root for asset references and verify the files exist.\n\nBoth searches need code: if the code root holds no source files, Orphaned and\nMissing are `NOT ASSESSED — no code to search`. On Unity and Unreal most asset\nreferences live in scenes, prefabs and other assets rather than code, so an\nasset no code names may still be in use: Orphaned is `NOT ASSESSED` there.\n\n---\n\n## Phase 4: Output Audit Report\n\n```markdown\n# Asset Audit Report -- [Category] -- [Date]\n\n## Summary\n- **Total assets scanned**: [N]\n- **Naming violations**: [N]\n- **Size violations**: [N]\n- **Format violations**: [N]\n- **Orphaned assets**: [N]\n- **Missing assets**: [N]\n- **Sections not assessed**: [none | each section and why]\n\n## Naming Violations\n| File | Expected Pattern | Issue |\n|------|-----------------|-------|\n\n## Size Violations\n| File | Budget | Actual | Overage |\n|------|--------|--------|---------|\n\n## Format Violations\n| File | Expected Format | Actual Format |\n|------|----------------|---------------|\n\n## Orphaned Assets (no code references found)\n| File | Last Modified | Size | Recommendation |\n|------|-------------|------|---------------|\n\n## Missing Assets (referenced but not found)\n| Reference Location | Expected Path |\n|-------------------|---------------|\n\n## Recommendations\n[Prioritized list of fixes, one per violation, each naming the change — the\ntarget resolution or compression for a size violation, the corrected name for a\nnaming violation, the target format for a format violation]\n\n## Verdict: [NOT ASSESSED / COMPLIANT / WARNINGS / NON-COMPLIANT]\n```\n\nChoose the verdict by the findings, first match wins:\n- **NON-COMPLIANT** — any size violation, or any asset that code references but that does not exist\n- **WARNINGS** — only naming, format or orphaned-asset findings\n- **NOT ASSESSED** — the audit did not cover its scope: no data at all (the path\n above), zero assets scanned, or any section `NOT ASSESSED` — name which. It\n ranks below the two finding verdicts, because a measured violation is more\n actionable than a gap, and above COMPLIANT\n- **COMPLIANT** — at least one asset scanned, every section assessed, no findings\n\nThis skill is read-only — it produces a report but does not write files.\n\n---\n\n## Phase 5: Next Steps\n\n- Fix naming violations using the Phase 3 patterns (or the art bible's, where it states its own).\n- If standards were missing, run `/art-bible` to write its Asset Standards section.\n- Delete confirmed orphaned assets after manual review.\n- Run `/content-audit` to cross-check asset counts against GDD-specified requirements.\n",".claude/skills/asset-spec/SKILL.md":"---\nname: asset-spec\ndescription: \"Per-asset visual specs plus AI generation prompts from GDDs and character profiles. After the art bible.\"\nargument-hint: \"[system: | level: | character:] [--review full|lean|solo]\"\nuser-invocable: true\nallowed-tools: Read, Glob, Grep, Write, Edit, Agent, AskUserQuestion, Bash(bash \"*/.claude/skills/asset-spec/../../hooks/yaml-helper.sh\" resolve_config *)\nmodel: sonnet\n---\n\n!`bash \"${CLAUDE_SKILL_DIR}/../../hooks/yaml-helper.sh\" resolve_config --keys review_mode,automation`\n\n# Asset Spec\n\n\n\nIf no argument is provided, check whether `design/assets/entity-inventory.md` exists:\n- If it exists: read it, find the first entity or screen with status \"Needed\" but no spec file yet, and use `AskUserQuestion`:\n - Prompt: \"The next unspecced item is **[name]**. Generate specs for it?\"\n - Options: `[A] Yes — spec [name]` / `[B] Pick a different item` / `[C] Stop here`\n- If no entity inventory: check `design/assets/asset-manifest.md`. If manifest exists, same flow above but reading from manifest.\n- If neither exists: **start the Entity & Screen Inventory flow** (Phase 0b below) rather than failing.\n\n---\n\nEvery `AskUserQuestion` call follows `.claude/docs/automation-modes.md`\n(collaborative asks always · guided major-only · autonomous logs and proceeds;\n`automation_always_ask` categories always prompt). **Note**: actually invoking an external image\ngenerator (calling an image API) always prompts regardless of\n`modes.automation` — it is an irreversible external action guarded\nunconditionally, independent of whether `external_calls` is listed in\n`automation_always_ask`. (Today this skill only emits generation-prompt\n*text*; the guard applies if live generation is ever wired in.)\n\n## Phase 0b: Entity & Screen Inventory (runs when no arguments and no existing inventory)\n\nThis flow produces `design/assets/entity-inventory.md` — the master list of everything\nthe game needs visually. Run once before asset spec work begins.\n\n### Step 1 — Gather from docs\nRead all available source material in parallel, each doc by section: find the\nheadings you need with the Grep tool (pattern `^#`, content mode) and Read those\nranges with offset and limit.\n- `design/gdd/systems-index.md` — extract every system listed\n- GDD asset content — do **not** full-read every GDD. The two wanted sections are\n standard headings, and named entities live in the registry:\n ```\n Grep pattern=\"## (Visual/Audio Requirements|UI Requirements)\" glob=\"design/gdd/*.md\" output_mode=\"content\" -A 25\n ```\n For named entities (characters, enemies, buildings, items), read\n `design/registry/entities.yaml` (`entities`/`items`) if it exists and has\n entries; otherwise grep the GDDs for named content. Full-read a GDD only when\n its Visual/Audio section is missing or reads `[To be designed]` (Phase 1 already\n handles that case). VFX events surface in the Visual/Audio grep context.\n- `design/art/art-bible.md` — extract: any named visual categories, asset type expectations\n- `design/narrative/` — scan for any character or world entity documents if they exist (optional — not required)\n\n### Step 2 — Build proposed inventory\nOrganize everything found into categories:\n\n```\nCharacters / Protagonists\nEnemies / Creatures\nBuildings / Structures\nEnvironment / Terrain\nItems / Props\nVFX / Particles\nUI Screens (list each screen by name)\nHUD Elements\nAudio (SFX, music — descriptions only, no generation prompts)\nOther\n```\n\nFor each item, note the source doc it was found in.\n\n### Step 3 — Present and collaborate\nPresent the full proposed inventory to the user in conversation. Then use `AskUserQuestion`:\n- Prompt: \"I found **[N] visual entities and [N] UI screens** across your GDDs and art bible. Review the list — what's missing, what's not needed?\"\n- Options:\n - `[A] Looks good — save this inventory`\n - `[B] Add items I'll describe`\n - `[C] Remove items that don't apply`\n - `[D] Both add and remove — let me edit`\n\nIf [B] or [D]: ask the user to describe additional items. Accept brief descriptions (\"a medieval keep, used as a level background\") or detailed ones — either works. Work through them collaboratively until the user is satisfied.\n\nIf [C] or [D]: ask which items to remove and why. Remove them from the list.\n\n### Step 4 — Write inventory\nAfter user approval, ask: \"May I write the entity inventory to `design/assets/entity-inventory.md`?\"\n\nWrite the file:\n\n```markdown\n# Visual Entity & Screen Inventory\n\n> Generated: [date]\n> Sources: [list of source docs read]\n\n## Entities\n\n| # | Name | Type | Description | Source | Status |\n|---|------|------|-------------|--------|--------|\n| 1 | [name] | Character / Enemy / Building / Environment / Item / Other | [brief description] | [source doc] | Needed |\n\n## UI Screens\n\n| # | Screen Name | Description | Source | Status |\n|---|-------------|-------------|--------|--------|\n| 1 | Main Menu | [description] | [source] | Needed |\n\n## HUD Elements\n\n| # | Element | Description | Source | Status |\n|---|---------|-------------|--------|--------|\n\n## Audio\n\n| # | Name | Type (SFX / Music / Ambient) | Description | Source | Status |\n|---|------|------------------------------|-------------|--------|--------|\n```\n\nAfter writing, tell the user:\n> \"Entity inventory saved. Next steps:\n> - Run `/ux-design [screen name]` for each UI screen in the inventory\n> - Run `/asset-spec system:[name]`, `level:[name]` or `character:[name]` for each\n> visual entity — whichever of the three the entity belongs to\n> - Or run `/asset-spec` again to work through the inventory one item at a time\"\n\n---\n\n## Phase 0: Parse Arguments\n\nExtract:\n- **Target type**: `system`, `level`, or `character`\n- **Target name**: the name after the colon (normalize to kebab-case)\n- **Review mode**: `--review [full|lean|solo]` if present\n\nThe effective mode is the one already resolved at the top of this skill via\n`resolve_config --keys review_mode`, which applies the full chain; with nothing\nset it follows `modes.rigor` — `solo` at `minimal` (the default), `lean` at\n`standard`, `full` at `full`. A `--review` argument overrides it for this\nrun only.\n\n**Mode behavior:**\n- `full`: spawn both `art-director` and `technical-artist` in parallel\n- `lean`: spawn `art-director` only — faster, skips technical constraint pass\n- `solo`: no agent spawning — main session writes specs from art bible rules alone. Use for simple asset categories or when speed matters more than depth.\n\n---\n\n## Phase 1: Gather Context\n\nRead all source material **before** asking the user anything. Read the art bible and\nthe GDD by section: find the headings you need with the Grep tool (pattern `^#`,\ncontent mode) and Read those ranges with offset and limit.\n\n### Required reads:\n- **Art bible**: Read `design/art/art-bible.md` — fail if missing:\n > \"No art bible found. Run `/art-bible` first — asset specs are anchored to the art bible's visual rules and asset standards.\"\n\n **Exception — the minimal path.** If there is no art bible but\n `design/game-brief.md` exists (at `rigor: minimal` no art bible is required),\n do not fail: anchor the specs in the brief's **Art & audio direction** line,\n and say so at the top of the output — \"Anchored to the brief's one-line art\n direction; there is no art bible, so colour, shape and asset-standard rules\n below are proposals, not constraints.\" Offer `/art-bible` once, as optional.\n The written spec follows the same anchor: its header reads\n `> **Art direction**: design/game-brief.md (Art & audio direction) — no art bible`\n in place of the `> **Art Bible**:` line, each asset carries\n `**Brief anchor:** [the brief line applied]` in place of the **Art Bible\n Anchors** block, and no spec cites an Art Bible section or §8 tier.\n Extract: Visual Identity Statement, Color System (semantic colors), Shape Language, Asset Standards (art bible Section 8 — dimensions, formats, polycount budgets, texture resolution tiers).\n\n- **Project config**: Read `performance.*` and `naming.*` from `project.yaml`; for any key absent or empty (including when `project.yaml` has no `performance` or `naming` block), fall back to `.claude/docs/technical-preferences.md`. Extract performance budgets and naming conventions.\n\n### Source doc reads (by target type):\n- **system**: Read `design/gdd/[target-name].md`. Extract the **Visual/Audio Requirements** section. If it doesn't exist or reads `[To be designed]`:\n > \"The Visual/Audio section of `design/gdd/[target-name].md` is empty. Either run `/design-system [target-name]` to complete the GDD, or describe the visual needs manually.\"\n Use `AskUserQuestion`: `[A] Describe needs manually` / `[B] Stop — complete the GDD first`\n- **level**: Read `design/levels/[target-name].md`. Extract art requirements, asset list, VFX needs, and the art-director's production concept specs from Step 4.\n- **character** or **entity**: Read `design/narrative/characters/[target-name].md` or search `design/narrative/` and `design/assets/entity-inventory.md` for a matching entry. Extract visual description, role, and any specified distinguishing features.\n - **If no source doc exists**: do not fail. Instead, use `AskUserQuestion`:\n - Prompt: \"No profile found for **[name]**. Describe it briefly — a sentence or two is enough.\"\n - Options: `[A] Describe it now` / `[B] Skip this entity` / `[C] Stop here`\n - If [A]: the user's description becomes the source. Brief answers produce concise specs; detailed answers produce detailed specs. Accept whatever level of detail the user provides and work from it.\n\n### Optional reads:\n- **This target's existing spec**: if `design/assets/specs/[target-name]-assets.md` exists, read it — this is a re-run, and Phase 2 proposes only what is new or changed since (Phase 5 updates the file in place).\n- **Existing manifest**: Read `design/assets/asset-manifest.md` if it exists — extract already-specced assets for this target to avoid duplicates.\n- **Related specs**: Glob `design/assets/specs/*.md` — scan for assets that could be shared (e.g., a common UI element specced for one system might apply here too).\n\n### Present context summary:\n> **Asset Spec: [Target Type] — [Target Name]**\n> - Source doc: [path] — [N] asset types identified\n> - Art bible: found — Asset Standards at Section 8\n> - Existing specs for this target: [N already specced / none]\n> - Shared assets found in other specs: [list or \"none\"]\n\n---\n\n## Phase 2: Asset Identification\n\nFrom the source doc, extract every asset type mentioned — explicit and implied.\n\n**For systems**: look for VFX events, sprite references, UI elements, audio triggers, particle effects, icon needs, and any \"visual feedback\" language.\n\n**For levels**: look for unique environment props, atmospheric VFX, lighting setups, ambient audio, skybox/background, and any area-specific materials.\n\n**For characters**: look for sprite sheets (idle, walk, attack, death), portrait/avatar, VFX attached to abilities, UI representation (icon, health bar skin).\n\nGroup assets into categories:\n- **Sprite / 2D Art** — character sprites, UI icons, tile sheets\n- **VFX / Particles** — hit effects, ambient particles, screen effects\n- **Environment** — props, tiles, backgrounds, skyboxes\n- **UI** — HUD elements, menu art, fonts (if custom)\n- **Audio** — SFX, music tracks, ambient loops *(note: audio specs are descriptions only — no generation prompts)*\n- **3D Assets** — meshes, materials (if applicable per engine)\n\nPresent the full identified list to the user. Use `AskUserQuestion`:\n- Prompt: \"I identified [N] assets across [N] categories for **[target]**. Review before speccing:\"\n- Show the grouped list in conversation text first\n- Options: `[A] Proceed — spec all of these` / `[B] Remove some assets` / `[C] Add assets I didn't catch` / `[D] Adjust categories`\n\nDo NOT proceed to Phase 3 without user confirmation of the asset list.\n\n---\n\n## Phase 3: Spec Generation\n\nSpawn specialist agents based on review mode. **Issue all `Agent` calls simultaneously — do not wait for one before starting the next.**\n\n### Full mode — spawn in parallel:\n\n**`art-director`** via `Agent`:\n- Provide: full asset list from Phase 2, art bible Visual Identity Statement, Color System, Shape Language, the source doc's visual requirements, and any reference games/art mentioned in the art bible Section 9\n- Ask: \"For each asset in this list, produce: (1) a 2–3 sentence visual description anchored to the art bible's shape language and color system — be specific enough that two different artists would produce consistent results; (2) a generation prompt ready for use with AI image tools (Midjourney/Stable Diffusion style — include style keywords, composition, color palette anchors, negative prompts); (3) which art bible rules directly govern this asset (cite by section). For audio assets, describe the sonic character instead of a generation prompt.\"\n\n**`technical-artist`** via `Agent`:\n- Provide: full asset list, art bible Asset Standards (Section 8), performance budgets (`performance.*` from `project.yaml`, else `technical-preferences.md`), engine name and version\n- Ask: \"For each asset in this list, specify: (1) exact dimensions or polycount (match the art bible Asset Standards tiers — do not invent new sizes); (2) file format and export settings; (3) naming convention (`naming.*` from `project.yaml`, else `technical-preferences.md`); (4) any engine-specific constraints this asset type must respect; (5) LOD requirements if applicable. Flag any asset type where the art bible's preferred standard conflicts with the engine's constraints.\"\n\n### Lean mode — spawn art-director only (skip technical-artist).\n\n### Solo mode — skip both. Derive specs from art bible rules alone, noting that technical constraints were not validated.\n\n**Announce every skipped agent by name in the output**, before the specs:\n\"technical-artist skipped — Lean mode: technical constraints not validated.\" /\n\"art-director and technical-artist skipped — Solo mode: specs derived in this\nsession; technical constraints not validated.\" A spec drafted without an agent\nmust not read like one an agent reviewed.\n\n**Collect both responses before Phase 4.** If any conflict exists between art-director and technical-artist (e.g., art-director specifies 4K textures but technical-artist flags the engine budget requires 512px), surface it explicitly — do NOT silently resolve.\n\n---\n\n## Phase 4: Compile and Review\n\nCombine the agent outputs into a draft spec per asset. Present all specs in conversation text using this format:\n\n```\n## ASSET-[NNN] — [Asset Name]\n\n| Field | Value |\n|-------|-------|\n| Category | [Sprite / VFX / Environment / UI / Audio / 3D] |\n| Dimensions | [e.g. 256×256px, 4-frame sprite sheet] |\n| Format | [PNG / SVG / WAV / etc.] |\n| Naming | [e.g. vfx_frost_hit_01.png] |\n| Polycount | [if 3D — e.g. <800 tris] |\n| Texture Res | [e.g. 512px — matches Art Bible §8 Tier 2] |\n\n**Visual Description:**\n[2–3 sentences. Specific enough for two artists to produce consistent results.]\n\n**Art Bible Anchors:**\n- §3 Shape Language: [relevant rule applied]\n- §4 Color System: [color role — e.g. \"uses Threat Blue per semantic color rules\"]\n\n**Generation Prompt:**\n[Ready-to-use prompt. Include: style keywords, composition notes, color palette anchors, lighting direction, negative prompts.]\n\n**Status:** Needed\n```\n\nAfter presenting all specs, use `AskUserQuestion`:\n- Prompt: \"Asset specs for **[target]** — [N] assets. Review complete?\"\n- Options: `[A] Approve all — write to file` / `[B] Revise a specific asset` / `[C] Regenerate with different direction`\n\nIf [B]: ask which asset and what to change. Revise inline and re-present. Do NOT re-spawn agents for minor text revisions — only re-spawn if the visual direction itself needs to change.\n\nIf [C]: ask what direction to change. Re-spawn the relevant agent with the updated brief.\n\n---\n\n## Phase 5: Write Spec File\n\nAfter approval, ask: \"May I write the spec to `design/assets/specs/[target-name]-assets.md`?\"\n\n**If that file already exists** (a re-run for the same target), update it in\nplace — never overwrite it wholesale. Keep its existing `ASSET-NNN` blocks and\nIDs, apply only the changes the user approved, and append new assets with the\nnext project-wide IDs. Show what changes, then ask \"May I update\n`design/assets/specs/[target-name]-assets.md`?\" instead of \"May I write\".\n\nWrite the file with:\n\n```markdown\n# Asset Specs — [Target Type]: [Target Name]\n\n> **Source**: [path to source GDD/level/character doc]\n> **Art Bible**: design/art/art-bible.md\n> **Generated**: [date]\n> **Status**: [N] assets specced / [N] approved / [N] in production / [N] done\n\n[all asset specs in ASSET-NNN format]\n```\n\nThen update `design/assets/asset-manifest.md`. If it doesn't exist, create it:\n\n```markdown\n# Asset Manifest\n\n> Last updated: [date]\n\n## Progress Summary\n\n| Total | Needed | In Progress | Done | Approved |\n|-------|--------|-------------|------|----------|\n| [N] | [N] | [N] | [N] | [N] |\n\n## Assets by Context\n\n### [Target Type]: [Target Name]\n| Asset ID | Name | Category | Status | Spec File |\n|----------|------|----------|--------|-----------|\n| ASSET-001 | [name] | [category] | Needed | design/assets/specs/[target]-assets.md |\n```\n\nIf the manifest already exists, append the new context block — on a re-run for this target, add the new rows to its existing block instead of appending a second one — and update the Progress Summary counts.\n\nAsk: \"May I update `design/assets/asset-manifest.md`?\"\n\n---\n\n## Phase 6: Close\n\nUse `AskUserQuestion`:\n- Prompt: \"Asset specs complete for **[target]**. What's next?\"\n- Options:\n - `[A] Spec another system — /asset-spec system:[next-system]`\n - `[B] Spec a level — /asset-spec level:[level-name]`\n - `[C] Spec a character — /asset-spec character:[character-name]`\n - `[D] Run /asset-audit — validate delivered assets against specs`\n - `[E] Stop here`\n\n---\n\n## Asset ID Assignment\n\nAsset IDs are assigned sequentially across the entire project — not per-context. Read the manifest before assigning IDs to find the current highest number:\n\n```\nGrep pattern=\"ASSET-\" path=\"design/assets/asset-manifest.md\"\n```\n\nStart new assets from `ASSET-[highest + 1]`. This ensures IDs are stable and unique across the whole project.\n\nIf no manifest exists yet, start from `ASSET-001`.\n\n---\n\n## Shared Asset Protocol\n\nBefore speccing an asset, check if an equivalent already exists in another context's spec:\n\n- Common UI elements (health bars, score displays) are often shared across systems\n- Generic environment props may appear in multiple levels\n- Character VFX (hit sparks, death effects) may reuse a base spec with color variants\n\nIf a match is found: reference the existing ASSET-ID rather than creating a duplicate. Note the shared usage in the manifest's referenced-by column.\n\n> \"ASSET-012 (Generic Hit Spark) already specced for Combat system. Reusing for Tower Defense — adding tower-defense to referenced-by.\"\n\n---\n\n## Error Recovery Protocol\n\nIf any spawned agent returns BLOCKED or cannot complete:\n\n1. Surface immediately: \"[AgentName]: BLOCKED — [reason]\"\n2. In `lean` mode or if `technical-artist` blocks: proceed with art-director output only — note that technical constraints were not validated\n3. In `solo` mode or if `art-director` blocks: derive descriptions from art bible rules — flag as \"Art director not consulted — verify against art bible before production\"\n4. Always produce a partial spec — never discard work because one agent blocked\n\n---\n\n## Collaborative Protocol\n\n**Applies in `collaborative` mode (the default).** For `guided` and\n`autonomous` modes, see `.claude/docs/automation-modes.md` — the rules below\ndescribe what collaborative mode requires, not universal behavior.\n\nEvery phase follows: **Identify → Confirm → Generate → Review → Approve → Write**\n\n- Never spec assets without first confirming the asset list with the user\n- Always anchor specs to the art bible — a spec that contradicts the art bible is wrong\n- Surface all agent disagreements — do not silently pick one\n- Write the spec file only after explicit approval\n- Update the manifest immediately after writing the spec\n\n---\n\n## Recommended Next Steps\n\n- Run `/asset-spec [next-context]` to continue speccing remaining systems, levels, or characters\n- Run `/asset-audit` to validate delivered assets against the written specs and identify gaps or mismatches\n",".claude/skills/balance-check/SKILL.md":"---\nname: balance-check\ndescription: \"Find balance outliers, broken progressions, degenerate strategies, economy imbalances in formulas and data. 'Check game balance'.\"\nargument-hint: \"[system-name|path-to-data-file]\"\nuser-invocable: true\nallowed-tools: Read, Glob, Grep, Write, AskUserQuestion, Bash(bash \"*/.claude/skills/balance-check/../../hooks/yaml-helper.sh\" resolve_config *)\nmodel: sonnet\n---\n\n!`bash \"${CLAUDE_SKILL_DIR}/../../hooks/yaml-helper.sh\" resolve_config --keys automation`\n\n# Balance Check\n\n\n\nEvery `AskUserQuestion` call follows `.claude/docs/automation-modes.md`\n(collaborative asks always · guided major-only · autonomous logs and proceeds;\n`automation_always_ask` categories always prompt).\n\n## Insufficient input — check this before producing any report\n\n**If the inputs this skill needs do not exist, the answer is \"could not run\" —\nnot a filled-in report.** Check first, and stop if the check fails.\n\n1. List the inputs this skill reads (data files, prior reports, profiler output,\n test results, registries, source code).\n2. For each, record `FOUND` or `ABSENT` — not \"assumed present\".\n3. If any input required for a section is ABSENT, that section is\n **`NOT ASSESSED — NO DATA`**. Do not estimate it, do not infer it from an\n adjacent artifact, and do not leave a mandated cell to be filled by whoever\n reads the template next.\n4. If **every** required input is ABSENT, stop and report\n **`NOT ASSESSED — NO DATA`** as the whole verdict, naming what was missing and\n which skill produces it.\n\n**A verdict of `NOT ASSESSED` is a success.** It is the correct, useful answer to\n\"what does the data say?\" when there is no data. The failure mode this prevents is\nspecific: a report whose verdict enum has no \"could not run\" state produces\n**false clean passes** — an asset audit returning COMPLIANT on a project with no\nassets and no standards, or a performance profile reporting \">99% headroom against\na 16.67ms budget\" with zero profiler data and no budget ever set.\n\n**Absence of evidence is never evidence of absence.** A scan that finds no\nmatches because there are no files to scan has not verified anything. Say which of\nthe two happened — a reader cannot tell from a green result.\n\n---\n\n## Phase 1: Identify Balance Domain\n\nDetermine the balance domain from `$ARGUMENTS` — the whole string, since a data-file path may contain spaces:\n\n- **Combat** → weapon/ability DPS, time-to-kill, damage type interactions\n- **Economy** → resource faucets/sinks, acquisition rates, item pricing\n- **Progression** → XP/power curves, dead zones, power spikes\n- **Loot** → rarity distribution, pity timers, inventory pressure\n- **File path given** → load that file directly and infer domain from content\n\nIf no argument, ask the user which system to check.\n\n---\n\n## Phase 2: Read Data Files\n\nRead relevant files from `assets/data/` and `design/balance/` for the identified domain.\nNote every file read — they will appear in the Data Sources section of the report.\n\n---\n\n## Phase 3: Read Design Document\n\n**Registry first.** If `design/registry/entities.yaml` exists, read it before the\nGDD. Its `constants` and `formulas` sections hold the cross-GDD named values and\noutput ranges — the balance targets — already distilled, each with a `source:`\nGDD and any `revised:` date:\n```\nGrep pattern=\"^ - name:\" path=\"design/registry/entities.yaml\" output_mode=\"content\" -A 6\n```\nTake the intended values from the registry for any constant or formula it lists\n(the `constants:` and `formulas:` blocks); these are the authoritative cross-doc\nfigures a GDD must not contradict. **If `design/registry/entities.yaml` does not\nexist or has no entries** (it ships as an empty stub until `/design-system`\npopulates it), skip this and use the GDD alone.\n\nThen read the GDD for the system from `design/gdd/` to understand intended design\ntargets, tuning knobs, and expected value ranges — for anything the registry did\nnot already supply. This is the baseline for \"correct\" behaviour. Read it by section:\nfind the headings you need with the Grep tool (pattern `^#`, content mode) and\nRead those ranges with offset and limit.\n\nIf the data files are FOUND but neither source gives targets for this domain,\nthe sections that judge against targets (Outliers Detected, and Progression\nAnalysis where the domain has a curve) are `NOT ASSESSED — NO DATA`. Each one names what was missing — the\nGDD it looked for in `design/gdd/`, and whether the registry was absent or empty\n— and names `/design-system`, which writes both.\n\n---\n\n## Phase 4: Perform Analysis\n\n**Every domain: compare each value with its target.** For each named value in the\ndata files, take its target from Phase 3 — a registry constant's `value`, a\nregistry formula's `output_range`, or the range the GDD states — and compare. A\nvalue outside its target is a row in Outliers Detected (`player_damage_base` 140\nagainst 90–110). A value with no target anywhere is neither in range nor an\noutlier: list it under Values That Need Attention as `no stated range — not judged`.\n\nThen run domain-specific checks:\n\n**Combat balance:**\n- Calculate DPS for all weapons/abilities at each power tier\n- Check time-to-kill at each tier\n- Identify any options that dominate all others (strictly better)\n- Check if defensive options can create unkillable states\n- Verify damage type/resistance interactions are balanced\n\n**Economy balance:**\n- Map all resource faucets and sinks with flow rates\n- Project resource accumulation over time\n- Check for infinite resource loops\n- Verify gold sinks scale with gold generation\n- Check if any items are never worth purchasing\n\n**Progression balance:**\n- Plot the XP curve and power curve\n- Check for dead zones (no meaningful progression for too long)\n- Check for power spikes (sudden jumps in capability)\n- Verify content gates align with expected player power\n- Check if skip/grind strategies break intended pacing\n\n**Loot balance:**\n- Calculate expected time to acquire each rarity tier\n- Check pity timer math\n- Verify no loot is strictly useless at any stage\n- Check inventory pressure vs acquisition rate\n\n---\n\n## Phase 5: Output the Analysis\n\n```\n## Balance Check: [System Name]\n\n### Data Sources Analyzed\n- [List of files read]\n\n### Health Summary: [NOT ASSESSED / HEALTHY / CONCERNS / CRITICAL ISSUES]\n\n### Outliers Detected\n| Item/Value | Expected Range | Actual | Issue |\n|-----------|---------------|--------|-------|\n\n### Degenerate Strategies Found\n- [Strategy description and why it is problematic]\n\n### Progression Analysis\n[Graph description or table showing progression curve health]\n\n### Recommendations\n| Priority | Issue | Suggested Fix | Impact |\n|----------|-------|--------------|--------|\n\n### Values That Need Attention\n[Specific values with suggested adjustments and rationale]\n```\n\nChoose the Health Summary by the worst finding, first match wins:\n- **CRITICAL ISSUES** — a degenerate strategy (one choice dominates every\n alternative), a progression that stalls or cannot be completed, or an economy\n loop with no sink\n- **CONCERNS** — outliers or curve problems a tuning pass can fix, with no\n finding of the critical kind\n- **NOT ASSESSED** — nothing to analyze (the no-data path above), a section that\n needs targets is `NOT ASSESSED — NO DATA`, or a value had no stated range to\n judge it against; name which. It ranks below the two finding verdicts, because\n a measured problem is more actionable than a gap, and above HEALTHY\n- **HEALTHY** — every value judged against a stated target, no outliers, no\n degenerate strategies, progression within the stated targets\n\n---\n\n## Phase 6: Fix & Verify Cycle\n\nAfter presenting the report, use `AskUserQuestion`:\n- Prompt: \"Balance check complete. What would you like to do next?\"\n- Options:\n - `[A] Fix highest-priority issue now — walk me through it`\n - `[B] Save report to design/balance/balance-check-[system]-[date].md`\n - `[C] Stop here — I'll review the findings manually`\n\n**Run as a subagent?** `game-designer` preloads this skill, and a subagent has\nno `AskUserQuestion`. End your reply with the question and these three options\nas a short list, and stop: whoever called you asks the user and passes the\nanswer back.\n\nIf [A]:\n- Ask which issue to address first (refer to the Recommendations table by priority row)\n- Guide the user to update the relevant data file in `assets/data/` or formula in `design/balance/`\n- After each fix, offer to re-run the relevant balance checks to verify no new outliers were introduced\n- If the fix changes a tuning knob defined in a GDD or referenced by an ADR, remind the user:\n > \"This value is defined in a design document. Run `/propagate-design-change [path]` on the affected GDD to find downstream impacts before committing.\"\n\nIf [B]:\n- Write the report to `design/balance/balance-check-[system]-[date].md` (create the directory if needed). Use the current date for [date] in YYYY-MM-DD format.\n- Confirm the file was written, then end with: \"Re-run `/balance-check` after fixes to verify.\"\n\nIf [C]:\n- Summarize open issues and end with: \"Re-run `/balance-check` after fixes to verify.\"\n",".claude/skills/brainstorm/SKILL.md":"",".claude/skills/brainstorm/references/full-concept.md":"# Full concept flow (`workflow: standard` or `full`)\n\n**In this file:** start · Phase 1 Creative discovery · Phase 2 Concept generation · Phase 3 Core loop ·\nPhase 4 Pillars and boundaries · Phase 5 Player types · Phase 6 Scope and feasibility · Phase 7\nWrite the concept · Phase 8 Next steps\n\nThe output is `design/gdd/game-concept.md`, written from the game-concept template SKILL.md names.\nAsk at each phase; never generate the whole concept silently. You facilitate, the user decides.\nWrite the analysis in your reply first, then ask with short option labels.\n\n## Start\n\n1. The text typed after the skill name may hold a genre or theme hint (`roguelike`, `cozy\n farming`). `open` or nothing: start from scratch.\n2. If `design/gdd/game-concept.md` or `design/gdd/game-pillars.md` exists, read it by section (find\n the headings with the Grep tool with pattern `^#` in content mode, then read those ranges)\n and resume or build on it instead of restarting.\n\n## Phase 1: Creative discovery\n\nStart with the person, not the game. Ask conversationally:\n- A moment in a game that moved or thrilled them, and what created it.\n- A fantasy they have always wanted in a game and never found.\n- The three games they spent the most time with, and why. Ask this as plain text, never with\n preset options: they must be able to type any game.\n- Genres they love or avoid. Then ask: challenge, relax, story or self-expression?\n\nThen ask these three questions together:\n- \"What kind of experience do you most want players to have?\" Challenge & Mastery / Story &\n Discovery / Expression & Creativity / Relaxation & Flow\n- \"What's your realistic development timeline?\" Weeks / Months / 1-2 years / Multi-year\n- \"Where are you in your dev journey?\" First game / Shipped before / Professional background\n\nSum the answers up as a **Creative Brief** of 3 to 5 sentences (emotional goals, taste,\nconstraints), read it back and confirm it.\n\n## Phase 2: Concept generation\n\nGenerate **three** distinct concepts from the brief, each in a different direction, using:\n- **Verb-first:** start from the core verb (build, fight, explore, solve, survive, manage).\n- **Mashup:** genre A + theme B; the tension is the hook (\"farming sim + cosmic horror\").\n- **Experience-first (MDA backward):** start from the aesthetic (sensation, fantasy, narrative,\n challenge, fellowship, discovery, expression, submission) and work back to mechanics.\n\nEach concept has: Working Title · Elevator Pitch (1-2 sentences, passes the 10-second test) · Core\nVerb · Core Fantasy · Unique Hook (\"like X, and also Y\") · Primary MDA Aesthetic · Estimated Scope\n(small / medium / large) · Why It Could Work (one sentence) · Biggest Risk (one sentence).\n\nPresent all three, then ask one question with these five options: \"Which concept resonates with\nyou? You can pick one, combine elements, or ask for fresh directions.\" `Concept 1 — [Title]` /\n`Concept 2 — [Title]` / `Concept 3 — [Title]` / `Combine elements across concepts` / `Generate\nfresh directions`. Ask it in every automation mode: no rule can pick the user's creative\ndirection. Do not push toward a choice.\n\n## Phase 3: Core loop\n\nFor the chosen concept, ask with options derived from the concept, each with an `I'll describe it`\noption:\n1. \"What's the primary feel of the core action?\" (3-4 options that fit the genre and tone)\n2. The concept's most important design variable (world reactivity, pacing, agency), as a question.\n\nThen work through, in the reply:\n- **30-second loop:** is the action satisfying in itself, and why (feedback, timing, depth)?\n- **5-minute loop:** what turns moments into cycles; where \"one more run\" starts; the choices made.\n- **Session loop (30-120 minutes):** a full session, its stopping points, the hook between sessions.\n- **Progression loop:** how the player grows, the long-term goal, when the game is done.\n- **Motivation (self-determination theory):** autonomy, competence, relatedness.\n\n## Phase 4: Pillars and boundaries\n\nDraft **3 to 5 pillars**, each with a name, a one-sentence definition and a design test (\"debating\nX or Y, this pillar picks __\"). Pillars should pull against each other a little. Add **3 or more\nanti-pillars**: \"We will NOT do [thing] because it would compromise [pillar].\"\n\nAsk: \"Do these pillars feel right for your game?\" `Lock these in` / `Rename or reframe one` /\n`Swap a pillar out` / `Something else`. After a revision ask: \"Pillars updated. Ready to lock these\nin?\" `Lock these in` / `Revise another pillar` / `Something else`.\n- `collaborative`: repeat until the user picks `Lock these in`.\n- `guided`: ask once, apply the revision, lock them in.\n- `autonomous`: do not ask; lock the draft in and log the decision with the alternatives.\n\n**Review mode** (from the settings block or `--review`):\n- `solo` or `lean`: print these two lines, with the mode's name, and go on to Phase 5:\n `CD-PILLARS skipped — Solo mode.` and `AD-CONCEPT-VISUAL skipped — Solo mode.`\n- `full`: hand the pillar review to the `creative-director` agent (gate CD-PILLARS; brief: the\n pillars with design tests, anti-pillars, core fantasy and hook) and the visual review to the\n `art-director` agent (gate AD-CONCEPT-VISUAL; brief: the pitch, pillars, target platform if\n known, reference games mentioned). Each reads its own gate file and returns its verdict; neither\n edits files. They are independent: hand them out together where you can, otherwise one after\n another.\n\nWith both reports, when CD-PILLARS returns APPROVE, ask these two questions together:\n- **Pillars:** the creative-director's feedback. `Lock in as-is` / `Revise [pillar]` / `Discuss\n further`.\n- **Visual anchor:** the art-director's 2-3 named directions, one option each, plus `Combine\n elements across directions` / `Describe my own direction`. On STRONG mark the dominant one\n `(Recommended)`. On CONCERNS show its reason and offer `Revise pillars` / `Describe my own\n direction`.\n\nIf CD-PILLARS returns CONCERNS or REJECT, settle the pillars first (the Pillars question alone),\nthen ask the Visual anchor question alone. NOT ASSESSED from either gate is not an approval: name\nthe missing input, supply it and run that gate again; failing that, treat CD-PILLARS NOT ASSESSED\nas CONCERNS, and with no art-director directions offer only `Describe my own direction`.\n\nThe chosen direction is the **Visual Identity Anchor**: it goes into the concept and seeds the art\nbible.\n\n## Phase 5: Player types\n\nUsing Bartle's types and the Quantic Foundry model: the primary player who will love it\n(Achievers, Explorers, Socializers, Competitors, Creators, Storytellers), the secondary appeal, who\nit is not for, and successful games that serve the same player.\n\n## Phase 6: Scope and feasibility\n\n- **Platform.** Ask: \"What platforms are you targeting?\" `PC (Steam / Epic)` / `Mobile (iOS /\n Android)` / `Console` / `Web / Browser` / `Multiple platforms`. Record it for `/setup-engine`.\n Note what the platform implies, without recommending an engine: `/setup-engine` makes that call\n against the pinned engine reference.\n- **Engine.** Ask in every automation mode, `autonomous` included: \"Do you already have an engine\n you work in?\" `Godot` / `Unity` / `Unreal Engine 5` / `No preference — help me decide`. Never\n pick an engine for the user. A named engine is recorded as their preference without second\n guessing. No preference: \"Run `/setup-engine` after this session; it walks through the choice\n with your concept and platform.\" Make no recommendation here.\n- Art pipeline and how labour-heavy it is; content scope (levels, items, hours); the MVP (the\n smallest build that tests whether the core loop is fun); the biggest technical, design and market\n risks; scope tiers (full vision, and what ships if time runs out).\n\n**Review mode** before TD-FEASIBILITY: `solo` or `lean` prints `TD-FEASIBILITY skipped — Solo\nmode.` (or `Lean mode`) and goes on to the scope tiers. `full`: after the technical risks, hand the\nfeasibility review to the `technical-director` agent (gate TD-FEASIBILITY; brief: the core loop,\nplatform, engine or \"undecided\", the technical risks). Show its report. HIGH RISK: offer to revisit\nscope. CONCERNS: note and go on. NOT ASSESSED: name the missing input and record feasibility as not\nassessed in the concept's risks, never as VIABLE.\n\n**Review mode** before PR-SCOPE: `solo` or `lean` prints `PR-SCOPE skipped — Solo mode.` (or `Lean\nmode`) and goes on to Phase 7. `full`: hand the scope review to the `producer` agent (gate PR-SCOPE;\nbrief: full vision, MVP, scope tiers, timeline, team size). It answers REALISTIC, OPTIMISTIC or\nUNREALISTIC. UNREALISTIC: ask whether to adjust the MVP or scope tiers or keep them; the user\ndecides and the concept is never rejected for it. OPTIMISTIC: show the producer's adjustments and\nask whether to apply them. NOT ASSESSED: ask for the missing input (timeline, team size) and run it\nagain, or record scope as not assessed, never as REALISTIC.\n\n## Phase 7: Write the concept\n\nFill every section of the template from the conversation, including the MDA analysis, motivation\nprofile and flow design, plus a **Visual Identity Anchor** section: the direction's name, its\none-line visual rule, 2-3 supporting principles with design tests, and the colour philosophy.\n\nThe Core Identity table's Estimated Scope matches the full-vision timeline in Scope Tiers: write\n\"Large (X–Y months, solo)\" or \"Large (X–Y months, team of N)\", not \"Large\".\n\nAsk, as its own question: \"Game concept is ready. May I write it to `design/gdd/game-concept.md`?\"\n`Yes — write it` / `Not yet — revise a section first`. Write only on an explicit yes to this\nquestion. A revision: ask which section (`Elevator Pitch` / `Core Fantasy & Unique Hook` /\n`Pillars` / `Core Loop` / `MVP Definition` / `Scope Tiers` / `Risks` / `Something else — I'll\ndescribe`), show it before and after, then ask \"Ready to write the updated concept document?\"\n`Yes — write it` / `Revise another section`.\n- `collaborative`: repeat until the yes.\n- `guided`: ask once, apply the revision and write.\n- `autonomous`: do not ask; write and log the decision.\n\nWrite the file, creating folders as needed. Never write `design/game-brief.md` at this tier.\n\n## Phase 8: Next steps\n\nList every step, in order.\n\n**Design-first** (the concept is well defined):\n1. `/setup-engine`: configure the engine and its version-aware reference docs\n2. `/art-bible`: the visual identity, before any GDD. Required before the Technical Setup gate at\n `full`; at `standard` only when the game has visual-asset stories\n3. `/design-review design/gdd/game-concept.md`: check the concept is complete\n4. The `creative-director` agent: refine the pillars\n5. `/map-systems`: the systems, their dependencies and priorities, in the systems index\n6. `/design-system`: one GDD per system from step 5\n7. `/create-architecture`: the architecture blueprint and its Required ADR list\n8. `/architecture-decision`: one ADR per decision on that list\n9. `/architecture-review`: the TR registry and traceability matrix (needed before the\n Pre-Production gate)\n10. `/gate-check`: the stage gate before Production\n\n**Prototype-first** (the core mechanic is unproven):\n1. `/setup-engine`\n2. `/prototype [core mechanic]`: is it fun, in a day at most, throwaway code\n3. PROCEED: `/art-bible`, then design-first steps 5-10 with what the prototype taught\n4. PIVOT: `/brainstorm` again with the learnings\n5. After design and architecture, `/vertical-slice` before committing to sprints\n\nThen a summary: the pitch, pillars, primary player type, engine preference, biggest risk and the\nfile path. End with the line `Verdict: COMPLETE — game concept written.`\n\nIf the conversation is getting long before Phase 7, say that anything not yet written to\n`design/gdd/game-concept.md` lives only in this conversation, and write the concept before a fresh\nsession.\n",".claude/skills/bug-report/SKILL.md":"",".claude/skills/bug-triage/SKILL.md":"",".claude/skills/changelog/SKILL.md":"",".claude/skills/code-review/SKILL.md":"",".claude/skills/consistency-check/SKILL.md":"",".claude/skills/content-audit/SKILL.md":"",".claude/skills/create-architecture/SKILL.md":"",".claude/skills/create-architecture/references/0-load-context.md":"",".claude/skills/create-architecture/references/1-layers.md":"",".claude/skills/create-architecture/references/2-module-ownership.md":"",".claude/skills/create-architecture/references/3-data-flow.md":"",".claude/skills/create-architecture/references/4-api-boundaries.md":"",".claude/skills/create-architecture/references/5-adr-audit.md":"",".claude/skills/create-architecture/references/6-missing-adrs.md":"",".claude/skills/create-architecture/references/7-write.md":"",".claude/skills/create-architecture/references/8-handoff.md":"",".claude/skills/create-control-manifest/SKILL.md":"",".claude/skills/create-epics/CONTRACT.md":"",".claude/skills/create-epics/SKILL.md":"",".claude/skills/create-epics/references/pr-epic-gate.md":"",".claude/skills/create-stories/CONTRACT.md":"",".claude/skills/create-stories/SKILL.md":"",".claude/skills/create-stories/references/qa-lead-gate.md":"",".claude/skills/day-one-patch/SKILL.md":"",".claude/skills/design-review/SKILL.md":"",".claude/skills/design-system/SKILL.md":"",".claude/skills/design-system/references/1-parse-arguments.md":"",".claude/skills/design-system/references/2-gather-context.md":"",".claude/skills/design-system/references/3-file-skeleton.md":"",".claude/skills/design-system/references/4-section-design.md":"",".claude/skills/design-system/references/5-post-design.md":"",".claude/skills/dev-story/CONTRACT.md":"",".claude/skills/dev-story/SKILL.md":"",".claude/skills/dev-story/references/engine-checks.md":"",".claude/skills/dev-story/references/version-mismatch.md":"",".claude/skills/estimate/SKILL.md":"",".claude/skills/gate-check/CONTRACT.md":"",".claude/skills/gate-check/SKILL.md":"",".claude/skills/gate-check/references/2b-workflow-tier.md":"",".claude/skills/gate-check/references/3-run-gate-check.md":"",".claude/skills/gate-check/references/4-assessment.md":"",".claude/skills/gate-check/references/5-verdict.md":"",".claude/skills/gate-check/references/6-update-stage.md":"",".claude/skills/gate-check/references/7-next-steps.md":"",".claude/skills/gate-check/references/gate-polish.md":"",".claude/skills/gate-check/references/gate-pre-production.md":"",".claude/skills/gate-check/references/gate-production.md":"",".claude/skills/gate-check/references/gate-release.md":"",".claude/skills/gate-check/references/gate-systems-design.md":"",".claude/skills/gate-check/references/gate-technical-setup.md":"",".claude/skills/help/SKILL.md":"",".claude/skills/hotfix/SKILL.md":"",".claude/skills/launch-checklist/SKILL.md":"",".claude/skills/localize/SKILL.md":"",".claude/skills/map-systems/SKILL.md":"",".claude/skills/milestone-review/SKILL.md":"",".claude/skills/onboard/SKILL.md":"",".claude/skills/patch-notes/SKILL.md":"",".claude/skills/perf-profile/SKILL.md":"",".claude/skills/playtest-report/SKILL.md":"",".claude/skills/project-stage-detect/SKILL.md":"",".claude/skills/propagate-design-change/SKILL.md":"",".claude/skills/prototype/SKILL.md":"",".claude/skills/prototype/references/1-question.md":"",".claude/skills/prototype/references/2-load-context.md":"",".claude/skills/prototype/references/3-choose-path.md":"",".claude/skills/prototype/references/4-plan.md":"",".claude/skills/prototype/references/5-implement.md":"",".claude/skills/prototype/references/6-debrief.md":"",".claude/skills/prototype/references/7-report.md":"",".claude/skills/prototype/references/8-cd-review.md":"",".claude/skills/prototype/references/9-summary.md":"",".claude/skills/prototype/references/spike-mode.md":"",".claude/skills/qa-plan/SKILL.md":"",".claude/skills/quick-design/SKILL.md":"",".claude/skills/regression-suite/SKILL.md":"",".claude/skills/release-checklist/SKILL.md":"",".claude/skills/retrospective/SKILL.md":"",".claude/skills/reverse-document/SKILL.md":"",".claude/skills/review-all-gdds/SKILL.md":"",".claude/skills/review-all-gdds/references/1-load.md":"",".claude/skills/review-all-gdds/references/2-consistency.md":"",".claude/skills/review-all-gdds/references/3-design-holism.md":"",".claude/skills/review-all-gdds/references/4-scenarios.md":"",".claude/skills/review-all-gdds/references/5-report.md":"",".claude/skills/review-all-gdds/references/6-write.md":"",".claude/skills/review-all-gdds/references/7-handoff.md":"",".claude/skills/scope-check/SKILL.md":"",".claude/skills/security-audit/SKILL.md":"",".claude/skills/settings/SKILL.md":"",".claude/skills/setup-engine/SKILL.md":"",".claude/skills/setup-engine/references/11-upgrade.md":"",".claude/skills/setup-engine/references/12-output-summary.md":"",".claude/skills/setup-engine/references/2-guided-mode.md":"",".claude/skills/setup-engine/references/3-version.md":"",".claude/skills/setup-engine/references/4-claude-md-stack.md":"",".claude/skills/setup-engine/references/5-technical-preferences.md":"",".claude/skills/setup-engine/references/5.5-project-yaml.md":"",".claude/skills/setup-engine/references/6-knowledge-gap.md":"",".claude/skills/setup-engine/references/7-reference-docs.md":"",".claude/skills/setup-engine/references/7.5-scaffold.md":"",".claude/skills/setup-engine/references/8-verify.md":"",".claude/skills/setup-engine/references/godot-language-config.md":"",".claude/skills/skill-improve/SKILL.md":"",".claude/skills/skill-test/SKILL.md":"",".claude/skills/smoke-check/SKILL.md":"",".claude/skills/smoke-check/references/1-detect-setup.md":"",".claude/skills/smoke-check/references/2-run-tests.md":"",".claude/skills/smoke-check/references/3-coverage.md":"",".claude/skills/smoke-check/references/4-manual-checks.md":"",".claude/skills/smoke-check/references/5-report.md":"",".claude/skills/smoke-check/references/6-write-gate.md":"",".claude/skills/soak-test/SKILL.md":"",".claude/skills/sprint-plan/SKILL.md":"",".claude/skills/sprint-status/SKILL.md":"",".claude/skills/start/SKILL.md":"",".claude/skills/story-done/CONTRACT.md":"",".claude/skills/story-done/SKILL.md":"",".claude/skills/story-done/references/review-gates.md":"",".claude/skills/story-done/references/sprint-next.md":"",".claude/skills/story-done/references/tech-debt-row.md":"",".claude/skills/story-readiness/CONTRACT.md":"",".claude/skills/story-readiness/SKILL.md":"",".claude/skills/story-readiness/references/qa-lead-gate.md":"",".claude/skills/team-audio/SKILL.md":"",".claude/skills/team-combat/SKILL.md":"",".claude/skills/team-level/SKILL.md":"",".claude/skills/team-live-ops/SKILL.md":"",".claude/skills/team-narrative/SKILL.md":"",".claude/skills/team-polish/SKILL.md":"",".claude/skills/team-qa/SKILL.md":"",".claude/skills/team-release/SKILL.md":"",".claude/skills/team-ui/SKILL.md":"",".claude/skills/tech-debt/SKILL.md":"",".claude/skills/test-evidence-review/SKILL.md":"",".claude/skills/test-flakiness/SKILL.md":"",".claude/skills/test-helpers/SKILL.md":"",".claude/skills/test-setup/SKILL.md":"",".claude/skills/test-setup/references/1-detect.md":"",".claude/skills/test-setup/references/2-plan.md":"",".claude/skills/test-setup/references/3-directories.md":"",".claude/skills/test-setup/references/4-ci.md":"",".claude/skills/test-setup/references/5-smoke-seed.md":"",".claude/skills/test-setup/references/6-summary.md":"",".claude/skills/ux-design/SKILL.md":"",".claude/skills/ux-design/references/2-gather-context.md":"",".claude/skills/ux-design/references/3-file-skeleton.md":"",".claude/skills/ux-design/references/4-authoring.md":"",".claude/skills/ux-design/references/5-crossref-handoff.md":"",".claude/skills/ux-design/references/sections-hud.md":"",".claude/skills/ux-design/references/sections-patterns.md":"",".claude/skills/ux-design/references/sections-ux-spec.md":"",".claude/skills/ux-review/SKILL.md":"",".claude/skills/vertical-slice/SKILL.md":"","CLAUDE.md":"# Claude Code Game Studios -- Game Studio Agent Architecture\n\nIndie game development managed through 49 coordinated Claude Code subagents.\nEach agent owns a specific domain, enforcing separation of concerns and quality.\n\n## Technology Stack\n\n- **Engine**: [CHOOSE: Godot 4 / Unity / Unreal Engine 5]\n- **Language**: [CHOOSE: GDScript / C# / C++ / Blueprint]\n- **Version Control**: Git with trunk-based development\n- **Build System**: [SPECIFY after choosing engine]\n- **Asset Pipeline**: [SPECIFY after choosing engine]\n\n> **Note**: Engine-specialist agents exist for Godot, Unity, and Unreal with\n> dedicated sub-specialists. Use the set matching your engine.\n\n## Project Structure\n\n@.claude/docs/directory-structure.md\n\n## Engine Version Reference\n\n\n@docs/engine-reference/godot/VERSION.md\n\n\n## Technical Preferences\n\n`project.yaml` at the repo root is the primary config store — engine, specialists,\nnaming, platform, performance, modes. Skills resolve it via `resolve_config`\n(see `.claude/docs/config-resolution.md`).\n\n`.claude/docs/technical-preferences.md` is the **legacy fallback**, read on demand\nwhen a key is absent from `project.yaml`. It is not imported here: before\n`/setup-engine` runs it is almost entirely `[TO BE CONFIGURED]` placeholders, and\nafter it runs `project.yaml` holds the real values.\n\n## Coordination Rules\n\n@.claude/docs/coordination-rules.md\n\n## Collaboration Protocol\n\n**User-driven collaboration, not autonomous execution.**\nEvery task follows: **Question -> Options -> Decision -> Draft -> Approval**\n\n- Agents MUST ask \"May I write this to [filepath]?\" before using Write/Edit tools\n (exempt: `active.md` appends, agent memory, a subagent's new file at the path\n its orchestrating skill named; see `.claude/rules/agent-memory.md`)\n- Agents MUST show drafts or summaries before requesting approval\n- Multi-file changes require explicit approval for the full changeset\n- No commits without user instruction\n- A skipped or dismissed question is not an answer: act on nothing, re-ask in\n plain text and wait\n- Started outside this file's folder? Warn first: hooks, deny rules and the\n ask-first mode load only when Claude Code starts here\n\nSee `docs/COLLABORATIVE-DESIGN-PRINCIPLE.md` for full protocol and examples.\n\n> **First session?** If the project has no engine configured and no game concept,\n> run `/start` to begin the guided onboarding flow.\n\n## Coding Standards\n\n@.claude/docs/coding-standards.md\n\n## Context Management\n\nRead `.claude/docs/context-management.md` on demand — it is a reference, not\nsession context. Two of its conventions are load-bearing and cited by name\nelsewhere in the repo, so they are restated here rather than lost:\n\n- **`production/session-state/active.md` is the session checkpoint.** The file is\n the memory, not the conversation. Read it first after any compaction, crash, or\n `/clear`.\n- **Helpers in `.claude/scripts/` emit observations, never verdicts.** A script\n that scores or judges will eventually contradict a mode or override it cannot\n see. (Cited by `artifact-check.sh` and `adr-dep-graph.sh`.)\n","design/CLAUDE.md":"# Design Directory\n\nWhen authoring or editing files in this directory, follow these standards.\n\n## GDD Files (`design/gdd/`)\n\nThe 8 GDD sections, in order:\n1. Overview — one-paragraph summary\n2. Player Fantasy — intended feeling and experience\n3. Detailed Rules — unambiguous mechanics\n4. Formulas — all math defined with variables\n5. Edge Cases — unusual situations handled\n6. Dependencies — other systems listed\n7. Tuning Knobs — configurable values identified\n8. Acceptance Criteria — testable success conditions\n\n**How many are REQUIRED depends on `modes.workflow`** — all 8 at `full`; 5 at\n`standard` (Overview, Detailed Rules, Edge Cases, Dependencies, Acceptance\nCriteria, plus Formulas when the system has math); none at `minimal`, where\n`design/game-brief.md` is the design record instead of a GDD. Resolve the tier\nbefore flagging a section as missing — see `.claude/docs/workflow-modes.md`.\n\n> **Three other places already encode the tier rule** —\n> `.claude/docs/coding-standards.md`, `.claude/rules/design-docs.md` and\n> `.claude/hooks/validate-commit.sh`. This file is the copy a session working in\n> `design/` reads first, so it must agree with them: demanding all 8 at\n> `minimal` warns a jam project about six sections its own configuration says it\n> does not need, which trains the user to ignore the warning.\n\n**Section-name alias:** the GDD template and `/design-system` author section 3\nas `## Detailed Design`; the standard calls it **Detailed Rules**. Same required\nsection — accept either heading, never rewrite one into the other.\n\n**File naming:** `[system-slug].md` (e.g. `movement-system.md`, `combat-system.md`)\n\n**Systems index:** `design/gdd/systems-index.md` — update when adding a new GDD.\n\n**Design order:** Foundation → Core → Feature → Presentation → Polish\n\n**Validation:** Run `/design-review [path]` after authoring any GDD.\nRun `/review-all-gdds` after completing a set of related GDDs.\n\n## Quick Specs (`design/quick-specs/`)\n\nLightweight specs for tuning changes, minor mechanics, or balance adjustments.\nUse `/quick-design` to author.\n\n## UX Specs (`design/ux/`)\n\n- Per-screen specs: `design/ux/[screen-name].md`\n- HUD design: `design/ux/hud.md`\n- Interaction pattern library: `design/ux/interaction-patterns.md`\n- Accessibility requirements: `design/accessibility-requirements.md`\n\nUse `/ux-design` to author. Validate with `/ux-review` before passing to `/team-ui`.\n\n> **Accessibility requirements sit OUTSIDE `design/ux/` on purpose.** They are a\n> project-wide standard the per-screen specs consult, not a spec for one screen.\n> `.claude/docs/workflow-catalog.yaml`, the Pre-Production, Production and Polish\n> gates, and `/architecture-review` all check `design/accessibility-requirements.md`\n> at that exact path. Do not \"tidy\" it under `design/ux/` — every one of those\n> checks would stop matching, and the Technical Setup → Pre-Production gate would\n> become unpassable. `/ux-design` states the same rule at its `accessibility` mode.\n","docs/CLAUDE.md":"# Docs Directory\n\nWhen authoring or editing files in this directory, follow these standards.\n\n## Architecture Decision Records (`docs/architecture/`)\n\nUse the ADR template: `.claude/docs/templates/architecture-decision-record.md`\n\n**Required sections:** Title, Status, Context, Decision, Consequences,\nADR Dependencies, Engine Compatibility, GDD Requirements Addressed\n\n**Status lifecycle:** `Proposed` → `Accepted` → `Superseded`\n- Never skip `Accepted` — stories referencing a `Proposed` ADR are auto-blocked\n- Use `/architecture-decision` to create ADRs through the guided flow\n\n**TR Registry:** `docs/architecture/tr-registry.yaml`\n- Stable requirement IDs (e.g. `TR-movement-001`) that link GDD requirements to stories\n- Never renumber existing IDs — only append new ones\n- Updated by `/architecture-review` Phase 8\n\n**Control Manifest:** `docs/architecture/control-manifest.md`\n- Flat programmer rules sheet: Required / Forbidden / Guardrails per layer\n- Date-stamped `Manifest Version:` in header\n- Stories embed this version; `/story-done` checks for staleness\n\n**Validation:** Run `/architecture-review` after completing a set of ADRs.\n\n## Engine Reference (`docs/engine-reference/`)\n\nVersion-pinned engine API snapshots. **Always check here before using any\nengine API** — the LLM's training data predates the pinned engine version.\n\nCurrent engine: see `docs/engine-reference//VERSION.md` (`` is `godot`, `unity` or `unreal`, matching `engine.name` in `project.yaml`)\n","docs/engine-reference/unity/plugins/addressables.md":"","docs/engine-reference/unity/plugins/cinemachine.md":"","docs/engine-reference/unity/plugins/dots-entities.md":"","docs/engine-reference/unreal/plugins/common-ui.md":"","docs/engine-reference/unreal/plugins/gameplay-ability-system.md":"","docs/engine-reference/unreal/plugins/gameplay-camera-system.md":"","docs/engine-reference/unreal/plugins/pcg.md":"","src/CLAUDE.md":"# Source Directory\n\nWhen writing or editing game code in this directory, follow these standards.\n\n## Engine Version Warning\n\nThe LLM's training data predates the pinned engine version.\n**Always check `docs/engine-reference/` before using any engine API.**\nDo not guess at post-cutoff API signatures — look them up first.\n\n## Coding Standards\n\n- All public APIs require doc comments\n- Gameplay values must be **data-driven** (external config files), never hardcoded\n- Prefer dependency injection over singletons for testability\n- Architecture decisions go in `docs/architecture/` as ADRs — **how many depends on\n `modes.workflow`**: all at `full`, critical only at `standard`, none required at\n `minimal` (the decision log carries them)\n- Commits must reference the relevant story ID or design document\n\n## File Routing\n\nMatch the engine-specialist agent to the file type being written.\n`/setup-engine` records which specialist handles code, shaders and UI in the\n`specialists` block of `project.yaml`.\n\nWhen in doubt, use `specialists.code` from `project.yaml`.\n\n## Tests\n\nTests live in `tests/` — not in `src/`.\nRun `/test-setup` to scaffold the test framework if it doesn't exist yet.\nEvery gameplay system should have unit tests covering its formulas and edge cases.\n\n## Verification-Driven Development\n\nWrite tests first when adding gameplay systems.\nFor UI changes, verify with screenshots.\nCompare expected output to actual output before marking work complete.\n","studio-tests/CLAUDE.md":"# Studio Tests — Claude Instructions\n\nThis folder is the quality assurance layer for the Claude Code Game Studios skill/agent\nframework. It is self-contained and separate from any game project.\n\n## Key files\n\n| File | Purpose |\n|------|---------|\n| `catalog.yaml` | Master registry for all 74 skills and 49 agents. Contains category, spec path, and last-test tracking fields. Always read this first when running any test command. |\n| `quality-rubric.md` | Category-specific pass/fail metrics. Read the matching `###` section for the skill's category when running `/skill-test category`. |\n| `skills/[category]/[name].md` | Behavioral spec for a skill — 5 or more test cases + protocol compliance assertions. |\n| `agents/[tier]/[name].md` | Behavioral spec for an agent — 5 or more test cases + protocol compliance assertions. |\n| `templates/skill-test-spec.md` | Template for writing new skill spec files. |\n| `templates/agent-test-spec.md` | Template for writing new agent spec files. |\n| `results/` | Written by `/skill-test spec` when results are saved. Not gitignored — add it to `.gitignore` to keep results out of commits. |\n\n## Path conventions\n\n- Skill specs: `studio-tests/skills/[category]/[name].md`\n- Agent specs: `studio-tests/agents/[tier]/[name].md`\n- Catalog: `studio-tests/catalog.yaml`\n- Rubric: `studio-tests/quality-rubric.md`\n\nThe `spec:` field in `catalog.yaml` is the authoritative path for each skill/agent spec.\nAlways read it rather than guessing the path.\n\n## Skill categories\n\n```\ngate → gate-check\nreview → design-review, architecture-review, review-all-gdds\nauthoring → design-system, quick-design, architecture-decision, art-bible,\n create-architecture, ux-design, ux-review\nreadiness → story-readiness, story-done\npipeline → create-epics, create-stories, dev-story, create-control-manifest,\n propagate-design-change, map-systems, vertical-slice\nanalysis → consistency-check, balance-check, content-audit, code-review,\n tech-debt, scope-check, estimate, perf-profile, asset-audit,\n security-audit, test-evidence-review, test-flakiness\nteam → team-combat, team-narrative, team-audio, team-level, team-ui,\n team-qa, team-release, team-polish, team-live-ops\nsprint → sprint-plan, sprint-status, milestone-review, retrospective,\n changelog, patch-notes\nutility → all remaining skills\n```\n\n## Agent tiers\n\n```\ndirectors → creative-director, technical-director, producer, art-director\nleads → lead-programmer, narrative-director, audio-director, game-designer,\n systems-designer, level-designer, qa-lead\nspecialists → gameplay-programmer, engine-programmer, network-programmer,\n ai-programmer, tools-programmer, ui-programmer, ux-designer,\n technical-artist, sound-designer, performance-analyst, prototyper,\n writer, world-builder\nengine/godot → godot-specialist, godot-gdscript-specialist, godot-csharp-specialist,\n godot-shader-specialist, godot-gdextension-specialist\nengine/unity → unity-specialist, unity-ui-specialist, unity-shader-specialist,\n unity-dots-specialist, unity-addressables-specialist\nengine/unreal → unreal-specialist, ue-gas-specialist, ue-replication-specialist,\n ue-umg-specialist, ue-blueprint-specialist\noperations → devops-engineer, release-manager, live-ops-designer,\n community-manager, analytics-engineer, economy-designer,\n localization-lead\nqa → qa-tester, security-engineer, accessibility-specialist\n```\n\nA tier is the directory a spec lives in. The rubric category is the agent's\n`category:` in `catalog.yaml` and can differ: `security-engineer` and\n`accessibility-specialist` sit in `qa/` but are rated as `specialist`.\n\n## Workflow for testing a skill or agent\n\n1. Read `catalog.yaml` to get the `spec:` path and `category:` — from the\n `skills:` entry for a skill, the `agents:` entry for an agent\n2. Read the skill at `.claude/skills/[name]/SKILL.md` and every file in its\n `references/` folder, or the agent at `.claude/agents/[name].md`\n3. Read the project `CLAUDE.md` and the files it imports with `@`: every\n subagent receives them, so a rule stated there (for example a redirect in\n `coordination-rules.md`) counts as the skill's or agent's own\n4. Read the spec at the `spec:` path\n5. Evaluate the spec's Static Assertions, each case's assertions, and its\n Protocol Compliance list\n6. Offer to write results to `results/` and update `catalog.yaml`\n\n## Fixture defaults\n\nEvery skill spec has a `## Fixture Defaults` section above its cases. A case's\nsandbox project starts from this `project.yaml` block:\n\n```yaml\nmodes:\n rigor: minimal # → workflow minimal, docs.density terse, qa.level minimal,\n # story_granularity coarse, review_mode solo, team.size individual\n automation: collaborative\n```\n\n- A setting the case's Fixture names wins over the block, and an explicit\n sub-knob (`modes.workflow`, `modes.review_mode`, `qa.level`, …) wins over the\n `rigor` preset (`.claude/docs/config-resolution.md` § Defaults).\n- A case that says `project.yaml` sets no `modes` keys, or that there is no\n `project.yaml`, runs without the block: it tests the unset defaults.\n- There is no `project.local.yaml` unless the case names one.\n- A case whose expected behaviour changes with a setting pins that setting in\n its own Fixture, with the reason — e.g. `modes.workflow: standard` (pinned:\n unset resolves to minimal, which recommends the next build instead of a\n sprint).\n\nThe block is pinned so that a change to the framework's defaults cannot\nsilently change what a case tests. A spec may set a different default in its\nown section when most of its cases need one.\n\n## Workflow for improving a skill\n\nUse `/skill-improve [name]`. It handles the full loop:\ntest → diagnose → propose fix → rewrite → retest → keep or revert.\n\n## Spec validity note\n\nSpecs in this folder assert the **correct** behavior, not whatever a skill or agent\ndoes today. A failing assertion means the skill or agent is wrong until shown\notherwise: fix it and re-run, and never weaken an assertion just so it passes.\nSpecs can be wrong too — when one asserts behavior that is itself incorrect,\ncorrect the spec toward the right behavior, not toward what the skill currently does.\n\n## This folder is deletable\n\nNothing in `.claude/` imports from here, and every other CCGS skill and agent works\nwithout it — but `/skill-test` and `/skill-improve` read it by path. Without it,\n`/skill-test static` still works, `/skill-test spec` and `/skill-test category`\nstop working, `/skill-test audit` reports that no catalog exists, and\n`/skill-improve` skips its category checks (the table in `README.md` has the detail).\n","studio-tests/skills/analysis/asset-audit.md":"","studio-tests/skills/analysis/balance-check.md":"","studio-tests/skills/analysis/code-review.md":"","studio-tests/skills/analysis/consistency-check.md":"","studio-tests/skills/analysis/content-audit.md":"","studio-tests/skills/analysis/estimate.md":"","studio-tests/skills/analysis/perf-profile.md":"","studio-tests/skills/analysis/scope-check.md":"","studio-tests/skills/analysis/security-audit.md":"","studio-tests/skills/analysis/tech-debt.md":"","studio-tests/skills/analysis/test-evidence-review.md":"","studio-tests/skills/analysis/test-flakiness.md":"","studio-tests/skills/authoring/architecture-decision.md":"","studio-tests/skills/authoring/art-bible.md":"","studio-tests/skills/authoring/create-architecture.md":"","studio-tests/skills/authoring/design-system.md":"","studio-tests/skills/authoring/quick-design.md":"","studio-tests/skills/authoring/ux-design.md":"","studio-tests/skills/authoring/ux-review.md":"","studio-tests/skills/gate/gate-check.md":"","studio-tests/skills/pipeline/create-control-manifest.md":"","studio-tests/skills/pipeline/create-epics.md":"","studio-tests/skills/pipeline/create-stories.md":"","studio-tests/skills/pipeline/dev-story.md":"","studio-tests/skills/pipeline/map-systems.md":"","studio-tests/skills/pipeline/propagate-design-change.md":"","studio-tests/skills/pipeline/vertical-slice.md":"","studio-tests/skills/readiness/story-done.md":"","studio-tests/skills/readiness/story-readiness.md":"","studio-tests/skills/review/architecture-review.md":"","studio-tests/skills/review/design-review.md":"","studio-tests/skills/review/review-all-gdds.md":"","studio-tests/skills/sprint/changelog.md":"","studio-tests/skills/sprint/milestone-review.md":"","studio-tests/skills/sprint/patch-notes.md":"","studio-tests/skills/sprint/retrospective.md":"","studio-tests/skills/sprint/sprint-plan.md":"","studio-tests/skills/sprint/sprint-status.md":"","studio-tests/skills/team/team-audio.md":"","studio-tests/skills/team/team-combat.md":"","studio-tests/skills/team/team-level.md":"","studio-tests/skills/team/team-live-ops.md":"","studio-tests/skills/team/team-narrative.md":"","studio-tests/skills/team/team-polish.md":"","studio-tests/skills/team/team-qa.md":"","studio-tests/skills/team/team-release.md":"","studio-tests/skills/team/team-ui.md":"","studio-tests/skills/utility/adopt.md":"","studio-tests/skills/utility/asset-spec.md":"","studio-tests/skills/utility/brainstorm.md":"","studio-tests/skills/utility/bug-report.md":"","studio-tests/skills/utility/bug-triage.md":"","studio-tests/skills/utility/day-one-patch.md":"","studio-tests/skills/utility/help.md":"","studio-tests/skills/utility/hotfix.md":"","studio-tests/skills/utility/launch-checklist.md":"","studio-tests/skills/utility/localize.md":"","studio-tests/skills/utility/onboard.md":"","studio-tests/skills/utility/playtest-report.md":"","studio-tests/skills/utility/project-stage-detect.md":"","studio-tests/skills/utility/prototype.md":"","studio-tests/skills/utility/qa-plan.md":"","studio-tests/skills/utility/regression-suite.md":"","studio-tests/skills/utility/release-checklist.md":"","studio-tests/skills/utility/reverse-document.md":"","studio-tests/skills/utility/settings.md":"","studio-tests/skills/utility/setup-engine.md":"","studio-tests/skills/utility/skill-improve.md":"","studio-tests/skills/utility/skill-test.md":"","studio-tests/skills/utility/smoke-check.md":"","studio-tests/skills/utility/soak-test.md":"","studio-tests/skills/utility/start.md":"","studio-tests/skills/utility/test-helpers.md":"","studio-tests/skills/utility/test-setup.md":""},"items":[{"name":"CLAUDE.md","path":"CLAUDE.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/CLAUDE.md","title":"Claude Agent Guidelines & System Prompt","category":"claude-rule","format":"markdown","content":"# Claude Code Game Studios -- Game Studio Agent Architecture\n\nIndie game development managed through 49 coordinated Claude Code subagents.\nEach agent owns a specific domain, enforcing separation of concerns and quality.\n\n## Technology Stack\n\n- **Engine**: [CHOOSE: Godot 4 / Unity / Unreal Engine 5]\n- **Language**: [CHOOSE: GDScript / C# / C++ / Blueprint]\n- **Version Control**: Git with trunk-based development\n- **Build System**: [SPECIFY after choosing engine]\n- **Asset Pipeline**: [SPECIFY after choosing engine]\n\n> **Note**: Engine-specialist agents exist for Godot, Unity, and Unreal with\n> dedicated sub-specialists. Use the set matching your engine.\n\n## Project Structure\n\n@.claude/docs/directory-structure.md\n\n## Engine Version Reference\n\n\n@docs/engine-reference/godot/VERSION.md\n\n\n## Technical Preferences\n\n`project.yaml` at the repo root is the primary config store — engine, specialists,\nnaming, platform, performance, modes. Skills resolve it via `resolve_config`\n(see `.claude/docs/config-resolution.md`).\n\n`.claude/docs/technical-preferences.md` is the **legacy fallback**, read on demand\nwhen a key is absent from `project.yaml`. It is not imported here: before\n`/setup-engine` runs it is almost entirely `[TO BE CONFIGURED]` placeholders, and\nafter it runs `project.yaml` holds the real values.\n\n## Coordination Rules\n\n@.claude/docs/coordination-rules.md\n\n## Collaboration Protocol\n\n**User-driven collaboration, not autonomous execution.**\nEvery task follows: **Question -> Options -> Decision -> Draft -> Approval**\n\n- Agents MUST ask \"May I write this to [filepath]?\" before using Write/Edit tools\n (exempt: `active.md` appends, agent memory, a subagent's new file at the path\n its orchestrating skill named; see `.claude/rules/agent-memory.md`)\n- Agents MUST show drafts or summaries before requesting approval\n- Multi-file changes require explicit approval for the full changeset\n- No commits without user instruction\n- A skipped or dismissed question is not an answer: act on nothing, re-ask in\n plain text and wait\n- Started outside this file's folder? Warn first: hooks, deny rules and the\n ask-first mode load only when Claude Code starts here\n\nSee `docs/COLLABORATIVE-DESIGN-PRINCIPLE.md` for full protocol and examples.\n\n> **First session?** If the project has no engine configured and no game concept,\n> run `/start` to begin the guided onboarding flow.\n\n## Coding Standards\n\n@.claude/docs/coding-standards.md\n\n## Context Management\n\nRead `.claude/docs/context-management.md` on demand — it is a reference, not\nsession context. Two of its conventions are load-bearing and cited by name\nelsewhere in the repo, so they are restated here rather than lost:\n\n- **`production/session-state/active.md` is the session checkpoint.** The file is\n the memory, not the conversation. Read it first after any compaction, crash, or\n `/clear`.\n- **Helpers in `.claude/scripts/` emit observations, never verdicts.** A script\n that scores or judges will eventually contradict a mode or override it cannot\n see. (Cited by `artifact-check.sh` and `adr-dep-graph.sh`.)\n","isInternal":false,"tokens":816,"sizeBytes":3531},{"name":"CLAUDE.md","path":"design/CLAUDE.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/design/CLAUDE.md","title":"design - Claude Agent Guidelines & System Prompt","category":"claude-rule","format":"markdown","content":"# Design Directory\n\nWhen authoring or editing files in this directory, follow these standards.\n\n## GDD Files (`design/gdd/`)\n\nThe 8 GDD sections, in order:\n1. Overview — one-paragraph summary\n2. Player Fantasy — intended feeling and experience\n3. Detailed Rules — unambiguous mechanics\n4. Formulas — all math defined with variables\n5. Edge Cases — unusual situations handled\n6. Dependencies — other systems listed\n7. Tuning Knobs — configurable values identified\n8. Acceptance Criteria — testable success conditions\n\n**How many are REQUIRED depends on `modes.workflow`** — all 8 at `full`; 5 at\n`standard` (Overview, Detailed Rules, Edge Cases, Dependencies, Acceptance\nCriteria, plus Formulas when the system has math); none at `minimal`, where\n`design/game-brief.md` is the design record instead of a GDD. Resolve the tier\nbefore flagging a section as missing — see `.claude/docs/workflow-modes.md`.\n\n> **Three other places already encode the tier rule** —\n> `.claude/docs/coding-standards.md`, `.claude/rules/design-docs.md` and\n> `.claude/hooks/validate-commit.sh`. This file is the copy a session working in\n> `design/` reads first, so it must agree with them: demanding all 8 at\n> `minimal` warns a jam project about six sections its own configuration says it\n> does not need, which trains the user to ignore the warning.\n\n**Section-name alias:** the GDD template and `/design-system` author section 3\nas `## Detailed Design`; the standard calls it **Detailed Rules**. Same required\nsection — accept either heading, never rewrite one into the other.\n\n**File naming:** `[system-slug].md` (e.g. `movement-system.md`, `combat-system.md`)\n\n**Systems index:** `design/gdd/systems-index.md` — update when adding a new GDD.\n\n**Design order:** Foundation → Core → Feature → Presentation → Polish\n\n**Validation:** Run `/design-review [path]` after authoring any GDD.\nRun `/review-all-gdds` after completing a set of related GDDs.\n\n## Quick Specs (`design/quick-specs/`)\n\nLightweight specs for tuning changes, minor mechanics, or balance adjustments.\nUse `/quick-design` to author.\n\n## UX Specs (`design/ux/`)\n\n- Per-screen specs: `design/ux/[screen-name].md`\n- HUD design: `design/ux/hud.md`\n- Interaction pattern library: `design/ux/interaction-patterns.md`\n- Accessibility requirements: `design/accessibility-requirements.md`\n\nUse `/ux-design` to author. Validate with `/ux-review` before passing to `/team-ui`.\n\n> **Accessibility requirements sit OUTSIDE `design/ux/` on purpose.** They are a\n> project-wide standard the per-screen specs consult, not a spec for one screen.\n> `.claude/docs/workflow-catalog.yaml`, the Pre-Production, Production and Polish\n> gates, and `/architecture-review` all check `design/accessibility-requirements.md`\n> at that exact path. Do not \"tidy\" it under `design/ux/` — every one of those\n> checks would stop matching, and the Technical Setup → Pre-Production gate would\n> become unpassable. `/ux-design` states the same rule at its `accessibility` mode.\n","isInternal":false,"tokens":731,"sizeBytes":3024},{"name":"CLAUDE.md","path":"docs/CLAUDE.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/docs/CLAUDE.md","title":"docs - Claude Agent Guidelines & System Prompt","category":"claude-rule","format":"markdown","content":"# Docs Directory\n\nWhen authoring or editing files in this directory, follow these standards.\n\n## Architecture Decision Records (`docs/architecture/`)\n\nUse the ADR template: `.claude/docs/templates/architecture-decision-record.md`\n\n**Required sections:** Title, Status, Context, Decision, Consequences,\nADR Dependencies, Engine Compatibility, GDD Requirements Addressed\n\n**Status lifecycle:** `Proposed` → `Accepted` → `Superseded`\n- Never skip `Accepted` — stories referencing a `Proposed` ADR are auto-blocked\n- Use `/architecture-decision` to create ADRs through the guided flow\n\n**TR Registry:** `docs/architecture/tr-registry.yaml`\n- Stable requirement IDs (e.g. `TR-movement-001`) that link GDD requirements to stories\n- Never renumber existing IDs — only append new ones\n- Updated by `/architecture-review` Phase 8\n\n**Control Manifest:** `docs/architecture/control-manifest.md`\n- Flat programmer rules sheet: Required / Forbidden / Guardrails per layer\n- Date-stamped `Manifest Version:` in header\n- Stories embed this version; `/story-done` checks for staleness\n\n**Validation:** Run `/architecture-review` after completing a set of ADRs.\n\n## Engine Reference (`docs/engine-reference/`)\n\nVersion-pinned engine API snapshots. **Always check here before using any\nengine API** — the LLM's training data predates the pinned engine version.\n\nCurrent engine: see `docs/engine-reference//VERSION.md` (`` is `godot`, `unity` or `unreal`, matching `engine.name` in `project.yaml`)\n","isInternal":false,"tokens":343,"sizeBytes":1505},{"name":"CLAUDE.md","path":"src/CLAUDE.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/src/CLAUDE.md","title":"src - Claude Agent Guidelines & System Prompt","category":"claude-rule","format":"markdown","content":"# Source Directory\n\nWhen writing or editing game code in this directory, follow these standards.\n\n## Engine Version Warning\n\nThe LLM's training data predates the pinned engine version.\n**Always check `docs/engine-reference/` before using any engine API.**\nDo not guess at post-cutoff API signatures — look them up first.\n\n## Coding Standards\n\n- All public APIs require doc comments\n- Gameplay values must be **data-driven** (external config files), never hardcoded\n- Prefer dependency injection over singletons for testability\n- Architecture decisions go in `docs/architecture/` as ADRs — **how many depends on\n `modes.workflow`**: all at `full`, critical only at `standard`, none required at\n `minimal` (the decision log carries them)\n- Commits must reference the relevant story ID or design document\n\n## File Routing\n\nMatch the engine-specialist agent to the file type being written.\n`/setup-engine` records which specialist handles code, shaders and UI in the\n`specialists` block of `project.yaml`.\n\nWhen in doubt, use `specialists.code` from `project.yaml`.\n\n## Tests\n\nTests live in `tests/` — not in `src/`.\nRun `/test-setup` to scaffold the test framework if it doesn't exist yet.\nEvery gameplay system should have unit tests covering its formulas and edge cases.\n\n## Verification-Driven Development\n\nWrite tests first when adding gameplay systems.\nFor UI changes, verify with screenshots.\nCompare expected output to actual output before marking work complete.\n","isInternal":false,"tokens":314,"sizeBytes":1475},{"name":"CLAUDE.md","path":"studio-tests/CLAUDE.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/studio-tests/CLAUDE.md","title":"studio-tests - Claude Agent Guidelines & System Prompt","category":"claude-rule","format":"markdown","content":"# Studio Tests — Claude Instructions\n\nThis folder is the quality assurance layer for the Claude Code Game Studios skill/agent\nframework. It is self-contained and separate from any game project.\n\n## Key files\n\n| File | Purpose |\n|------|---------|\n| `catalog.yaml` | Master registry for all 74 skills and 49 agents. Contains category, spec path, and last-test tracking fields. Always read this first when running any test command. |\n| `quality-rubric.md` | Category-specific pass/fail metrics. Read the matching `###` section for the skill's category when running `/skill-test category`. |\n| `skills/[category]/[name].md` | Behavioral spec for a skill — 5 or more test cases + protocol compliance assertions. |\n| `agents/[tier]/[name].md` | Behavioral spec for an agent — 5 or more test cases + protocol compliance assertions. |\n| `templates/skill-test-spec.md` | Template for writing new skill spec files. |\n| `templates/agent-test-spec.md` | Template for writing new agent spec files. |\n| `results/` | Written by `/skill-test spec` when results are saved. Not gitignored — add it to `.gitignore` to keep results out of commits. |\n\n## Path conventions\n\n- Skill specs: `studio-tests/skills/[category]/[name].md`\n- Agent specs: `studio-tests/agents/[tier]/[name].md`\n- Catalog: `studio-tests/catalog.yaml`\n- Rubric: `studio-tests/quality-rubric.md`\n\nThe `spec:` field in `catalog.yaml` is the authoritative path for each skill/agent spec.\nAlways read it rather than guessing the path.\n\n## Skill categories\n\n```\ngate → gate-check\nreview → design-review, architecture-review, review-all-gdds\nauthoring → design-system, quick-design, architecture-decision, art-bible,\n create-architecture, ux-design, ux-review\nreadiness → story-readiness, story-done\npipeline → create-epics, create-stories, dev-story, create-control-manifest,\n propagate-design-change, map-systems, vertical-slice\nanalysis → consistency-check, balance-check, content-audit, code-review,\n tech-debt, scope-check, estimate, perf-profile, asset-audit,\n security-audit, test-evidence-review, test-flakiness\nteam → team-combat, team-narrative, team-audio, team-level, team-ui,\n team-qa, team-release, team-polish, team-live-ops\nsprint → sprint-plan, sprint-status, milestone-review, retrospective,\n changelog, patch-notes\nutility → all remaining skills\n```\n\n## Agent tiers\n\n```\ndirectors → creative-director, technical-director, producer, art-director\nleads → lead-programmer, narrative-director, audio-director, game-designer,\n systems-designer, level-designer, qa-lead\nspecialists → gameplay-programmer, engine-programmer, network-programmer,\n ai-programmer, tools-programmer, ui-programmer, ux-designer,\n technical-artist, sound-designer, performance-analyst, prototyper,\n writer, world-builder\nengine/godot → godot-specialist, godot-gdscript-specialist, godot-csharp-specialist,\n godot-shader-specialist, godot-gdextension-specialist\nengine/unity → unity-specialist, unity-ui-specialist, unity-shader-specialist,\n unity-dots-specialist, unity-addressables-specialist\nengine/unreal → unreal-specialist, ue-gas-specialist, ue-replication-specialist,\n ue-umg-specialist, ue-blueprint-specialist\noperations → devops-engineer, release-manager, live-ops-designer,\n community-manager, analytics-engineer, economy-designer,\n localization-lead\nqa → qa-tester, security-engineer, accessibility-specialist\n```\n\nA tier is the directory a spec lives in. The rubric category is the agent's\n`category:` in `catalog.yaml` and can differ: `security-engineer` and\n`accessibility-specialist` sit in `qa/` but are rated as `specialist`.\n\n## Workflow for testing a skill or agent\n\n1. Read `catalog.yaml` to get the `spec:` path and `category:` — from the\n `skills:` entry for a skill, the `agents:` entry for an agent\n2. Read the skill at `.claude/skills/[name]/SKILL.md` and every file in its\n `references/` folder, or the agent at `.claude/agents/[name].md`\n3. Read the project `CLAUDE.md` and the files it imports with `@`: every\n subagent receives them, so a rule stated there (for example a redirect in\n `coordination-rules.md`) counts as the skill's or agent's own\n4. Read the spec at the `spec:` path\n5. Evaluate the spec's Static Assertions, each case's assertions, and its\n Protocol Compliance list\n6. Offer to write results to `results/` and update `catalog.yaml`\n\n## Fixture defaults\n\nEvery skill spec has a `## Fixture Defaults` section above its cases. A case's\nsandbox project starts from this `project.yaml` block:\n\n```yaml\nmodes:\n rigor: minimal # → workflow minimal, docs.density terse, qa.level minimal,\n # story_granularity coarse, review_mode solo, team.size individual\n automation: collaborative\n```\n\n- A setting the case's Fixture names wins over the block, and an explicit\n sub-knob (`modes.workflow`, `modes.review_mode`, `qa.level`, …) wins over the\n `rigor` preset (`.claude/docs/config-resolution.md` § Defaults).\n- A case that says `project.yaml` sets no `modes` keys, or that there is no\n `project.yaml`, runs without the block: it tests the unset defaults.\n- There is no `project.local.yaml` unless the case names one.\n- A case whose expected behaviour changes with a setting pins that setting in\n its own Fixture, with the reason — e.g. `modes.workflow: standard` (pinned:\n unset resolves to minimal, which recommends the next build instead of a\n sprint).\n\nThe block is pinned so that a change to the framework's defaults cannot\nsilently change what a case tests. A spec may set a different default in its\nown section when most of its cases need one.\n\n## Workflow for improving a skill\n\nUse `/skill-improve [name]`. It handles the full loop:\ntest → diagnose → propose fix → rewrite → retest → keep or revert.\n\n## Spec validity note\n\nSpecs in this folder assert the **correct** behavior, not whatever a skill or agent\ndoes today. A failing assertion means the skill or agent is wrong until shown\notherwise: fix it and re-run, and never weaken an assertion just so it passes.\nSpecs can be wrong too — when one asserts behavior that is itself incorrect,\ncorrect the spec toward the right behavior, not toward what the skill currently does.\n\n## This folder is deletable\n\nNothing in `.claude/` imports from here, and every other CCGS skill and agent works\nwithout it — but `/skill-test` and `/skill-improve` read it by path. Without it,\n`/skill-test static` still works, `/skill-test spec` and `/skill-test category`\nstop working, `/skill-test audit` reports that no catalog exists, and\n`/skill-improve` skips its category checks (the table in `README.md` has the detail).\n","isInternal":false,"tokens":1635,"sizeBytes":6961},{"name":"agent-memory.md","path":".claude/rules/agent-memory.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/rules/agent-memory.md","title":"Rules Skill","category":"anthropic-skill","format":"markdown","content":"---\npaths:\n - \".claude/agent-memory/**\"\n---\n\n# Agent Memory Rules\n\n**Agent memory is one of three writes that need no \"May I write?\"** The other two\nare named in `CLAUDE.md`:\n\n- **Appends to `production/session-state/active.md`** — the session checkpoint\n the hooks and the next session rely on. An append, never a rewrite of what is\n already there.\n- **A subagent's new file at the path its orchestrating skill named.** Only a\n new file under `production/`, `docs/` or `tests/`, only at a path the skill's\n prompt names (never one you chose), and only inside a phase the user approved.\n\n`.claude/agent-memory/` is gitignored, per-agent, and never ships. Its exemption\nexists because the memory is the agent's own working notes about how to do its\njob, not a project artifact.\n\nNone of the three extends anywhere else. The Collaboration Protocol still governs\nevery other write under the code root (`src/`, `Assets/` or `Source/`),\n`design/`, `docs/`, `production/` and `assets/`: ask first, naming the path.\nWriting a memory is never a substitute for asking, and a memory must never be\nused to record something the user declined to have written.\n\n## Never record a temporary absence as a durable fact\n\nThis is the failure this file exists to prevent, and this repo is unusually\nexposed to it.\n\n**CCGS ships as a template the user clones *as their game*.** So on day one every\nagent observes the same things — no game code, no GDDs, no engine configured, no\n`tests/performance/` — and every one of those observations is **guaranteed to\nstop being true**. A memory reading *\"this repo is the framework, not a game;\nperf requests have no target\"* is accurate when written and actively harmful two\nweeks later, when it tells a future run to return BLOCKED on a project that now\nhas a build. The agent will not re-derive it; that is what memory is for.\n\nSo:\n\n- **Prefer recording a method over a state.** \"Confirm an engine project and a\n captured profile exist before profiling; return BLOCKED naming what is missing\n rather than estimating\" is durable. \"There is no game here\" is a timestamp.\n- **If you must record a state, state what invalidates it**, on the same line:\n `INVALIDATED WHEN: project.yaml declares an engine, or the code root (src/, Assets/ or Source/) contains game code.`\n A reader with no other context must be able to tell whether the note still\n holds.\n- **Never record absence of a game, of assets, of tests or of config as a\n settled property of the project.** Those are the states CCGS exists to move a\n user out of.\n\n## Disclose the write\n\nSay in your response that you recorded a memory and where. An unmentioned write\nis indistinguishable from no write, and the user cannot correct a note they do\nnot know exists — the same reason a skipped check has to announce itself\n(`.claude/rules/skill-authoring.md`, obligation 3).\n\n## Verify before you trust\n\nA recalled memory reflects what was true when it was written. If it names a file,\na path, a setting or a count, **check that it still holds before acting on it**.\nMemory is a starting point for investigation, never evidence.\n","frontmatter":{"paths":[".claude/agent-memory/**"]},"isInternal":false,"tokens":755,"sizeBytes":3121},{"name":"ai-code.md","path":".claude/rules/ai-code.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/rules/ai-code.md","title":"Rules Skill","category":"anthropic-skill","format":"markdown","content":"---\npaths:\n - \"src/ai/**\"\n - \"Assets/**/{AI,Ai,ai}/**/*.cs\"\n - \"Source/**/{AI,Ai,ai}/**/*.{h,cpp}\"\n---\n\n# AI Code Rules\n\n- AI update budget: 2ms per frame maximum — profile to verify\n- All AI parameters must be tunable from data files (behavior tree weights, perception ranges, timers)\n- AI must be debuggable: implement visualization hooks for all AI state (paths, perception cones, decision trees)\n- AI should telegraph intentions — players need time to read and react\n- Prefer utility-based or behavior tree approaches over hard-coded if/else chains\n- Group AI must support formation, flanking, and role assignment from data\n- All AI state machines must log transitions for debugging\n- Never trust AI input from the network without validation\n","frontmatter":{"paths":["src/ai/**","Assets/**/{AI,Ai,ai}/**/*.cs","Source/**/{AI,Ai,ai}/**/*.{h,cpp}"]},"isInternal":false,"tokens":180,"sizeBytes":753},{"name":"data-files.md","path":".claude/rules/data-files.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/rules/data-files.md","title":"Rules Skill","category":"anthropic-skill","format":"markdown","content":"---\npaths:\n - \"assets/data/**/*.json\"\n - \"Assets/**/{Data,data}/**/*.json\"\n - \"Content/**/{Data,data}/**/*.json\"\n---\n\n# Data File Rules\n\n- All JSON files must be valid JSON — broken JSON blocks the entire build pipeline\n- File naming: lowercase with underscores only, following `[system]_[name].json` pattern\n- Every data file must have a documented schema (either JSON Schema or documented in the corresponding design doc)\n- Numeric values must include comments or companion docs explaining what the numbers mean\n- Use consistent key naming: **`snake_case` for keys within JSON files**, matching\n the `[system]_[name].json` file convention one line above and the engine idiom\n every other standard in this repo uses.\n\n > **On Unity and Unreal this costs you a mapping layer — budget for it rather\n > than changing the keys.** `JsonUtility` binds by *exact field name*, and C#\n > fields are `camelCase` per `naming.variables`, so a snake_case file cannot bind\n > directly to the type that consumes it. Use a private nested DTO whose fields\n > are the wire format and which maps once into your real type, or take a\n > dependency that supports a naming policy (Newtonsoft `SnakeCaseNamingStrategy`,\n > `System.Text.Json` `JsonNamingPolicy`). Do **not** switch the file to camelCase\n > to avoid the DTO: keys are the cross-engine contract. Write the DTO and\n > document it as a wire-format boundary — that is the intended shape.\n- No orphaned data entries — every entry must be referenced by code or another data file\n- Version data files when making breaking schema changes\n- Include sensible defaults for all optional fields\n\n## Examples\n\n**Correct** naming and structure (`combat_enemies.json`):\n\n```json\n{\n \"goblin\": {\n \"base_health\": 50,\n \"base_damage\": 8,\n \"move_speed\": 3.5,\n \"loot_table\": \"loot_goblin_common\"\n },\n \"goblin_chief\": {\n \"base_health\": 150,\n \"base_damage\": 20,\n \"move_speed\": 2.8,\n \"loot_table\": \"loot_goblin_rare\"\n }\n}\n```\n\n**Incorrect** (`EnemyData.json`):\n\n```json\n{\n \"Goblin\": { \"hp\": 50 }\n}\n```\n\nViolations: uppercase filename, uppercase key, no `[system]_[name]` pattern, missing required fields.\n","frontmatter":{"paths":["assets/data/**/*.json","Assets/**/{Data,data}/**/*.json","Content/**/{Data,data}/**/*.json"]},"isInternal":false,"tokens":547,"sizeBytes":2172},{"name":"design-docs.md","path":".claude/rules/design-docs.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/rules/design-docs.md","title":"Rules Skill","category":"anthropic-skill","format":"markdown","content":"---\npaths:\n - \"design/gdd/**\"\n---\n\n# Design Document Rules\n\n- The 8 GDD sections are: Overview, Player Fantasy, Detailed Rules, Formulas, Edge Cases, Dependencies, Tuning Knobs, Acceptance Criteria\n- **How many are required depends on `modes.workflow`** — all 8 at `full`, 5 (+ Formulas when the system **defines numeric rules**: rates, curves, thresholds, costs, damage, drop weights — anything a balance pass would tune) at `standard`, none at `minimal` (the design record there is `design/game-brief.md`). Resolve the tier before flagging a section as missing; see `.claude/docs/workflow-modes.md`\n- **The Formulas test is what the system defines, not what it is called.** A system's `Category` in `systems-index.md` is a hint — `Gameplay`, `Economy` and `Progression` almost always qualify — never the test. Do not gate Formulas on a category token: the categories `/map-systems` writes (`Core · Gameplay · Progression · Economy · Persistence · UI · Audio · Narrative · Meta`) do not include `combat` or `AI`, which are example systems *within* `Gameplay`. Every site stating this rule must state the same test.\n- **Section-name alias**: The GDD template and `/design-system` author this section as `## Detailed Design`; the design standard calls it **Detailed Rules**. These are the SAME required section — accept either heading and never rewrite one into the other.\n- Formulas must include variable definitions, expected value ranges, and example calculations\n- Edge cases must explicitly state what happens, not just \"handle gracefully\"\n- Dependencies must be bidirectional — if system A depends on B, B's doc must mention A\n- Tuning knobs must specify safe ranges and what gameplay aspect they affect\n- Acceptance criteria must be testable — a QA tester must be able to verify pass/fail\n- No hand-waving: \"the system should feel good\" is not a valid specification\n- Balance values must link to their source formula or rationale\n- Design documents MUST be written incrementally: create skeleton first, then fill\n each section one at a time with user approval between sections. Write each\n approved section to the file immediately to persist decisions and manage context\n","frontmatter":{"paths":["design/gdd/**"]},"isInternal":false,"tokens":492,"sizeBytes":2202},{"name":"engine-code.md","path":".claude/rules/engine-code.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/rules/engine-code.md","title":"Rules Skill","category":"anthropic-skill","format":"markdown","content":"---\npaths:\n - \"src/core/**\"\n - \"Assets/**/{Core,core}/**/*.cs\"\n - \"Source/**/{Core,core}/**/*.{h,cpp}\"\n---\n\n# Engine Code Rules\n\n- ZERO allocations in hot paths (update loops, rendering, physics) — pre-allocate, pool, reuse\n- All engine APIs must be thread-safe OR explicitly documented as single-thread-only\n- Profile before AND after every optimization — document the measured numbers\n- Engine code must NEVER depend on gameplay code (strict dependency direction: engine <- gameplay)\n- Every public API must have usage examples in its doc comment\n- Changes to public interfaces require a deprecation period and migration guide\n- Use RAII / deterministic cleanup for all resources\n- All engine systems must support graceful degradation\n- Before writing engine API code, consult `docs/engine-reference/` for the current engine version and verify APIs against the reference docs\n\n## Examples\n\n**Correct** (zero-alloc hot path) — Godot:\n\n```gdscript\n# Pre-allocated array reused each frame\nvar _nearby_cache: Array[Node3D] = []\n\nfunc _physics_process(delta: float) -> void:\n _nearby_cache.clear() # Reuse, don't reallocate\n _spatial_grid.query_radius(position, radius, _nearby_cache)\n```\n\nUnity:\n\n```csharp\nprivate readonly Collider[] _nearbyCache = new Collider[64]; // allocated once\n\nvoid FixedUpdate()\n{\n int count = Physics.OverlapSphereNonAlloc(transform.position, radius, _nearbyCache);\n}\n```\n\nUnreal:\n\n```cpp\n// TArray member, reserved once; Reset() keeps the allocation\nvoid UProximityComponent::TickComponent(float DeltaTime, ELevelTick TickType,\n FActorComponentTickFunction* ThisTickFunction)\n{\n NearbyCache.Reset();\n SpatialGrid->QueryRadius(GetComponentLocation(), Radius, NearbyCache);\n}\n```\n\n**Incorrect** (allocating in hot path):\n\n```gdscript\nfunc _physics_process(delta: float) -> void:\n var nearby: Array[Node3D] = [] # VIOLATION: allocates every frame\n nearby = get_tree().get_nodes_in_group(\"enemies\") # VIOLATION: tree query every frame\n```\n","frontmatter":{"paths":["src/core/**","Assets/**/{Core,core}/**/*.cs","Source/**/{Core,core}/**/*.{h,cpp}"]},"isInternal":false,"tokens":479,"sizeBytes":2035},{"name":"gameplay-code.md","path":".claude/rules/gameplay-code.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/rules/gameplay-code.md","title":"Rules Skill","category":"anthropic-skill","format":"markdown","content":"---\npaths:\n - \"src/gameplay/**\"\n - \"Assets/**/{Gameplay,gameplay}/**/*.cs\"\n - \"Source/**/{Gameplay,gameplay}/**/*.{h,cpp}\"\n---\n\n# Gameplay Code Rules\n\n- ALL gameplay values MUST come from external config/data files, NEVER hardcoded\n- Use delta time for ALL time-dependent calculations (frame-rate independence)\n- NO direct references to UI code — use events for cross-system communication\n (Godot signals, C# events, Unreal delegates)\n- Every gameplay system must implement a clear interface\n- State machines must have explicit transition tables with documented states\n- Write unit tests for all gameplay logic — separate logic from presentation\n- Document which design doc each feature implements in code comments\n- No static singletons for game state — use dependency injection\n\n## Examples\n\n**Correct** (data-driven) — Godot:\n\n```gdscript\nvar damage: float = config.get_value(\"combat\", \"base_damage\", 10.0)\nvar speed: float = stats_resource.movement_speed * delta\n```\n\nUnity (values from a ScriptableObject):\n\n```csharp\nfloat damage = combatConfig.BaseDamage;\nfloat speed = stats.MovementSpeed * Time.deltaTime;\n```\n\nUnreal (values from a data asset):\n\n```cpp\nconst float Damage = CombatConfig->BaseDamage;\nconst float Speed = Stats->MovementSpeed * DeltaTime;\n```\n\n**Incorrect** (hardcoded):\n\n```gdscript\nvar damage: float = 25.0 # VIOLATION: hardcoded gameplay value\nvar speed: float = 5.0 # VIOLATION: not from config, not using delta\n```\n","frontmatter":{"paths":["src/gameplay/**","Assets/**/{Gameplay,gameplay}/**/*.cs","Source/**/{Gameplay,gameplay}/**/*.{h,cpp}"]},"isInternal":false,"tokens":346,"sizeBytes":1464},{"name":"narrative.md","path":".claude/rules/narrative.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/rules/narrative.md","title":"Rules Skill","category":"anthropic-skill","format":"markdown","content":"---\npaths:\n - \"design/narrative/**\"\n---\n\n# Narrative Rules\n\n- All new lore must be cross-referenced against existing lore for contradictions\n- Every lore entry must specify canon level: Established / Provisional / Under Review\n- Character dialogue must match the voice profile defined for that character\n- World rules (what is possible/impossible) must be explicitly documented and consistent\n- Mysteries must have documented \"true answers\" even if players never learn them\n- Faction motivations, relationships, and power structures must be internally logical\n- All narrative text must be localization-ready: no idioms that don't translate, named placeholders for variables\n- No line of dialogue should exceed 120 characters for dialogue box constraints\n","frontmatter":{"paths":["design/narrative/**"]},"isInternal":false,"tokens":148,"sizeBytes":755},{"name":"network-code.md","path":".claude/rules/network-code.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/rules/network-code.md","title":"Rules Skill","category":"anthropic-skill","format":"markdown","content":"---\npaths:\n - \"src/networking/**\"\n - \"Assets/**/{Networking,networking,Network,network}/**/*.cs\"\n - \"Source/**/{Networking,networking,Network,network}/**/*.{h,cpp}\"\n---\n\n# Network Code Rules\n\n- Server is AUTHORITATIVE for all gameplay-critical state — never trust the client\n- All network messages must be versioned for forward/backward compatibility\n- Client predicts locally, reconciles with server — implement rollback for mispredictions\n- Handle disconnection, reconnection, and host migration gracefully\n- Rate-limit all network logging to prevent log flooding\n- All networked values must specify replication strategy: reliable/unreliable, frequency, interpolation\n- Bandwidth budget: define and track per-message-type bandwidth usage\n- Security: validate all incoming packet sizes and field ranges\n","frontmatter":{"paths":["src/networking/**","Assets/**/{Networking,networking,Network,network}/**/*.cs","Source/**/{Networking,networking,Network,network}/**/*.{h,cpp}"]},"isInternal":false,"tokens":174,"sizeBytes":811},{"name":"prototype-code.md","path":".claude/rules/prototype-code.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/rules/prototype-code.md","title":"Rules Skill","category":"anthropic-skill","format":"markdown","content":"---\npaths:\n - \"prototypes/**\"\n---\n\n# Prototype Code Standards (Relaxed)\n\nPrototypes are throwaway code for validating ideas. Standards are intentionally\nrelaxed to maximize iteration speed. The goal is learning, not production quality.\n\n## What's Allowed in Prototypes\n- Hardcoded values (no need for data-driven config)\n- Minimal or no doc comments\n- Simple architecture (no dependency injection required)\n- Singletons and global state\n- Copy-pasted code (no need for abstraction)\n- Debug output left in place\n- Placeholder art and audio\n- Quick-and-dirty solutions\n\n## What's Still Required\n- Each prototype lives in its own subdirectory: `prototypes/[name]/`\n- Every prototype MUST have a `README.md` with:\n - What hypothesis is being tested\n - How to run the prototype\n - Current status (in-progress / concluded)\n - Findings (updated when prototype concludes)\n- No production code may reference or import from `prototypes/`\n- Prototypes must not modify files outside `prototypes/`\n- Prototypes must not be deployed or shipped\n\n## When a Prototype Succeeds\nIf a prototype validates a concept and the feature moves to production:\n1. The prototype code is NOT migrated directly — it is rewritten to production standards\n2. The prototype `README.md` findings inform the production design document\n3. The prototype directory is preserved for reference but never extended\n\n## Cleanup\nConcluded prototypes should be archived or deleted after findings are captured.\nNever let prototype code grow into production code through incremental \"cleanup.\"\n","frontmatter":{"paths":["prototypes/**"]},"isInternal":false,"tokens":326,"sizeBytes":1551},{"name":"scene-files.md","path":".claude/rules/scene-files.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/rules/scene-files.md","title":"Rules Skill","category":"anthropic-skill","format":"markdown","content":"---\npaths:\n - \"**/*.tscn\"\n - \"**/*.tres\"\n - \"**/*.unity\"\n - \"**/*.prefab\"\n - \"Assets/**/*.asset\"\n---\n\n# Scene and Asset File Rules\n\nThe engine's editor writes these files. A hand edit that breaks one can stop a\nscene loading, or drop references without an error. Change them in the editor\nwhen you can.\n\n## Godot (`.tscn`, `.tres`, `.uid`)\n\nWhen you edit the text by hand:\n\n- Never change the `format=` value in the `[gd_scene]` or `[gd_resource]` header.\n- Never reuse an `id`: every `[ext_resource]` and `[sub_resource]` id is unique in its file.\n- Never copy a node block with its `unique_id=` (Godot 4.6+). Drop it from the copy.\n- Never invent a `uid://` value. Leave `uid=` off a new reference and let the\n editor or `godot --headless --path . --import` assign it.\n- Never hand-edit TileMapLayer or GridMap cell data. It is encoded, so change it in the editor.\n- Never edit or delete a `.uid` file, and commit it with its script or shader.\n Godot 4.4+ writes one beside each; when you move or rename the script or\n shader outside the editor, move its `.uid` with it.\n- After a hand edit, run `godot --headless --path . --import` and open or run\n the scene once to confirm it loads without errors.\n\n## Unity (`.unity`, `.prefab`, `.asset`)\n\n- Never hand-edit `.unity`, `.prefab` or `.asset` YAML while a Unity Editor is\n reachable: open on this project, or reachable through its command-line or MCP\n tools. The Editor holds its own copy, and its next save can overwrite or\n conflict with the edit. Make the change through the Editor, or hand the user\n the steps. If you cannot tell whether an Editor is reachable, treat it as reachable.\n- With no Editor reachable, keep every `fileID` and `guid` reference intact,\n never invent a GUID, never edit or delete a `.meta` file, and open the scene\n in the Editor afterwards to confirm it loads.\n","frontmatter":{"paths":["**/*.tscn","**/*.tres","**/*.unity","**/*.prefab","Assets/**/*.asset"]},"isInternal":false,"tokens":496,"sizeBytes":1859},{"name":"shader-code.md","path":".claude/rules/shader-code.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/rules/shader-code.md","title":"Rules Skill","category":"anthropic-skill","format":"markdown","content":"---\npaths:\n - \"assets/shaders/**\"\n - \"**/*.gdshader\"\n - \"Assets/**/*.{shader,hlsl,cginc,compute,shadergraph}\"\n - \"Shaders/**\"\n - \"**/*.{usf,ush}\"\n---\n\n# Shader Code Standards\n\nAll shader files, in every engine, must follow these standards to maintain\nvisual quality, performance, and cross-platform compatibility.\n\n## Naming Conventions\n- File naming: `[type]_[category]_[name].[ext]`\n - `spatial_env_water.gdshader` (Godot)\n - `SG_Env_Water` (Unity Shader Graph)\n - `M_Env_Water` (Unreal Material)\n- Use descriptive names that indicate the material purpose\n- Prefix with the engine's shader type — Godot `spatial_`, `canvas_`, `particles_`,\n `post_`; Unity `SG_` (Shader Graph); Unreal `M_`, `MI_` (instance), `MF_` (function)\n\n## Code Quality\n- All uniforms/parameters must have descriptive names and appropriate hints\n- Group related parameters (Godot: `group_uniforms`, Unity: `[Header]`, Unreal: Category)\n- Comment non-obvious calculations (especially math-heavy sections)\n- No magic numbers — use named constants or documented uniform values\n- Include authorship and purpose comment at the top of each shader file\n\n## Performance Requirements\n- Document the target platform and complexity budget for each shader\n- Use appropriate precision: `half`/`mediump` on mobile where full precision isn't needed\n- Minimize texture samples in fragment shaders\n- Avoid dynamic branching in fragment shaders — use `step()`, `smoothstep()` and\n `mix()` (Godot, GLSL) or `lerp()` (HLSL: Unity, Unreal)\n- No texture reads inside loops\n- Two-pass approach for blur effects (horizontal then vertical)\n\n## Cross-Platform\n- Test shaders on minimum spec target hardware\n- Provide fallback/simplified versions for lower quality tiers\n- Document which render pipeline the shader targets (Forward/Deferred, URP/HDRP, Forward+/Mobile/Compatibility)\n- Do not mix shaders from different render pipelines in the same directory\n\n## Variant Management\n- Minimize shader variants — each variant is a separate compiled shader\n- Document all keywords/variants and their purpose\n- Use feature stripping where possible to reduce build size\n- Log and monitor total variant count per shader\n","frontmatter":{"paths":["assets/shaders/**","**/*.gdshader","Assets/**/*.{shader,hlsl,cginc,compute,shadergraph}","Shaders/**","**/*.{usf,ush}"]},"isInternal":false,"tokens":520,"sizeBytes":2179},{"name":"skill-authoring.md","path":".claude/rules/skill-authoring.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/rules/skill-authoring.md","title":"Rules Skill","category":"anthropic-skill","format":"markdown","content":"---\npaths:\n - \".claude/skills/**\"\n - \".claude/agents/**\"\n---\n\n# Skill and Gate Authoring\n\n**A check that cannot report that it did not run is not a check.**\n\nThe same shape recurs across unrelated subsystems, so treat it as the default\nrisk in any check you write, not as an unusual mistake.\n\nThe failure is always the same trade: a step that could not run produces output\nindistinguishable from a step that ran and found nothing. Nobody reading the\noutput can tell which happened, and the permissive reading is the one that gets\nbelieved, because it is the one that lets work proceed.\n\n## The five obligations\n\n### 1. Every gating verdict needs a \"could not assess\" value\n\nIf a skill emits a verdict something else depends on, its vocabulary must include\none — `NOT ASSESSED`, or the local equivalent — and the report must say *which*\nof the reasons applied. A vocabulary of three confident verdicts forces every\nunknown into a claim.\n\n**Rank it deliberately.** It must outrank the pass value: a run that could not\nassess part of its scope has not established that the scope is good. It must\n**not** outrank the failure values: a known problem is more actionable than an\nunknown, and demoting a real failure behind an access problem buries it.\n\n**`NOT ASSESSED` is not a gentler failure verdict.** \"I looked and found nothing\"\nand \"I could not look\" have different fixes — one needs work done, the other\nneeds access granted or an input classified. Collapsing them sends the reader to\nthe wrong fix.\n\n### 2. An absent value may not default to the permissive one\n\nEspecially when **nothing in the framework writes that key**. Before defaulting,\ncheck who sets it: a key with a reader and no writer takes its default branch on\nevery project that ever runs, so that branch is not an edge case — it is the\nbehaviour.\n\nOver-running a check costs minutes. Under-running one ships the category unrun.\n\n### 3. A skipped step announces itself\n\nIn the output, not only in the source. If a phase, category, or agent did not run\n— wrong engine, missing config, unavailable input, a `team.size` that collapses\nthe pipeline — the artifact must say so by name. A silent skip and a successful\none are the same artifact.\n\nA rule enforced in the body and never surfaced in the output is, to the reader,\nidentical to no rule at all.\n\n### 4. Never assert what you cannot source — and wire the gap to the verdict\n\nWhere this repo pins external facts (`docs/engine-reference/**`), do not fill a\ngap from training data. Write the gap down instead: `NOT SOURCEABLE — is\nnot covered by `.\n\n**Flagging alone is not enough.** A named gap that does not reach the verdict is\njust a comment. Wire it: a category with no sourced inputs must force obligation\n1's value, so the gap makes the pass unreachable rather than sitting beside it.\n\nA confidently wrong pattern list is worse than an absent one — it produces a scan\nthat looks thorough, finds nothing, and reads as a pass.\n\n### 5. Gates derive their covered set; they do not enumerate it\n\nAn allowlist pins what was known when it was written and is silent about\neverything added since. Derive the set from what the repo actually contains, so a\nnew skill or agent cannot ship outside coverage by simply not being on a list.\n\n**If the category is not mechanically crisp, say so in the gate and keep the\nlist.** A gate that fires on forty files does not get fixed, it gets muted — and\na muted gate is worse than a narrow one, because it reads as coverage. When you\nkeep a list, record *why* derivation failed and state the obligation to extend it.\n\nTwo further gate rules:\n\n- **Assert something that cannot be true by accident.** A check for the word\n \"unity\" is satisfied by a file path, and case-insensitively by \"community\".\n Assert a distinctive token instead.\n- **A gate you have not watched fail is not a gate.** Break the thing it guards,\n confirm it fails, restore. One mutation per tool invocation — a batch that\n times out leaves the repo holding a broken file, and `trap … EXIT` does not\n survive `SIGTERM`.\n\n## The test to apply\n\nBefore shipping a skill or gate, ask: **if this step silently did not run, what\nwould the output look like?**\n\nIf the answer is \"the same\", it is not finished.\n","frontmatter":{"paths":[".claude/skills/**",".claude/agents/**"]},"isInternal":false,"tokens":993,"sizeBytes":4268},{"name":"test-standards.md","path":".claude/rules/test-standards.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/rules/test-standards.md","title":"Rules Skill","category":"anthropic-skill","format":"markdown","content":"---\npaths:\n - \"tests/**\"\n - \"Assets/Tests/**/*.cs\"\n - \"Source/**/Tests/**/*.{h,cpp}\"\n---\n\n# Test Standards\n\n- Test naming follows the engine's language — every name says the scenario and\n the expected result:\n - **Godot (gdUnit4):** file `[system]_[feature]_test.gd`, function\n `test_[scenario]_[expected]`\n - **Unity (NUnit):** class `[System]Tests` in a file of the same name, method\n `[Scenario]_[Expected]` in PascalCase\n - **Unreal (Automation):** class `F[System][Scenario]Test` — one per test:\n each `IMPLEMENT_SIMPLE_AUTOMATION_TEST` defines its class, so a second test\n reusing a name fails to link — test name\n `.[System].[Scenario]` — the project's test command,\n `Automation RunTests .`, runs every test whose name contains\n `.` (a substring match, not a prefix). `.` is the root\n that filter in `commands.test` uses: the project name, or the distinct root\n `/setup-engine` chose when the project's name is also an engine area\n (`Audio`, `Core`, `Input`, …) — name tests under whichever it is\n- Every test must have a clear arrange/act/assert structure\n- Unit tests must not depend on external state (filesystem, network, database)\n- Integration tests must clean up after themselves\n- Performance tests must specify acceptable thresholds and fail if exceeded\n- Test data must be defined in the test or in dedicated fixtures, never shared mutable state\n- Mock external dependencies — tests should be fast and deterministic\n- Every bug fix must have a regression test that would have caught the original bug —\n and **you must watch it fail before you trust it.** Run the new test against the\n unfixed code, confirm it fails, then apply the fix and confirm it passes. A\n regression test that has only ever been seen passing is not known to test anything.\n\n > This is `.claude/rules/skill-authoring.md`'s \"a gate you have not watched fail\n > is not a gate\", applied to tests. It is written out here because stating the\n > *goal* is not enough. A regression test for an iteration-order defect can use\n > a fixture where no cell takes part in two transfers per tick — it then passes\n > against the very bug it was written for, and looks authoritative doing it. The\n > fixture, not the assertion, is what makes it useless, and only running it\n > against the unfixed code exposes that.\n\n## Examples\n\n**Correct** (proper naming + Arrange/Act/Assert) — Godot, gdUnit4:\n\n```gdscript\nextends GdUnitTestSuite\n\nfunc test_take_damage_reduces_health() -> void:\n # Arrange — auto_free: a Node left alive is an orphan (gdUnit4 exit 101)\n var health: HealthComponent = auto_free(HealthComponent.new())\n health.max_health = 100\n health.current_health = 100\n\n # Act\n health.take_damage(25)\n\n # Assert\n assert_int(health.current_health).is_equal(75)\n```\n\nUnity, NUnit (`Assets/Tests/EditMode/HealthTests.cs`):\n\n```csharp\nusing NUnit.Framework;\n\npublic class HealthTests\n{\n [Test]\n public void TakeDamage_ReducesHealth()\n {\n // Arrange\n var health = new Health(maxHealth: 100);\n\n // Act\n health.TakeDamage(25);\n\n // Assert\n Assert.AreEqual(75, health.Current);\n }\n}\n```\n\nUnreal, Automation (`Source//Private/Tests/HealthTest.cpp`):\n\n```cpp\n#include \"Misc/AutomationTest.h\"\n\n#if WITH_DEV_AUTOMATION_TESTS\n\nIMPLEMENT_SIMPLE_AUTOMATION_TEST(FHealthTakeDamageTest, \".Health.TakeDamageReducesHealth\",\n EAutomationTestFlags::EditorContext | EAutomationTestFlags::ProductFilter)\n\nbool FHealthTakeDamageTest::RunTest(const FString& Parameters)\n{\n // Arrange\n FHealthPool Health(100);\n\n // Act\n Health.TakeDamage(25);\n\n // Assert\n TestEqual(TEXT(\"health after 25 damage\"), Health.GetCurrent(), 75);\n return true;\n}\n\n#endif\n```\n\n**Incorrect**:\n\n```gdscript\nfunc test1() -> void: # VIOLATION: no descriptive name\n var h := HealthComponent.new()\n h.take_damage(25) # VIOLATION: no arrange step, no clear assert\n assert_bool(h.current_health < 100).is_true() # VIOLATION: imprecise assertion\n```\n","frontmatter":{"paths":["tests/**","Assets/Tests/**/*.cs","Source/**/Tests/**/*.{h,cpp}"]},"isInternal":false,"tokens":1026,"sizeBytes":4108},{"name":"ui-code.md","path":".claude/rules/ui-code.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/rules/ui-code.md","title":"Rules Skill","category":"anthropic-skill","format":"markdown","content":"---\npaths:\n - \"src/ui/**\"\n - \"Assets/**/{UI,Ui,ui}/**/*.cs\"\n - \"Source/**/{UI,Ui,ui}/**/*.{h,cpp}\"\n---\n\n# UI Code Rules\n\n- UI must NEVER own or directly modify game state — display only, use commands/events to request changes\n- All UI text must go through the localization system — no hardcoded user-facing strings\n- Support both keyboard/mouse AND gamepad input for all interactive elements\n- All animations must be skippable and respect user motion/accessibility preferences\n- UI sounds trigger through the audio event system, not directly\n- UI must never block the game thread\n- Scalable text and colorblind modes are mandatory, not optional\n- Test all screens at minimum and maximum supported resolutions\n","frontmatter":{"paths":["src/ui/**","Assets/**/{UI,Ui,ui}/**/*.cs","Source/**/{UI,Ui,ui}/**/*.{h,cpp}"]},"isInternal":false,"tokens":166,"sizeBytes":716},{"name":"1-detect.md","path":".claude/skills/adopt/references/1-detect.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/adopt/references/1-detect.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# /adopt — Phase 1: Detect Project State\n\n> Part of `/adopt`. `SKILL.md` names when to read this file; the settings it\n> resolved and the rules under its later headings still apply here.\n\n## Phase 1: Detect Project State\n\nEmit one line before reading: `\"Scanning project artifacts...\"` — this confirms the\nskill is running during the silent read phase.\n\nThen read silently before presenting anything else.\n\n### Existence check\n- `project.stage` in `project.yaml` (fallback `production/stage.txt`) — if either is present, use that value (authoritative phase)\n- `design/gdd/game-concept.md` (or, at the minimal tier, `design/game-brief.md`) — concept exists?\n- `design/gdd/systems-index.md` — systems index exists?\n- Count GDD files: `design/gdd/*.md` (excluding game-concept.md and systems-index.md)\n- Count ADR files: `docs/architecture/adr-*.md`\n- Count story files: `production/epics/**/*.md` (excluding EPIC.md)\n- `project.yaml` (`engine.name`) / `.claude/docs/technical-preferences.md` — engine configured?\n- `docs/engine-reference/` — engine reference docs present?\n- Glob `docs/adoption-plan-*.md` — note the filename of the most recent prior plan if any exist\n\n### Infer phase (if no project.stage / stage.txt)\nUse the same heuristic as `/project-stage-detect`:\n- 10+ source files in the code root → Production\n- Stories in `production/epics/` → Pre-Production\n- ADRs exist → Technical Setup\n- systems-index.md exists → Systems Design\n- game-concept.md (or `design/game-brief.md`) exists → Concept\n- Nothing → Fresh (not a brownfield project — suggest `/start`)\n\nIf the project appears fresh (no artifacts at all), use `AskUserQuestion`:\n- \"This looks like a fresh project — no existing artifacts found. `/adopt` is for\n projects with work to migrate. What would you like to do?\"\n - \"Run `/start` — begin guided first-time onboarding\"\n - \"My artifacts are in a non-standard location — help me find them\"\n - \"Cancel\"\n\n`/start` and Cancel end this skill: say which, and stop.\n\n**If they pick \"help me find them\"**, search before asking anything else:\n\n1. Search the folder they named, if they named one; otherwise the whole\n project, skipping `.claude/`, `.git/`, `docs/engine-reference/`,\n `studio-tests/`, `node_modules/` and the engine's build and\n cache folders.\n2. Glob `**/*.md` there, then Grep the matches for the headings each artifact\n carries: a GDD has `## Overview` with `## Detailed Rules` or\n `## Detailed Design`; an ADR `## Status` with `## Decision`; a story\n `## Acceptance Criteria` with a `Status` line; a concept doc\n `## Elevator Pitch` or `## Game Pillars`; a brief `## Core loop` with\n `## MVP`.\n3. Show what was found, grouped by type, each with the place every skill reads\n it from: GDD → `design/gdd/[name].md`; ADR →\n `docs/architecture/adr-NNNN-[name].md`; story →\n `production/epics/[epic]/story-NNN-[name].md`; concept →\n `design/gdd/game-concept.md`; brief → `design/game-brief.md`. If nothing\n matched, say so, name the folders and headings searched, and offer `/start`.\n4. Ask before moving anything — a move takes the file away from its old path,\n so it is a `file_deletions` decision: \"May I move these [N] files to the\n standard folders?\" — `[A] Move them all` / `[B] Let me pick which` /\n `[C] Don't move them — I'll do it myself`. Move with `git mv` in a git\n repository (the file's history follows it), plain `mv` otherwise. Never\n overwrite a file already at the target: name the clash and skip that file.\n Files are moved, never edited.\n5. After the moves, run Phase 1 again from the top, so the audit reads the files\n where every other skill will. With [C], print the moves as a list and stop.\n\nReport: \"Detected phase: [phase]. Found: [N] GDDs, [M] ADRs, [P] stories.\"\n\n---\n","isInternal":false,"tokens":1011,"sizeBytes":3820},{"name":"2-format-audit.md","path":".claude/skills/adopt/references/2-format-audit.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/adopt/references/2-format-audit.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# /adopt — Phase 2: Format Audit\n\n> Part of `/adopt`. `SKILL.md` names when to read this file; the settings it\n> resolved and the rules under its later headings still apply here.\n\n## Phase 2: Format Audit\n\n**In this file:**\n\n- 2a: GDD Format Audit\n- 2b: ADR Format Audit\n- 2c: systems-index.md Format Audit\n- 2d: Story Format Audit\n- 2e: Infrastructure Audit\n- 2f: Project Config Audit\n- 2g: v1.0 Migration Check\n\nFor each artifact type in scope (based on argument mode **and the resolved\nworkflow tier**), check not just that the file exists but that it contains the\ninternal structure the template requires. At `minimal`, scope the audit to\n`design/game-brief.md` — do not audit for GDDs, ADRs, or UX specs (they are not expected).\nSteps 2e (the Engine reference row only), 2f (project config) and 2g (v1.0\nmigration check) run at every tier.\n\n### 2a: GDD Format Audit\n\n**Gather section presence deterministically — do not read the GDDs to count\nheadings.** For each GDD discovered in Phase 1, pass its path explicitly to the\nstructure-check script:\n\n```\nBash: bash .claude/scripts/gdd-structure-check.sh [path-to-gdd]\n```\n\n**Pass paths one at a time; do not invoke it bare.** The no-argument form sweeps\n`design/gdd/` only, and a brownfield project's GDDs are not guaranteed to live\nthere — pass whatever paths Phase 1 found. The script prints a `PRESENT:` list\nand, when applicable, an `ABSENT:` list per file. It reports **presence only**\nand makes no REQUIRED/ADVISORY judgment (that is the tier logic below), and it\nalready accepts `## Detailed Design` as satisfying the `Detailed Rules`\nrequirement, so do not flag that alias as missing.\n\nIf the script prints `Not found:` for a path or errors, that is a **discovery\nfailure, not a format gap** — report it as \"could not audit [path]\" and do not\ncount it as a missing-sections finding.\n\n**Then apply the workflow tier** resolved above to each file's PRESENT/ABSENT\nlists. Which sections are **required** (a miss = gap) vs **advisory** (a miss =\ninformational):\n- **`full`** — all 8 sections are required.\n- **`standard`** — the 5 required (Overview, Detailed Rules, Edge Cases,\n Dependencies, Acceptance Criteria) + Formulas for any system that defines\n numeric rules (rates, curves, thresholds, costs — the system's `Category` is a\n hint, not the test); Player Fantasy and Tuning Knobs are advisory.\n- **`minimal`** — GDDs are not expected; audit `design/game-brief.md` instead,\n against `.claude/docs/templates/game-brief.md`: each of the six required fields\n present and not a placeholder; the three one-liners advisory. Any GDD that\n does exist is checked at the `standard` bar, advisorily.\n\nThe script's 8 canonical labels are: Overview, Player Fantasy, Detailed Rules,\nFormulas, Edge Cases, Dependencies, Tuning Knobs, Acceptance Criteria.\n\nA section reported PRESENT can still be an empty heading. For each GDD, also\nrecord with a targeted grep (not a full read):\n- Placeholder-only sections — the script's `PLACEHOLDER:` line names the\n present sections that hold only `[To be designed]` or nothing; a\n single-line stub body is the same in effect, so spot-check short sections.\n- The `**Status**:` header field — `Grep pattern=\"^>?[[:space:]]*\\*\\*Status\\*\\*:\"`.\n Valid values: `Draft`, `In Design`, `Designed`, `In Review`, `Approved`,\n `Implemented`, `Needs Revision`.\n\n> **The `>?` is load-bearing, and so are `Draft`/`Implemented`.** Both emitters\n> write this field inside a blockquote — `.claude/docs/templates/game-design-document.md`\n> and `/design-system` produce `> **Status**: …` — so an anchor of\n> `^\\*\\*Status\\*\\*:` matches nothing and reports *every* template-compliant GDD\n> as missing its Status. The template's own value list offers `Draft` and\n> `Implemented`, so both must count as valid.\n\n### 2b: ADR Format Audit\n\nFor each ADR file found, check for these critical sections:\n\n| Section | Impact if missing |\n|---|---|\n| `## Status` | **BLOCKING** — `/story-readiness` ADR status check silently passes everything |\n| `## ADR Dependencies` | HIGH — dependency ordering in `/architecture-review` breaks |\n| `## Engine Compatibility` | HIGH — post-cutoff API risk is unknown |\n| `## GDD Requirements Addressed` | MEDIUM — traceability matrix loses coverage |\n| `## Performance Implications` | LOW — not pipeline-critical |\n\nFor each ADR, record: which sections present, which missing, current Status value\nif the Status section exists.\n\n### 2c: systems-index.md Format Audit\n\nIf `design/gdd/systems-index.md` exists:\n\n1. **Parenthetical status values** — Grep for any Status cell containing\n parentheses: `\"Needs Revision (\"`, `\"In Progress (\"`, etc.\n These break exact-string matching in `/gate-check`, `/create-stories`,\n and `/architecture-review`. **BLOCKING.**\n\n2. **Valid status values** — check that Status column values are only from:\n `Not Started`, `In Progress`, `In Review`, `Designed`, `Approved`, `Needs Revision`\n Flag any unrecognised values.\n\n3. **Column structure** — check that the table has at minimum: System name,\n Layer, Priority, Status columns. Missing columns degrade skill functionality.\n\n### 2d: Story Format Audit\n\nFor each story file found:\n\n- **`Manifest Version:` field** — present in story header? (LOW — auto-passes if absent)\n- **TR-ID reference** — does story contain `TR-[a-z]+-[0-9]+` pattern? (MEDIUM — no staleness tracking)\n- **ADR reference** — does story reference at least one ADR? (check for `ADR-` pattern)\n- **Status field** — present and readable?\n- **Acceptance criteria** — does the story have a checkbox list (`- [ ]`)?\n\n### 2e: Infrastructure Audit\n\n| Artifact | Path | Impact if missing |\n|---|---|---|\n| TR registry | `docs/architecture/tr-registry.yaml` | HIGH — no stable requirement IDs |\n| Control manifest | `docs/architecture/control-manifest.md` | HIGH — no layer rules for stories |\n| Manifest version stamp | In manifest header: `Manifest Version:` | MEDIUM — staleness checks blind |\n| Sprint status | `production/sprint-status.yaml` | MEDIUM — `/sprint-status` falls back to markdown |\n| Stage file | `project.stage` in `project.yaml` (fallback `production/stage.txt`) | MEDIUM — phase auto-detect unreliable |\n| Engine reference | `docs/engine-reference/[engine]/VERSION.md` | HIGH — ADR engine checks blind |\n| Architecture traceability | `docs/architecture/requirements-traceability.md` | MEDIUM — no persistent matrix |\n\nAt `workflow: minimal` only the Engine reference row applies. The TR registry,\ncontrol manifest and its version stamp, sprint status, stage file and\ntraceability matrix are not on the minimal path, so their absence is not a gap.\n\n### 2f: Project Config Audit\n\nRead `project.yaml` (the primary config store) and `.claude/docs/technical-preferences.md` (legacy mirror). A setting counts as configured if EITHER source has a real value (in technical-preferences.md, `[TO BE CONFIGURED]` means unconfigured):\n- `engine.name`/`version`/`language`/`rendering`/`physics` (else the Engine/Language/Rendering/Physics fields) → HIGH if unconfigured in both (ADR skills fail)\n- `naming.*` (else Naming conventions) → MEDIUM\n- `performance.*` (else Performance budgets) → MEDIUM\n- Forbidden Patterns, Allowed Libraries (technical-preferences.md only — not migrated to project.yaml) → LOW (starts empty by design)\n\n### 2g: v1.0 Migration Check\n\nA project is a **v1.0 project needing migration** when `project.yaml` does NOT\nexist at the repo root AND at least one legacy file does: `production/stage.txt`,\n`production/review-mode.txt`, or a `.claude/docs/technical-preferences.md` with\nreal values.\n\n\"Real values\" means one of the keys the converter actually migrates — Engine,\nLanguage, Rendering, Physics, the naming, platform and performance fields,\nFramework, or the specialists. Not merely \"some bullet is filled in\": the\nshipped template ships one prose default (`- **Required Tests**: …`) that is\nnever migrated, and counting it would make every fresh clone read as a v1.0\nproject.\n\nDo not hand-migrate. Run the converter, which is deterministic and covered by\nthe framework's own test suite:\n\n```bash\nbash .claude/scripts/migrate-v1-config.sh --dry-run\n```\n\nThe dry run writes nothing; record what it lists for the report. Do not run the\nconverter during the audit — Phase 2 reads silently. The migration is\nclassified BLOCKING in Phase 3, heads the plan, and **Phase 7 offers it as the\nfirst action**: report what the dry run listed, then ask \"May I run the\nconverter? It writes `project.yaml` and `production/migration-report.md`.\" If\nthe user approves, run it without `--dry-run`. It\nwrites `project.yaml` plus `production/migration-report.md` and **deletes\nnothing** — the whole operation stays reversible with `git checkout`.\n\nThen tell the user to read `production/migration-report.md` before running:\n\n```bash\nbash .claude/scripts/migrate-v1-config.sh --finalize\n```\n\n`--finalize` deletes a legacy file only after proving its value is present in\n`project.yaml`; on mismatch it deletes nothing and exits 4. It never deletes\n`technical-preferences.md`, which still holds Forbidden Patterns and Allowed\nLibraries.\n\n**If the script refuses with exit 3**, do not work around it. Exit 3 means one\nof two things, and the message says which:\n\n- **the values DISAGREE** — two sources of truth and no way to know which the\n user edited last. Surface it and let them decide.\n- **a `production/migration-report.md` is already present** — a migration ran\n here, so these are post-migration leftovers and `--finalize` is the next step,\n not a second `migrate`.\n\nBoth files merely *existing* is not exit 3 and must not be reported as a\nconflict: `/start` writes `production/stage.txt` on every new v1.1 project as a\nmirror, so agreement is the normal state. The script says\n`the legacy files mirror it (values agree)` and exits 0 for that.\n\nClassify as **BLOCKING** in Phase 3: until migration runs, every skill reads\nconfig through the legacy fallback chain, and v1.1 settings are unavailable.\n\n---\n","isInternal":false,"tokens":2505,"sizeBytes":10078},{"name":"3-classify.md","path":".claude/skills/adopt/references/3-classify.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/adopt/references/3-classify.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# /adopt — Phase 3: Classify and Prioritise Gaps\n\n> Part of `/adopt`. `SKILL.md` names when to read this file; the settings it\n> resolved and the rules under its later headings still apply here.\n\n## Phase 3: Classify and Prioritise Gaps\n\nOrganise every gap found across all audits into four severity tiers:\n\n**BLOCKING** — Will cause template skills to silently produce wrong results *right now*.\nExamples: ADR missing Status field, systems-index parenthetical status values,\nengine not configured when ADRs exist.\n\n**HIGH** — Will cause stories to be generated with missing safety checks, or\ninfrastructure bootstrapping will fail.\nExamples: ADRs missing Engine Compatibility, GDDs missing Acceptance Criteria\n(stories can't be generated from them), tr-registry.yaml missing.\n\n**MEDIUM** — Degrades quality and pipeline tracking but does not break functionality.\nExamples: GDDs missing Tuning Knobs or Formulas sections, stories missing TR-IDs,\nsprint-status.yaml missing.\n\n**LOW** — Retroactive improvements that are nice-to-have but not urgent.\nExamples: Stories missing Manifest Version stamps, GDDs missing Open Questions section.\n\nCount totals per tier. If zero BLOCKING and zero HIGH gaps: report that the project\nis template-compatible and only advisory improvements remain.\n\n---\n","isInternal":false,"tokens":286,"sizeBytes":1298},{"name":"4-migration-plan.md","path":".claude/skills/adopt/references/4-migration-plan.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/adopt/references/4-migration-plan.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# /adopt — Phase 4: Build the Migration Plan\n\n> Part of `/adopt`. `SKILL.md` names when to read this file; the settings it\n> resolved and the rules under its later headings still apply here.\n\n## Phase 4: Build the Migration Plan\n\nCompose a numbered, ordered action plan. Ordering rules:\n1. BLOCKING gaps first (must fix before any pipeline skill runs reliably)\n2. HIGH gaps next, infrastructure before GDD/ADR content (bootstrapping needs correct formats)\n3. MEDIUM gaps ordered: GDD gaps before ADR gaps before story gaps (stories depend on GDDs and ADRs)\n4. LOW gaps last\n\nFor each gap, produce a plan entry with:\n- A clear problem statement (one sentence, no jargon)\n- The exact command to fix it, if a skill handles it\n- Manual steps if it requires direct editing\n- A time estimate (rough: 5 min / 30 min / 1 session)\n- A checkbox `- [ ]` for tracking\n\n**Special case — systems-index parenthetical status values:**\nThis is always the first item if present. Show the exact values that need changing\nand the exact replacement text. Offer to fix this immediately before writing the plan.\n\n**Special case — ADRs missing Status field:**\nFor each affected ADR, the fix is:\n`/architecture-decision retrofit docs/architecture/adr-[NNNN]-[slug].md`\nList each ADR as a separate checkable item.\n\n**Special case — GDDs missing sections:**\nFor each affected GDD, list which sections are missing and the fix:\n`/design-system retrofit design/gdd/[filename].md`\n\n**Infrastructure bootstrap ordering** — always present in this sequence:\n1. Fix ADR formats first (registry depends on reading ADR Status fields)\n2. Run `/architecture-review` → bootstraps `tr-registry.yaml`\n3. Run `/create-control-manifest` → creates manifest with version stamp\n4. Run `/sprint-plan update` → creates `sprint-status.yaml`\n5. Run `/gate-check [phase]` (the gate into the phase the project is in; at Concept there is none — Concept is the default stage, nothing to run) → writes `project.stage` in `project.yaml` (and legacy `stage.txt`) authoritatively\n\n**At `workflow: minimal` the plan prescribes none of this sequence.** None of it\nis on the minimal path: ADRs are not expected, the brief's build order is the\nplan (no `/sprint-plan`), and nothing there runs `/gate-check`. The plan's\nStep 3 says so in one line and names the path's next step instead —\n`/create-stories` when no stories exist, else `/dev-story`.\n\n**Existing stories** — note explicitly:\n> \"Existing stories continue to work with all template skills — all new format\n> checks auto-pass when the fields are absent. They won't benefit from TR-ID\n> staleness tracking or manifest version checks until they're regenerated. This\n> is intentional: do not regenerate stories that are already in progress.\"\n\n---\n","isInternal":false,"tokens":661,"sizeBytes":2767},{"name":"5-summary.md","path":".claude/skills/adopt/references/5-summary.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/adopt/references/5-summary.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# /adopt — Phase 5: Present Summary and Ask to Write\n\n> Part of `/adopt`. `SKILL.md` names when to read this file; the settings it\n> resolved and the rules under its later headings still apply here.\n\n## Phase 5: Present Summary and Ask to Write\n\nPresent a compact summary before writing:\n\n```\n## Adoption Audit Summary\nPhase detected: [phase]\nEngine: [configured / NOT CONFIGURED]\nGDDs audited: [N] ([X] fully compliant, [Y] with gaps)\nADRs audited: [N] ([X] fully compliant, [Y] with gaps)\nStories audited: [N]\n\nGap counts:\n BLOCKING: [N] — template skills will malfunction without these fixes\n HIGH: [N] — unsafe to run /create-stories or /story-readiness\n MEDIUM: [N] — quality degradation\n LOW: [N] — optional improvements\n\nEstimated remediation: [X blocking items × ~Y min each = roughly Z hours]\n```\n\nBefore asking to write, show a **Gap Preview**:\n- List every BLOCKING gap as a one-line bullet describing the actual problem\n (e.g. `systems-index.md: 3 rows have parenthetical status values`,\n `adr-0002.md: missing ## Status section`). No counts — show the actual items.\n- Show HIGH / MEDIUM / LOW as counts only (e.g. `HIGH: 4, MEDIUM: 2, LOW: 1`).\n\nThis gives the user enough context to judge scope before committing to writing the file.\n\nIf a prior adoption plan was detected in Phase 1, add a note:\n> \"A previous plan exists at `docs/adoption-plan-[prior-date].md`. The new plan will\n> reflect current project state — it does not diff against the prior run.\"\n\nUse `AskUserQuestion`:\n- \"Ready to write the migration plan?\"\n - \"Yes — write `docs/adoption-plan-[date].md`\"\n - \"Show me the full plan preview first (don't write yet)\"\n - \"Cancel — I'll handle migration manually\"\n\nIf the user picks \"Show me the full plan preview\", output the complete plan as a\nfenced markdown block. Then ask again with the same three options.\n\n---\n","isInternal":false,"tokens":488,"sizeBytes":1879},{"name":"6-write.md","path":".claude/skills/adopt/references/6-write.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/adopt/references/6-write.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# /adopt — Phases 6 and 6b: Write the Adoption Plan and Report Review Mode\n\n> Part of `/adopt`. `SKILL.md` names when to read this file; the settings it\n> resolved and the rules under its later headings still apply here.\n\n## Phase 6: Write the Adoption Plan\n\n**In this file:**\n\n- Phase 6: the adoption plan template, then the write\n- Phase 6b: Report Review Mode\n\nIf approved, write `docs/adoption-plan-[date].md` with this structure:\n\n```markdown\n# Adoption Plan\n\n> **Generated**: [date]\n> **Project phase**: [phase]\n> **Engine**: [name + version, or \"Not configured\"]\n> **Template version**: v1.0+\n\nWork through these steps in order. Check off each item as you complete it.\nRe-run `/adopt` anytime to check remaining gaps.\n\n---\n\n## Step 1: Fix Blocking Gaps\n\n[One sub-section per blocking gap with problem, fix command, time estimate, checkbox]\n\n---\n\n## Step 2: Fix High-Priority Gaps\n\n[One sub-section per high gap]\n\n---\n\n## Step 3: Bootstrap Infrastructure\n\n[At `workflow: minimal`, replace 3a–3d with one line: \"Not on the minimal path —\nthe brief's build order is the plan. Next: `/create-stories` (or `/dev-story`\nonce stories exist).\"]\n\n### 3a. Register existing requirements (creates tr-registry.yaml)\nRun `/architecture-review` — even if ADRs already exist, this run bootstraps\nthe TR registry from your existing GDDs and ADRs.\n**Time**: 1 session (review can be long for large codebases)\n- [ ] tr-registry.yaml created\n\n### 3b. Create control manifest\nRun `/create-control-manifest`\n**Time**: 30 min\n- [ ] docs/architecture/control-manifest.md created\n\n### 3c. Create sprint tracking file\nRun `/sprint-plan update`\n**Time**: 5 min (if sprint plan already exists as markdown)\n- [ ] production/sprint-status.yaml created\n\n### 3d. Set authoritative project stage\nRun `/gate-check [current-phase]` (the gate into the phase the project is in;\nat Concept there is none — Concept is the default stage, nothing to run)\n**Time**: 5 min\n- [ ] `project.stage` in `project.yaml` written (legacy `production/stage.txt` also updated)\n\n---\n\n## Step 4: Medium-Priority Gaps\n\n[One sub-section per medium gap]\n\n---\n\n## Step 5: Optional Improvements\n\n[One sub-section per low gap]\n\n---\n\n## What to Expect from Existing Stories\n\nExisting stories continue to work with all template skills. New format checks\n(TR-ID validation, manifest version staleness) auto-pass when the fields are\nabsent — so nothing breaks. They won't benefit from staleness tracking until\nregenerated. Do not regenerate stories that are in progress or done.\n\n---\n\n## Re-run\n\nRun `/adopt` again after completing Step 3 to verify all blocking and high gaps\nare resolved. The new run will reflect the current state of the project.\n```\n\n---\n\n## Phase 6b: Report Review Mode\n\n**Do not write a review mode.** `modes.review_mode` is one of the six knobs\n`modes.rigor` fronts: pinning it in `project.yaml` shadows the rigor expansion, and\nthe legacy `production/review-mode.txt` sits *above* that expansion in resolution,\nso either write would freeze director-review depth for good — the rule `/start`\nand `project.yaml`'s header comment both state.\n\nReport the value the bootstrap above resolved instead: \"Review mode resolves to\n`[value]` — from `modes.rigor`, unless something pins it.\" If the user wants a\ndifferent depth, point them to changing `modes.rigor`, or to pinning it on purpose\nwith `/settings --local modes.review_mode=` (a personal override in\n`project.local.yaml`).\n\n---\n","isInternal":false,"tokens":863,"sizeBytes":3476},{"name":"7-first-action.md","path":".claude/skills/adopt/references/7-first-action.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/adopt/references/7-first-action.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# /adopt — Phase 7: Offer First Action\n\n> Part of `/adopt`. `SKILL.md` names when to read this file; the settings it\n> resolved and the rules under its later headings still apply here.\n\n## Phase 7: Offer First Action\n\nAfter writing the plan, don't stop there. Pick the single highest-priority gap\nand offer to handle it immediately using `AskUserQuestion`. Choose the first\nbranch that applies:\n\n**If Phase 2g found a v1.0 project needing migration:** offer the converter run\ndescribed there — report what the dry run listed and ask \"May I run the\nconverter? It writes `project.yaml` and `production/migration-report.md`.\"\nEvery other fix reads config through it, so it comes first.\n\n**If there are parenthetical status values in systems-index.md:**\nUse `AskUserQuestion`:\n- \"The most urgent fix is `systems-index.md` — [N] rows have parenthetical status\n values (e.g. `Needs Revision (see notes)`) that break /gate-check,\n /create-stories, and /architecture-review right now. I can fix these in-place.\"\n - \"Fix it now — edit systems-index.md\"\n - \"I'll fix it myself\"\n - \"Done — leave me with the plan\"\n\n**If ADRs are missing `## Status` (and no parenthetical issue):**\nUse `AskUserQuestion`:\n- \"The most urgent fix is adding `## Status` to [N] ADR(s): [list filenames].\n Without it, /story-readiness silently passes all ADR checks. Start with\n [first affected filename]?\"\n - \"Yes — retrofit [first affected filename] now\"\n - \"Retrofit all [N] ADRs one by one\"\n - \"I'll handle ADRs myself\"\n\n**If GDDs are missing Acceptance Criteria (and no blocking issues above):**\nUse `AskUserQuestion`:\n- \"The most urgent gap is missing Acceptance Criteria in [N] GDD(s):\n [list filenames]. Without them, /create-stories can't generate stories.\n Start with [highest-priority GDD filename]?\"\n - \"Yes — add Acceptance Criteria to [GDD filename] now\"\n - \"Do all [N] GDDs one by one\"\n - \"I'll handle GDDs myself\"\n\n**Otherwise, if any BLOCKING or HIGH gap remains** (one no branch above names —\ne.g. a missing TR registry):\nUse `AskUserQuestion`:\n- \"The most urgent remaining gap is [first BLOCKING or HIGH item in the plan] —\n [one line on what it breaks]. Start on it now?\"\n - \"Yes — start on [item]\"\n - \"Show me that plan item first\"\n - \"Done — leave me with the plan\"\n\n**If no BLOCKING or HIGH gaps exist:**\nUse `AskUserQuestion`:\n- \"No blocking gaps — this project is template-compatible. What next?\"\n - \"Walk me through the medium-priority improvements\"\n - \"Run /project-stage-detect for a broader health check\"\n - \"Done — I'll work through the plan at my own pace\"\n\n> **Adoption plan saved to `docs/adoption-plan-[date].md`.** Re-run `/adopt` at any time to re-check remaining gaps as you complete them.\n\n---\n","isInternal":false,"tokens":726,"sizeBytes":2746},{"name":"SKILL.md","path":".claude/skills/adopt/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/adopt/SKILL.md","title":"adopt","category":"anthropic-skill","format":"markdown","content":"---\nname: adopt\ndescription: \"Brownfield audit — do existing artifacts actually work? Numbered migration plan. Unlike /project-stage-detect, checks compliance not existence.\"\nargument-hint: \"[focus: full | gdds | adrs | stories | infra]\"\nuser-invocable: true\nallowed-tools: Read, Glob, Grep, Write, AskUserQuestion, Bash(bash \"*/.claude/skills/adopt/../../hooks/yaml-helper.sh\" resolve_config *), Bash(bash .claude/scripts/gdd-structure-check.sh *), Bash(bash .claude/scripts/migrate-v1-config.sh --dry-run*)\nmodel: sonnet\n---\n\n!`bash \"${CLAUDE_SKILL_DIR}/../../hooks/yaml-helper.sh\" resolve_config --keys review_mode,automation,automation_always_ask,workflow`\n\nResolved above — use as-is. `/adopt` also inspects `project.yaml` and the legacy\nconfig files directly when reporting and writing migration state; that raw\ninspection is deliberate and separate from the resolved values above.\n\n# Adopt — Brownfield Template Adoption\n\nThis skill audits an existing project's artifacts for **format compliance** with\nthe template's skill pipeline, then produces a prioritised migration plan.\n\n**This is not `/project-stage-detect`.**\n`/project-stage-detect` answers: *what exists?*\n`/adopt` answers: *will what exists actually work with the template's skills?*\n\nA project can have GDDs, ADRs, and stories — and every format-sensitive skill\nwill still fail silently or produce wrong results if those artifacts are in the\nwrong internal format.\n\n**Output:** `docs/adoption-plan-[date].md` — a persistent, checkable migration plan.\n\n**Argument modes:**\n\n**Audit mode:** `$ARGUMENTS` (blank = `full`)\n\n- **No argument / `full`**: Complete audit — all artifact types\n- **`gdds`**: GDD format compliance only\n- **`adrs`**: ADR format compliance only\n- **`stories`**: Story format compliance only\n- **`infra`**: Infrastructure artifact gaps only (registry, manifest, sprint-status, stage.txt)\n\n---\n\n**Automation mode**: Resolve `modes.automation` (`project.local.yaml` →\n`project.yaml` → default `collaborative`). Every `AskUserQuestion` call follows `.claude/docs/automation-modes.md`\n(collaborative asks always · guided major-only · autonomous logs and proceeds;\n`automation_always_ask` categories always prompt).\n\n**`workflow`** (per `.claude/docs/workflow-modes.md`). It scopes the Phase 2 audit and\nPhase 3 severity: `full` audits all doc types at full structure; `standard` audits\nonly the required docs/sections (optional sections are informational, not gaps);\n`minimal` is a `design/game-brief.md` format check — GDDs/ADRs/UX are not expected. See Phase 2.\n\n## Phase 1: Detect Project State\n\n**Read `references/1-detect.md` now and follow it** — this phase's steps are in that file, not here. Read it again if the conversation was compacted or resumed during this phase.\n\n## Phase 2: Format Audit\n\n**Read `references/2-format-audit.md` now and follow it** — this phase's steps are in that file, not here. Read it again if the conversation was compacted or resumed during this phase.\n\n## Phase 3: Classify and Prioritise Gaps\n\n**Read `references/3-classify.md` now and follow it** — this phase's steps are in that file, not here. Read it again if the conversation was compacted or resumed during this phase.\n\n## Phase 4: Build the Migration Plan\n\n**Read `references/4-migration-plan.md` now and follow it** — this phase's steps are in that file, not here. Read it again if the conversation was compacted or resumed during this phase.\n\n## Phase 5: Present Summary and Ask to Write\n\n**Read `references/5-summary.md` now and follow it** — this phase's steps are in that file, not here. Read it again if the conversation was compacted or resumed during this phase.\n\n## Phase 6: Write the Adoption Plan\n\n**Read `references/6-write.md` now and follow it** — this phase's steps are in that file, not here. Read it again if the conversation was compacted or resumed during this phase.\n\n## Phase 7: Offer First Action\n\n**Read `references/7-first-action.md` now and follow it** — this phase's steps are in that file, not here. Read it again if the conversation was compacted or resumed during this phase.\n\n## Collaborative Protocol\n\n**Applies in `collaborative` mode (the default).** For `guided` and\n`autonomous` modes, see `.claude/docs/automation-modes.md` — the rules below\ndescribe what collaborative mode requires, not universal behavior.\n\n1. **Read silently** — complete the full audit before presenting anything\n2. **Show the summary first** — let the user see scope before asking to write\n3. **Ask before writing** — always confirm before creating the adoption plan file\n4. **Offer, don't force** — the plan is advisory; the user decides what to fix and when\n5. **One action at a time** — after handing off the plan, offer one specific next step,\n not a list of six things to do simultaneously\n6. **Never regenerate existing artifacts** — only fill gaps in what exists;\n do not rewrite GDDs, ADRs, or stories that already have content\n","frontmatter":{"name":"adopt","description":"Brownfield audit — do existing artifacts actually work? Numbered migration plan. Unlike /project-stage-detect, checks compliance not existence.","argument-hint":"[focus: full | gdds | adrs | stories | infra]","user-invocable":true,"allowed-tools":"Read, Glob, Grep, Write, AskUserQuestion, Bash(bash \"*/.claude/skills/adopt/../../hooks/yaml-helper.sh\" resolve_config *), Bash(bash .claude/scripts/gdd-structure-check.sh *), Bash(bash .claude/scripts/migrate-v1-config.sh --dry-run*)","model":"sonnet","allowedTools":["Read,","Glob,","Grep,","Write,","AskUserQuestion,","Bash(bash","\"*/.claude/skills/adopt/../../hooks/yaml-helper.sh\"","resolve_config","*),","Bash(bash",".claude/scripts/gdd-structure-check.sh","*),","Bash(bash",".claude/scripts/migrate-v1-config.sh","--dry-run*)"]},"allowedTools":["Read,","Glob,","Grep,","Write,","AskUserQuestion,","Bash(bash","\"*/.claude/skills/adopt/../../hooks/yaml-helper.sh\"","resolve_config","*),","Bash(bash",".claude/scripts/gdd-structure-check.sh","*),","Bash(bash",".claude/scripts/migrate-v1-config.sh","--dry-run*)"],"isInternal":false,"tokens":1196,"sizeBytes":4979},{"name":"CONTRACT.md","path":".claude/skills/architecture-decision/CONTRACT.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/architecture-decision/CONTRACT.md","title":"Architecture-decision Skill","category":"anthropic-skill","format":"markdown","content":"# /architecture-decision — Handoff Contract\n\n## Role in Pipeline\nAuthors a new Architecture Decision Record (ADR) by guiding a collaborative design session, cross-referencing the engine reference library and existing architectural stances, and writing a fully-structured ADR file to `docs/architecture/` as `Proposed`. Its `accept` mode is the only route to `Accepted`, and acceptance is what unblocks the stories and epics that depend on the decision.\n\nTwo checks inside the run emit `NOT ASSESSED` rather than passing silently, and\na reader of the resulting ADR should expect them: **engine validation** when no\nengine is configured (`engine.name` unset and no legacy fallback), and **GDD\nsync** when the referenced design docs cannot be read. A skipped check that says\nnothing is indistinguishable from a check that passed.\n\n## Inputs Required\n\n### Files That Must Exist\n| File | Required Fields / Sections | Read-Only? |\n|------|---------------------------|-----------|\n| `docs/engine-reference/[engine]/VERSION.md` | Engine name + version, LLM knowledge cutoff date, post-cutoff risk levels per domain | Yes |\n| `docs/engine-reference/[engine]/modules/[domain].md` | Domain-specific API reference (read if exists for the decision's domain) | Yes |\n| `docs/engine-reference/[engine]/breaking-changes.md` | Post-cutoff breaking changes in the relevant domain | Yes |\n| `docs/engine-reference/[engine]/deprecated-apis.md` | APIs that must not be referenced in the new ADR | Yes |\n| `docs/registry/architecture.yaml` | All existing architectural stances (state ownership, interface contracts, forbidden patterns, performance budgets) — checked for conflicts before the design begins | Yes |\n| `docs/architecture/` (existing ADRs) | Scanned to determine the next sequential ADR number | Yes |\n| `design/gdd/[system].md` (GDDs relevant to the decision) | Specific rules, formulas, performance constraints, or integration points that motivate the decision | Yes |\n| `project.yaml` | `engine.name` — derives the primary specialist (`-specialist`) to spawn for validation (Step 5.5) | Yes |\n| `.claude/docs/technical-preferences.md` | `Engine Specialists` section — legacy fallback, used only when `engine.name` is absent or empty in `project.yaml` | Yes — required only when `engine.name` is absent |\n\n### Preconditions\n- An engine must be configured (`docs/engine-reference/[engine]/VERSION.md` must exist) — if not, the skill prompts to run `/setup-engine` first\n- The title or subject of the decision must be provided by the user before Step 0 proceeds (if no argument is given, the skill asks)\n- If in **retrofit mode** (`retrofit [path]` argument), the target ADR file must already exist on disk\n- Any conflict with a registered architectural stance in `docs/registry/architecture.yaml` must be resolved or explicitly accepted as an exception before the ADR is drafted (Step 3a is a BLOCKING gate)\n\n## Outputs Produced\n\n### Files Written\n| File | Guaranteed Fields / Sections | Notes |\n|------|------------------------------|-------|\n| `docs/architecture/adr-NNNN-[slug].md` | `## Status`, `## Date`, `## Engine Compatibility` (table with engine, domain, knowledge risk, post-cutoff APIs, verification required), `## ADR Dependencies` (table with depends-on, enables, blocks, ordering note), `## Context` (problem statement, constraints, requirements), `## Decision` (+ architecture diagram + key interfaces), `## Alternatives Considered`, `## Consequences` (positive, negative), `## Risks`, `## GDD Requirements Addressed` (table), `## Performance Implications`, `## Migration Plan`, `## Validation Criteria`, `## Related` | created after user approves (\"May I write this ADR to docs/architecture/adr-NNNN-[slug].md?\") |\n| `docs/registry/architecture.yaml` | New stance entries (state ownership, interface contracts, performance budgets, forbidden patterns) derived from the ADR; existing entries marked `status: superseded_by` if overridden | appended after separate user approval (\"May I update docs/registry/architecture.yaml with these N new stances?\") |\n\n### Output Guarantees\n- The ADR number is the next sequential integer after the highest existing `adr-NNNN-*` filename in `docs/architecture/`\n- `## Status` is always present. Authoring writes `Proposed`; retrofit writes the status the user gives, except that an `Accepted` answer is written as `Proposed` and handed to acceptance mode. Only acceptance mode writes `Accepted`, after its dependency check and the user's confirmation\n- `## Engine Compatibility` is always populated using verified data from the engine reference docs — never from training data alone when the domain carries MEDIUM or HIGH risk\n- `## GDD Requirements Addressed` is always present (if no GDD motivated the decision, it documents which GDDs the decision will constrain or enable)\n- `## ADR Dependencies` is always present (fields set to \"None\" if no ordering constraints exist)\n- Engine specialist validation (Step 5.5) runs before the file is written if an engine specialist is configured; blocking issues found by the specialist cause the Decision section to be revised before saving\n\n## Immutability Rules\n- READS but does NOT modify: all existing ADR files in `docs/architecture/` (including in retrofit mode — existing sections are never touched), all GDD files in `design/gdd/`, `docs/engine-reference/**`, `project.yaml`, `.claude/docs/technical-preferences.md` (legacy fallback)\n- MODIFIES: `docs/architecture/adr-NNNN-[slug].md` (new file created; or missing sections appended in retrofit mode), `docs/registry/architecture.yaml` (append only; existing entries get `status: superseded_by` annotation, never deleted or rewritten)\n- In retrofit mode: appends only the missing sections — never modifies any section that is already present in the target ADR file\n\n## Hard Constraints (Never Violate)\n- Never sets `Status: Accepted` without explicit user confirmation — the default on creation is always `Status: Proposed`\n- **Acceptance route: `/architecture-decision accept ADR-NNNN`** — the only path that sets `Accepted`. It refuses when a dependency is still Proposed, and prompts for confirmation regardless of `modes.automation`. Retrofit mode's `Accepted` answer, for a decision already in force, is written as `Proposed` and handed to this route. Without this route acceptance would be enforced by ten skills, owned per the authority below, and reachable by nobody.\n- **Acceptance authority: the user, or `technical-director` on the user's explicit confirmation — no other agent, and not this skill on its own.** Recorded here because every consumer enforces the consequences of acceptance, and without this line nothing would say who can produce it. This narrows *who* may set the field; it does not relax the confirmation rule above.\n- Never assigns an ADR number that is already in use — always scan `docs/architecture/` first and use the next sequential number\n- Never proceeds past the architectural stance conflict check (Step 3a) if a conflict exists — surface the conflict and require resolution or explicit exception acknowledgment before drafting\n- Never references APIs listed in `docs/engine-reference/[engine]/deprecated-apis.md` in the Decision or Key Interfaces sections\n- Never writes the ADR file without asking: \"May I write this ADR to docs/architecture/adr-NNNN-[slug].md?\"\n- Never writes to `docs/registry/architecture.yaml` without a separate ask: \"May I update docs/registry/architecture.yaml with these N new stances?\"\n- In retrofit mode: never modifies any existing section — only appends absent sections\n\n## Downstream Skill Expects\n**Next skills:** `/create-epics`, `/create-stories`, `/dev-story`, `/architecture-review`\n\n### `/create-epics` reads ADRs expecting:\n- `## Status` field — value must be `Accepted` for epics to reference it\n- `## GDD Requirements Addressed` table — used to link epics to GDD traceability\n- `## Engine Compatibility` section — checked during the Technical Setup → Pre-Production gate\n\n### `/create-stories` reads ADRs expecting:\n- `### Implementation Guidelines` (under `## Decision`) — the concrete \"must / must never\" patterns programmer agents follow; the ADR template carries this subsection\n- `## ADR Dependencies` table — stories referencing a `Depends On` ADR that is still `Proposed` are automatically set `Status: Blocked`\n\n### `/dev-story` reads ADRs expecting:\n- `## Decision` (full text, verbatim — not summarized)\n- `### Implementation Guidelines` (under `## Decision`, verbatim)\n- `## Engine Compatibility` (post-cutoff API risks, verification required)\n- `## ADR Dependencies` (to detect if this ADR's dependencies are unresolved)\n\n### `/architecture-review` reads ADRs expecting:\n- All required sections present (it flags gaps)\n- `## Status` is set (required for coverage matrix)\n- `## Engine Compatibility` is stamped with the correct engine version\n\n## Known Fragile Points\n- If the ADR number scan misses a file (e.g., a file in a subdirectory of `docs/architecture/` or with a non-standard naming pattern), a duplicate number can be assigned — all ADR files must follow the `adr-NNNN-[slug].md` naming convention at the top level of `docs/architecture/`\n- Acceptance mode moves a story from `Blocked` to `Ready` only when the story file, under `production/epics/`, contains a Blocked Status line in any of the forms `/create-stories` writes (`> **Status**: Blocked`, `**Status:** Blocked`, `Status: Blocked`) and this ADR's id. A story blocked pending this ADR that never names its id is not found, and stays `Blocked` until it is updated by hand\n- The `## GDD Requirements Addressed` table is populated based on what the user tells the skill during the collaborative session; if the user does not know which GDDs motivated the decision, this table may be incomplete — `/create-epics` and `/gate-check` both rely on this linkage for traceability\n- Engine specialist validation (Step 5.5) is skipped only when **both** sources are unset — `engine.name` absent or empty in `project.yaml` **and** `.claude/docs/technical-preferences.md` still reading `[TO BE CONFIGURED]`. A project configured solely via `project.yaml` **does** get specialist validation. When both are unset, post-cutoff engine API risks are not caught before the ADR is written\n- `docs/registry/architecture.yaml` is append-only by design; if a stance entry becomes permanently invalid (not superseded by another ADR), it must be manually removed — there is no cleanup mechanism\n- In retrofit mode, if the existing ADR has sections present but empty (e.g., a `## Status` heading with no value), the skill treats the section as present and does not fill it — an empty Status is effectively invisible to downstream skills like `/story-readiness`\n","isInternal":false,"tokens":2431,"sizeBytes":10803},{"name":"0-accept.md","path":".claude/skills/architecture-decision/references/0-accept.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/architecture-decision/references/0-accept.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# /architecture-decision — Acceptance Mode\n\n> Part of `/architecture-decision`. `SKILL.md` names when to read this file; the settings it\n> resolved and the rules under its later headings still apply here.\n\n**If the argument starts with `accept` followed by an ADR id**\n\n(e.g., `/architecture-decision accept ADR-0005`):\n\nEnter **acceptance mode**. This is the *only* path in the framework that moves an\nADR from `Proposed` to `Accepted`. Authoring always produces `Proposed`\n(Step 5), while\n`/create-control-manifest`, `/create-epics`, `/create-stories` and `/gate-check`\nall require `Accepted` — so without this mode an ADR would enter a state it\nnever leaves.\n\n1. **Resolve the id to a file, then read it.** Glob\n `docs/architecture/adr-NNNN-*.md` for the given number. If **no** file matches,\n or **more than one** does, stop and say which — do not pick one. If the file\n has no `## Status` section, stop and say so; a missing Status is exactly what\n retrofit mode is for.\n2. **Check the current status.** If it is already `Accepted`, say so and stop.\n If it is `Deprecated` or `Superseded`, refuse: reviving a superseded decision\n is a new ADR, not a status edit.\n3. **Check its dependencies first.** Read `## ADR Dependencies`.\n\n **If that section is absent, empty, or reads `UNKNOWN`, do not read it as\n \"no dependencies\" — refuse and say which:**\n > \"ADR-0005's dependency section is [absent / UNKNOWN], so I cannot tell what\n > this decision rests on. An empty dependency list and an unexamined one look\n > identical here, and only one of them is safe to accept. Run\n > `/architecture-decision retrofit ` to establish it.\"\n\n A dependency check reading a field that defaults to empty is the vacuous-pass\n shape this gate exists to prevent — the check would examine nothing and report\n clean.\n\n If it depends on any ADR that is not itself `Accepted`, **refuse and name them**:\n > \"ADR-0005 depends on ADR-0002, which is still Proposed. Accept ADR-0002\n > first — an accepted decision resting on an unaccepted one is not a decision,\n > it is a deferral with a different label.\"\n This is the same dependency rule `/architecture-review` already flags; here it\n is enforced rather than reported.\n4. **Confirm with the user, always.** Per `CONTRACT.md`, acceptance authority is\n **the user, or `technical-director` on the user's explicit confirmation — no\n other agent, and never this skill on its own.** Use `AskUserQuestion`:\n - Prompt: \"Accept ADR-NNNN — [title]? This is what unblocks stories and epics\n that depend on it.\"\n - Options: `[A] Yes — accept it` / `[B] Not yet — leave it Proposed`\n **This prompt fires regardless of `modes.automation`, including `autonomous`.**\n Acceptance is the decision the whole architecture pipeline gates on; it is not\n a step to be inferred.\n5. **Find the stories this will unblock, BEFORE the prompt in step 4.** Grep\n every story for a Blocked Status line —\n `Grep pattern=\"Status\\**:\\**\\s*Blocked\" path=\"production/epics\" glob=\"**/story-*.md\" output_mode=\"files_with_matches\"`,\n which matches `> **Status**: Blocked` (the form `/create-stories` writes),\n `**Status:** Blocked` and `Status: Blocked` — and keep the files that name\n this ADR's id as the reason they are blocked. That pairing is what \"blocked\n pending this ADR\" means — a story blocked for an unrelated reason will not\n name it. Leave out a story that names this ADR only as the successor to point\n at (`point the story at ADR-NNNN`, the note for a `Deprecated` or\n `Superseded` ADR): it is still governed by the old ADR, and accepting the\n successor does not re-point it.\n > **Stories live only under `production/epics/`.** A flat top-level stories\n > directory does not exist and no skill creates one — never write or match a\n > path outside `production/epics/`. `/dev-story` matches entries *by file\n > path*, so a story recorded under any other path silently fails to match and\n > never gets picked up.\n\n Feed the count into step 4's prompt so it reads *\"3 stories become Ready\"*\n rather than a generic claim: **the user is being asked to authorise an effect, and should be\n shown the effect.** If none match, say \"no stories are waiting on this\" — that\n is useful information, not an empty result to omit.\n6. On confirmation, `Edit` the `## Status` line to `Accepted`. Leave an existing\n `## Date` as it is: it records when the ADR was written, and `/create-stories`\n stamps stories with it (or `## Last Verified`), so rewriting it on acceptance\n would make every story drafted against the Proposed ADR look out of date to\n `/dev-story`. **If that section is absent, add it** with today's date — retrofit\n mode already owns this shape, and acceptance must not fail on a template that\n predates the field.\n7. Then set each story found in step 5 from `Blocked` to `Ready`. Unblocking is a\n consequence of acceptance, never of authoring — see Step 6's note below.\n8. Report what moved: the ADR (and its `## Date`, if one was added), and every\n story that became Ready.\n","isInternal":false,"tokens":1322,"sizeBytes":5134},{"name":"0-retrofit.md","path":".claude/skills/architecture-decision/references/0-retrofit.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/architecture-decision/references/0-retrofit.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# /architecture-decision — Retrofit Mode\n\n> Part of `/architecture-decision`. `SKILL.md` names when to read this file; the settings it\n> resolved and the rules under its later headings still apply here.\n\n**If the argument starts with `retrofit` followed by a file path**\n\n(e.g., `/architecture-decision retrofit docs/architecture/adr-0001-event-system.md`):\n\nEnter **retrofit mode**:\n\n1. Read the existing ADR file completely. This step needs the whole ADR: read it\n in ranges by its headings (found with the Grep tool: pattern `^#`, content\n mode), since a whole-file Read over 40 KB is refused.\n2. Identify which template sections are present by scanning headings:\n - `## Status` — **BLOCKING if missing**: `/story-readiness` cannot check ADR acceptance\n - `## ADR Dependencies` — HIGH if missing: dependency ordering breaks\n - `## Engine Compatibility` — HIGH if missing: post-cutoff risk unknown. A\n present table with no **Layer** row is HIGH too: the ADR counts as critical\n wherever it is read, so at `standard` its advisory items become blockers\n - `## GDD Requirements Addressed` — MEDIUM if missing: traceability lost\n - `## Date` — MEDIUM if missing, and no `## Last Verified` either: `/create-stories`\n stamps stories with it and `/dev-story` compares against it, so without it a\n story can never tell whether the ADR changed\n3. Present to the user:\n ```\n ## Retrofit: [ADR title]\n File: [path]\n\n Sections already present (will not be touched):\n ✓ Status: [current value, or \"MISSING — will add\"]\n ✓ [section]\n\n Missing sections to add:\n ✗ Status — BLOCKING (stories cannot validate ADR acceptance without this)\n ✗ ADR Dependencies — HIGH\n ✗ Engine Compatibility — HIGH\n ```\n4. Ask: \"Shall I add the [N] missing sections? I will not modify any existing content.\"\n If no: write nothing, and report the missing sections by name.\n5. If yes:\n - For **Status**: ask the user — \"What is the current status of this decision?\"\n Options: \"Proposed\", \"Accepted\", \"Deprecated\", \"Superseded by ADR-XXXX\"\n An `Accepted` answer — a decision already in force — is not written as\n given: write `Proposed`, add the other missing sections, then run\n acceptance mode (below) on this ADR. Its dependency check, confirmation and\n story unblocking apply here too; it stays the only path that sets `Accepted`.\n - For **ADR Dependencies**: ask — \"Does this decision depend on any other ADR?\n Does it enable or block any other ADR or epic?\" Accept \"None\" for each field.\n - For **Engine Compatibility**: read the engine reference docs (same as Step 1 below)\n and ask the user to confirm the domain. Then generate the table with verified data,\n its Layer row included.\n - For a present Engine Compatibility table with no **Layer** row: find the\n layer as `references/5-generate.md` says under \"Always write the Layer row\",\n and add the row under **Domain**. It adds a row and changes none.\n - For **GDD Requirements Addressed**: ask — \"Which GDD systems motivated this decision?\n What specific requirement in each GDD does this ADR address?\"\n - Append each missing section to the ADR file using the Edit tool.\n - For **Date** (counted only when there is no `## Last Verified`): append\n `## Date` with today's date — even when it is the only missing section, the\n case `/dev-story` sends you here for — and say that it records the retrofit,\n not when the decision was made.\n - **Never modify any existing section.** Only append or fill absent sections.\n6. Suggest: \"Run `/architecture-review` to re-validate coverage now that this ADR\n has its Status and Dependencies fields.\"\n","isInternal":false,"tokens":897,"sizeBytes":3734},{"name":"1-engine-context.md","path":".claude/skills/architecture-decision/references/1-engine-context.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/architecture-decision/references/1-engine-context.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# /architecture-decision — Step 1: Load Engine Context\n\n> Part of `/architecture-decision`. `SKILL.md` names when to read this file; the settings it\n> resolved and the rules under its later headings still apply here.\n\n## 1. Load Engine Context (ALWAYS FIRST)\n\nBefore doing anything else, establish the engine environment:\n\n1. Read `docs/engine-reference/[engine]/VERSION.md` to get:\n - Engine name and version\n - LLM knowledge cutoff date\n - Post-cutoff version risk levels (LOW / MEDIUM / HIGH)\n\n2. Identify the **domain** of this architecture decision from the title or\n user description. Common domains: Physics, Rendering, UI, Audio, Navigation,\n Animation, Networking, Core, Input, Scripting.\n\n3. Read the corresponding module reference if it exists:\n `docs/engine-reference/[engine]/modules/[domain].md`\n\n4. Read `docs/engine-reference/[engine]/breaking-changes.md` — flag any\n changes in the relevant domain that post-date the LLM's training cutoff.\n\n5. Read `docs/engine-reference/[engine]/deprecated-apis.md` — flag any APIs\n in the relevant domain that should not be used.\n\n6. **Display a knowledge gap warning** before proceeding if the domain carries\n MEDIUM or HIGH risk:\n\n ```\n ⚠️ ENGINE KNOWLEDGE GAP WARNING\n Engine: [name + version]\n Domain: [domain]\n Risk Level: HIGH — This version is post-LLM-cutoff.\n\n Key changes verified from engine-reference docs:\n - [Change 1 relevant to this domain]\n - [Change 2]\n\n This ADR will be cross-referenced against the engine reference library.\n Proceed with verified information only — do NOT rely solely on training data.\n ```\n\n If no engine has been configured yet, prompt: \"No engine is configured.\n Run `/setup-engine` first, or tell me which engine you are using.\"\n\n---\n","isInternal":false,"tokens":420,"sizeBytes":1788},{"name":"3-gather-context.md","path":".claude/skills/architecture-decision/references/3-gather-context.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/architecture-decision/references/3-gather-context.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# /architecture-decision — Steps 3a and 3b: Gather Context\n\n> Part of `/architecture-decision`. `SKILL.md` names when to read this file; the settings it\n> resolved and the rules under its later headings still apply here.\n\n## 3. Gather context\n\n### 3a: Architecture Registry Check (BLOCKING gate) — do this FIRST\n\nRead `docs/registry/architecture.yaml`. Extract entries relevant to this ADR's\ndomain and decision (grep by system name, domain keyword, or state being touched).\nRun this before reading any existing ADR — the registry exists specifically so a\nnew ADR's author does not need to open prior ADRs to learn their binding facts\n(state ownership, interface contracts, forbidden patterns).\n\nPresent any relevant stances to the user **before** the collaborative design\nbegins, as locked constraints:\n\n```\n## Existing Architectural Stances (must not contradict)\n\nState Ownership:\n player_health → owned by health-system (ADR-0001)\n Interface: HealthComponent.current_health (read-only float)\n → If this ADR reads or writes player health, it must use this interface.\n\nInterface Contracts:\n damage_delivery → signal pattern (ADR-0003)\n Signal: damage_dealt(amount, target, is_crit)\n → If this ADR delivers or receives damage events, it must use this signal.\n\nForbidden Patterns:\n ✗ autoload_singleton_coupling (ADR-0001)\n ✗ direct_cross_system_state_write (ADR-0000)\n → The proposed approach must not use these patterns.\n```\n\nIf the user's proposed decision would contradict any registered stance, surface\nthe conflict immediately:\n\n> \"⚠️ Conflict: This ADR proposes [X], but ADR-[NNNN] established that [Y] is\n> the accepted pattern for this purpose. Proceeding without resolving this will\n> produce contradictory ADRs and inconsistent stories.\n> Options: (1) Align with the existing stance, (2) Supersede ADR-[NNNN] with\n> an explicit replacement, (3) Explain why this case is an exception.\"\n\nDo not proceed to Step 4 (collaborative design) until any conflict is resolved\nor explicitly accepted as an intentional exception.\n\n### 3b: Existing ADRs and Related GDDs — registry-scoped, never unbounded\n\nThe registry (3a) covers *what* prior decisions bind — not always *why*. If the\nregistry surfaced a directly relevant ADR and its reasoning matters here (not\njust its stated facts), read that specific ADR — never glob-and-read every\nADR in `docs/architecture/` on the chance one is relevant. Read it by section:\nfind the headings you need with the Grep tool (pattern `^#`, content mode)\nand Read those ranges with offset and limit.\n\n1. **Map its headings first** (cheap):\n ```\n Grep pattern=\"^## \" path=\"docs/architecture/[adr-file].md\" output_mode=\"content\" -n\n ```\n2. **Under ~40KB** (`Bash: wc -c \"docs/architecture/[adr-file].md\"`) — one full\n `Read` is fine; per-call overhead exceeds the savings from bounded reads at\n this size.\n3. **~40KB or larger** — bounded-read only `## Context`, `## Decision`, and\n `## Consequences` (the sections that carry reasoning, not just facts) via\n `Read(offset, limit)` from the heading map.\n\nRead GDDs the same way `/design-system` Step 2b does: only GDDs the registry\nor the ADR list names as directly relevant, and only their `## Dependencies`,\n`## Formulas`, and `## Edge Cases` sections\n(`Grep pattern=\"^## (Dependencies|Formulas|Edge Cases)\" ... -A 40`) — never a\nspeculative full read of `design/gdd/*.md` looking for anything that might\nrelate.\n\nSkip 3b entirely if the registry already answers everything this decision\nneeds — most ADRs will.\n\n---\n","isInternal":false,"tokens":869,"sizeBytes":3561},{"name":"4-decide.md","path":".claude/skills/architecture-decision/references/4-decide.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/architecture-decision/references/4-decide.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# /architecture-decision — Step 4: Guide the Decision Collaboratively\n\n> Part of `/architecture-decision`. `SKILL.md` names when to read this file; the settings it\n> resolved and the rules under its later headings still apply here.\n\n## 4. Guide the decision collaboratively\n\nBefore asking anything, derive the skill's best guesses from the context already\ngathered (GDDs read, engine reference loaded, existing ADRs scanned). Then present\na **confirm/adjust** prompt using `AskUserQuestion` — not open-ended questions.\n\n**Derive assumptions first:**\n- **Problem**: Infer from the title + GDD context what decision needs to be made\n- **Alternatives**: Propose 2-3 concrete options from engine reference + GDD requirements\n- **Dependencies**: Scan existing ADRs for upstream dependencies. **If the scan is\n inconclusive, present `UNKNOWN — scan inconclusive, please confirm`, never\n `None`.** The two are not interchangeable: `None` asserts that nothing upstream\n constrains this decision, and a user confirming a prefilled list cannot tell an\n assertion from a guess. This field is load-bearing — `/architecture-review`\n flags unaccepted dependencies, `/dev-story` reads it, and the acceptance route\n in Phase 0 **refuses to accept an ADR whose dependencies are not themselves\n Accepted**. A dependency list that defaulted to empty makes that check pass\n while examining nothing. `UNKNOWN` must be resolved during the confirm/adjust\n prompt; it is a prompt state, never a value written to the file\n- **GDD linkage**: Extract which GDD systems the title directly relates to\n- **Status**: Always `Proposed` for new ADRs — never ask the user what the status is\n\n**Scope of assumptions tab**: Assumptions cover only: problem framing, alternative approaches, upstream dependencies, GDD linkage, and status. Schema design questions (e.g., \"How should spawn timing work?\", \"Should data be inline or external?\") are NOT assumptions — they are design decisions belonging to a separate step after the assumptions are confirmed. Do not include schema design questions in the assumptions AskUserQuestion widget.\n\n**After assumptions are confirmed**, if the ADR involves schema or data design choices, use a separate multi-tab `AskUserQuestion` to ask each design question independently before drafting.\n\n**Present assumptions with `AskUserQuestion`:**\n\n```\nHere's what I'm assuming before drafting:\n\nProblem: [one-sentence problem statement derived from context]\nAlternatives I'll consider:\n A) [option derived from engine reference]\n B) [option derived from GDD requirements]\n C) [option from common patterns]\nGDD systems driving this: [list derived from context]\nDependencies: [upstream ADRs if any, otherwise \"None\"]\nStatus: Proposed\n\n[A] Proceed — draft with these assumptions\n[B] Change the alternatives list\n[C] Adjust the GDD linkage\n[D] Add a performance budget constraint\n[E] Something else needs changing first\n```\n\nDo not generate the ADR until the user confirms assumptions or provides corrections.\n\n**After engine specialist and TD reviews return** (Step 5.5/5.6), if unresolved\ndecisions remain, present each one as a separate `AskUserQuestion` with the proposed\noptions as choices plus a free-text escape:\n\n```\nDecision: [specific unresolved point]\n[A] [option from specialist review]\n[B] [alternative option]\n[C] Different approach — I'll describe it\n```\n\n**ADR Dependencies** — derive from existing ADRs, then confirm:\n- Does this decision depend on any other ADR not yet Accepted?\n- Does it unlock or unblock any other ADR or epic?\n- Does it block any specific epic from starting?\n\nRecord answers in the **ADR Dependencies** section. Write \"None\" for each field if no constraints apply.\n\n---\n","isInternal":false,"tokens":821,"sizeBytes":3727},{"name":"5-generate.md","path":".claude/skills/architecture-decision/references/5-generate.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/architecture-decision/references/5-generate.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# /architecture-decision — Step 5: Generate the ADR\n\n> Part of `/architecture-decision`. `SKILL.md` names when to read this file; the settings it\n> resolved and the rules under its later headings still apply here.\n\n## 5. Generate the ADR\n\n**In this file:**\n\n- The ADR template\n- 5.5 Engine Specialist Validation\n- 5.6 Technical Director Strategic Review, with the review mode check\n- 5.7 GDD Sync Check: found, none found, could not check\n- Write approval\n- Update Architecture Registry, and the registry append logic\n\nFollowing this format:\n\n```markdown\n# ADR-[NNNN]: [Title]\n\n## Status\n[Proposed | Accepted | Deprecated | Superseded by ADR-XXXX]\n\n## Date\n[Date of decision]\n\n## Last Verified\n[YYYY-MM-DD — when this ADR was last confirmed accurate against the current\nengine version and design. Update this date when you re-read and confirm it is\nstill correct, even if nothing changed.]\n\n## Decision Makers\n[Who was involved in this decision]\n\n## Summary\n[2 sentences: what problem this ADR solves, and what was decided. Written for\ntiered context loading — a skill scanning 20 ADRs uses this to decide whether to\nread the full decision. Be specific: name the system, the problem, and the\nchosen approach.]\n\n## Engine Compatibility\n\n| Field | Value |\n|-------|-------|\n| **Engine** | [e.g. Godot 4.7] |\n| **Domain** | [Physics / Rendering / UI / Audio / Navigation / Animation / Networking / Core / Input] |\n| **Layer** | [Foundation / Core / Feature / Presentation] |\n| **Knowledge Risk** | [LOW / MEDIUM / HIGH — from VERSION.md] |\n| **References Consulted** | [List engine-reference docs read, e.g. `docs/engine-reference/godot/modules/physics.md`] |\n| **Post-Cutoff APIs Used** | [Any APIs from post-LLM-cutoff versions this decision depends on, or \"None\"] |\n| **Verification Required** | [Specific behaviours to test before shipping, or \"None\"] |\n\n## ADR Dependencies\n\n| Field | Value |\n|-------|-------|\n| **Depends On** | [ADR-NNNN (must be Accepted before this can be implemented), or \"None\"] |\n| **Enables** | [ADR-NNNN (this ADR unlocks that decision), or \"None\"] |\n| **Blocks** | [Epic/Story name — cannot start until this ADR is Accepted, or \"None\"] |\n| **Ordering Note** | [Any sequencing constraint that isn't captured above] |\n\n## Context\n\n### Problem Statement\n[What problem are we solving? Why does this decision need to be made now?]\n\n### Constraints\n- [Technical constraints]\n- [Timeline constraints]\n- [Resource constraints]\n- [Compatibility requirements]\n\n### Requirements\n- [Must support X]\n- [Must perform within Y budget]\n- [Must integrate with Z]\n\n## Decision\n\n[The specific technical decision made, described in enough detail for someone\nto implement it.]\n\n### Architecture Diagram\n[ASCII diagram or description of the system architecture this creates]\n\n### Key Interfaces\n[API contracts or interface definitions this decision creates]\n\n### Implementation Guidelines\n[Specific guidance for the programmer implementing this decision — the rules a\n`/create-control-manifest` or `/dev-story` run should follow. State mandates as\n\"must / must never\" so they extract cleanly.]\n\n## Alternatives Considered\n\n### Alternative 1: [Name]\n- **Description**: [How this would work]\n- **Pros**: [Advantages]\n- **Cons**: [Disadvantages]\n- **Rejection Reason**: [Why this was not chosen]\n\n### Alternative 2: [Name]\n- **Description**: [How this would work]\n- **Pros**: [Advantages]\n- **Cons**: [Disadvantages]\n- **Rejection Reason**: [Why this was not chosen]\n\n## Consequences\n\n### Positive\n- [Good outcomes of this decision]\n\n### Negative\n- [Trade-offs and costs accepted]\n\n## Risks\n- [Things that could go wrong]\n- [Mitigation for each risk]\n\n## GDD Requirements Addressed\n\n| GDD System | Requirement | How This ADR Addresses It |\n|------------|-------------|--------------------------|\n| [system-name].md | [specific rule, formula, or performance constraint from that GDD] | [how this decision satisfies it] |\n\n## Performance Implications\n- **CPU**: [Expected impact]\n- **Memory**: [Expected impact]\n- **Load Time**: [Expected impact]\n- **Network**: [Expected impact, if applicable]\n\n## Migration Plan\n[If this changes existing code, how do we get from here to there?]\n\n## Validation Criteria\n[How will we know this decision was correct? What metrics or tests?]\n\n## Related\n- [Links to related ADRs — note if supersedes, contradicts, or depends on]\n- [Links to related design documents]\n```\n\n**Always write the Layer row.** An ADR with no Layer row counts as critical\n(Foundation) wherever it is read, so at `standard` its advisory items become\nblockers. The value is the ADR's own layer, how early in the build it must\nexist: the layer `docs/architecture/architecture.md`'s layer map gives the\nsystem this decision governs. With no layer map, or no system in it, ask the\nuser, with the four values as options. Never take it from an epic that\nreferences the ADR, and never reuse a `Domain` value (the template's note under\nEngine Compatibility says why).\n\n5.5. **Engine Specialist Validation** — Before saving, spawn the **primary engine specialist** via `Agent` to validate the drafted ADR:\n - Resolve the primary specialist: `-specialist` derived from `engine.name` in `project.yaml` (Godot→`godot-specialist`, Unity→`unity-specialist`, Unreal→`unreal-specialist`); if `engine.name` is absent or empty, read the Primary line of the `## Engine Specialists` section in `.claude/docs/technical-preferences.md`\n - If no engine is configured (neither source yields an engine), skip this step **Record ``Engine validation: NOT ASSESSED — no engine configured (`engine.name` unset in `project.yaml`)`` in this run's output.** A skipped check that says nothing is indistinguishable from a check that passed; the reader cannot tell engine guidance was never sought.\n - Spawn `subagent_type: [primary specialist]` with: the ADR's Engine Compatibility section, Decision section, Key Interfaces, and the engine reference docs path. Ask them to:\n 1. Confirm the proposed approach is idiomatic for the pinned engine version\n 2. Flag any APIs or patterns that are deprecated or changed post-training-cutoff\n 3. Identify engine-specific risks or gotchas not captured in the current ADR draft\n - If the specialist identifies a **blocking issue** (wrong API, deprecated approach, engine version incompatibility): revise the Decision and Engine Compatibility sections accordingly, then confirm the changes with the user before proceeding\n - If the specialist finds **minor notes** only: incorporate them into the ADR's Risks subsection\n\n**Review mode check** — apply before spawning TD-ADR:\n- `solo` → skip. Note: \"TD-ADR skipped — Solo mode.\" Proceed to Step 5.7 (GDD sync check).\n- `lean` → skip (not a PHASE-GATE). Note: \"TD-ADR skipped — Lean mode.\" Proceed to Step 5.7 (GDD sync check).\n- `full` → spawn as normal.\n\n5.6. **Technical Director Strategic Review** — After the engine specialist validation, spawn `technical-director` via `Agent` using gate **TD-ADR** (`.claude/docs/director-gates/td-adr.md`):\n - Pass: the ADR file path (or draft content), engine version, domain, any existing ADRs in the same domain\n - The TD validates architectural coherence (is this decision consistent with the whole system?) — distinct from the engine specialist's API-level check\n - On CONCERNS: show them to the user verbatim and ask with the standard options from `director-gates.md` — `Revise flagged items` / `Accept and proceed` / `Discuss further`. Revise the flagged Decision or Alternatives sections only on `Revise flagged items`.\n - On REJECT: show the blockers verbatim and revise the Decision or Alternatives sections before proceeding.\n - A revised draft still reaches the user through the write approval below; nothing is written before it. A `NOT ASSESSED` answer is not an approval — name the missing input (`director-gates.md`).\n\n5.7. **GDD Sync Check** — Before presenting the write approval, scan all GDDs\nreferenced in the \"GDD Requirements Addressed\" section for naming inconsistencies\nwith the ADR's Key Interfaces and Decision sections (renamed signals, API methods,\nor data types). If any are found, surface them as a **prominent warning block**\nimmediately before the write approval — not as a footnote:\n\n```\n⚠️ GDD SYNC REQUIRED\n[gdd-filename].md uses names this ADR has renamed:\n [old_name] → [new_name_from_adr]\n [old_name_2] → [new_name_2_from_adr]\nThe GDD must be updated before or alongside writing this ADR to prevent\ndevelopers reading the GDD from implementing the wrong interface.\n```\n\n**This check has three outcomes, not two.** The two above are \"found\" and \"none\nfound\"; the third is **could not check**, which must never take the silent\nbranch and render like a clean result.\n\n- **None found** — print one line, do not stay silent:\n `GDD sync: checked [N] referenced GDD(s), no naming inconsistencies.`\n A silent pass is indistinguishable from a check that never ran, and this one\n guards against developers implementing the wrong interface from a stale GDD.\n- **Could not check** — the ADR has no `GDD Requirements Addressed` section, it\n names no GDDs, or a named GDD does not exist on disk. Print:\n `GDD sync: NOT ASSESSED — [which reason, and which files]`\n Do **not** treat an ADR that references no GDDs as one whose GDDs are\n consistent. Nothing was compared.\n\nOnly the warning block itself is conditional; the check always reports.\n\n5. **Write approval** — Use `AskUserQuestion`:\n\nIf GDD sync issues were found:\n- \"ADR draft is complete. How would you like to proceed?\"\n - [A] Write ADR + update GDD in the same pass\n - [B] Write ADR only — I'll update the GDD manually\n - [C] Not yet — I need to review further\n\nIf no GDD sync issues:\n- \"ADR draft is complete. May I write it?\"\n - [A] Write ADR to `docs/architecture/adr-[NNNN]-[slug].md`\n - [B] Not yet — I need to review further\n\nIf yes to any write option, write the file, creating the directory if needed.\nFor option [A] with GDD update: also update the GDD file(s) to use the new names.\n\n6. **Update Architecture Registry**\n\nScan the written ADR for new architectural stances that should be registered:\n- State it claims ownership of\n- Interface contracts it defines (signal signatures, method APIs)\n- Performance budget it claims\n- API choices it makes explicitly\n- Patterns it bans (Consequences → Negative or explicit \"do not use X\")\n\nPresent candidates:\n```\nRegistry candidates from this ADR:\n NEW state ownership: player_stamina → stamina-system\n NEW interface contract: stamina_depleted signal\n NEW performance budget: stamina-system: 0.5ms/frame\n NEW forbidden pattern: polling stamina each frame (use signal instead)\n EXISTING (referenced_by update only): player_health → already registered ✅\n```\n\n**Registry append logic**: When writing to `docs/registry/architecture.yaml`, do NOT assume sections are empty. The file may already have entries from previous ADRs written in this session. Before each Edit call:\n1. Read the current state of `docs/registry/architecture.yaml`\n2. Find the correct section (state_ownership, interfaces, forbidden_patterns, api_decisions)\n3. If the section is still the empty list (`state_ownership: []`), replace `[]` with the first entry: the key alone on its line, the entry below it indented two spaces as in the file's commented example. An entry appended after `[]` makes the file invalid YAML. Otherwise append the new entry AFTER the last existing entry in that section\n4. If the section has entries already, use the closing content of the last entry as the `old_string` anchor, and append the new entry after it\n\n**BLOCKING — do not write to `docs/registry/architecture.yaml` without explicit user approval.**\n\nAsk using `AskUserQuestion`:\n- \"May I update `docs/registry/architecture.yaml` with these [N] new stances?\"\n - Options: \"Yes — update the registry\", \"Not yet — I want to review the candidates\", \"Skip registry update\"\n\nOnly proceed if the user selects yes. If yes: append new entries. Never modify existing entries — if a stance is\nchanging, set the old entry to `status: \"superseded_by: ADR-[NNNN]\"` and add the new entry. Keep the quotes:\nunquoted, the second colon makes the file invalid YAML.\n\nAfter writing, run `bash .claude/scripts/registry.sh validate` and fix every row about an entry this write added\nor changed (a DUPLICATE, STATUS or LAYOUT row, an UNQUOTED row (quote the value it names), or a PATH_MISSING row for a path it named) before you go on; name\nrows about other entries to the user rather than fixing them unasked. If the script is missing or prints nothing,\nsay the registry check did not run, then re-read the entries you wrote against the rules in the file's header.\n\n---\n","isInternal":false,"tokens":3086,"sizeBytes":12804},{"name":"SKILL.md","path":".claude/skills/architecture-decision/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/architecture-decision/SKILL.md","title":"architecture-decision","category":"anthropic-skill","format":"markdown","content":"---\nname: architecture-decision\ndescription: \"Create an ADR documenting a technical decision: context, alternatives considered, consequences.\"\nargument-hint: \"[title | retrofit | accept ] [--review full|lean|solo]\"\nuser-invocable: true\nallowed-tools: Read, Glob, Grep, Write, Edit, Agent, AskUserQuestion, Bash(wc -c *), Bash(bash \"*/.claude/skills/architecture-decision/../../hooks/yaml-helper.sh\" resolve_config *), Bash(bash .claude/scripts/registry.sh *)\nmodel: sonnet\n---\n\n!`bash \"${CLAUDE_SKILL_DIR}/../../hooks/yaml-helper.sh\" resolve_config --keys review_mode,automation,workflow,docs.density,team.size`\n\nResolved above — use as-is; `--review` overrides `review_mode`. No block →\ndefaults in `.claude/docs/config-resolution.md`.\n\n# Architecture Decision\n\nWhen this skill is invoked:\n\n## 0. Parse Arguments — Detect Retrofit / Acceptance Mode\n\nSee `.claude/docs/director-gates.md` for the full check pattern. Individual gate definitions live in `.claude/docs/director-gates/[gate-id].md` — the spawned agent reads its own gate file; do not read it in the parent session.\n\nEvery `AskUserQuestion` call follows `.claude/docs/automation-modes.md`\n(collaborative asks always · guided major-only · autonomous logs and proceeds;\n`automation_always_ask` categories always prompt).\n\n**`team.size`**: which agents validate this ADR (orthogonal to review_mode/workflow).\n- **`individual`** (default): `technical-director` (TD-ADR) + the engine-specialist.\n- **`small`** and **`studio`**: the same two. This skill spawns no engine\n sub-specialist and no adversarial reviewer at any size.\n\n**`docs.density`** — it controls the *depth* of the ADR's prose sections, not\nwhich sections the skeleton emits (that is fixed). `modes.rigor` sets it\nalongside `workflow`; set `docs.density` explicitly to vary ADR verbosity alone:\n`terse` (the default, via `rigor: minimal`) = decision + alternatives as bullets, one line of rationale each;\n`balanced` = paragraph per section with light rationale (`rigor: standard`); `thorough` =\nfull prose with trade-offs and worked rationale in Decision, Alternatives, and\nConsequences. Apply it to the prose sections; the Engine Compatibility, ADR\nDependencies, and GDD Requirements tables are structural and stay whole at every\ndensity.\n\n**`workflow`** (see `.claude/docs/workflow-modes.md`):\n- `full` — all ADRs on the required ADR list must be completed.\n- `standard` — critical ADRs only (Foundation-layer systems).\n- `minimal` — not required. Can still be run voluntarily.\n\n**If the argument starts with `retrofit` followed by a file path**\n\n**Read `references/0-retrofit.md` now and follow it** — this phase's steps are in that file, not here. Read it again if the conversation was compacted or resumed during this phase.\n\n**If the argument starts with `accept` followed by an ADR id**\n\n**Read `references/0-accept.md` now and follow it** — this phase's steps are in that file, not here. Read it again if the conversation was compacted or resumed during this phase.\n\nIf NOT in retrofit or acceptance mode, proceed to Step 1 below (normal ADR authoring).\n\n**No-argument guard**: If no argument was provided (title is empty), ask before\nrunning Phase 0:\n\n> \"What technical decision are you documenting? Please provide a short title\n> (e.g., `event-system-architecture`, `physics-engine-choice`).\"\n\nUse the user's response as the title, then proceed to Step 1.\n\n---\n\n## 1. Load Engine Context (ALWAYS FIRST)\n\n**Read `references/1-engine-context.md` now and follow it** — this phase's steps are in that file, not here. Read it again if the conversation was compacted or resumed during this phase.\n\n## 2. Determine the next ADR number\n\nScan `docs/architecture/` for existing ADRs to find the next number.\n\n---\n\n## 3. Gather context\n\n**Read `references/3-gather-context.md` now and follow it** — this phase's steps are in that file, not here. Read it again if the conversation was compacted or resumed during this phase.\n\n## 4. Guide the decision collaboratively\n\n**Read `references/4-decide.md` now and follow it** — this phase's steps are in that file, not here. Read it again if the conversation was compacted or resumed during this phase.\n\n## 5. Generate the ADR\n\n**Read `references/5-generate.md` now and follow it** — this phase's steps are in that file, not here. Read it again if the conversation was compacted or resumed during this phase.\n\n## 6. Closing Next Steps\n\nAfter the ADR is written (and registry optionally updated), close with `AskUserQuestion`.\n\nBefore generating the widget:\n1. Read the `## Required ADRs` section of `docs/architecture/architecture.md` (by section) and list `docs/architecture/adr-*.md`: a required ADR with no file is still unwritten. Without `architecture.md`, look for ADRs flagged in technical-preferences.md or systems-index.md as prerequisites\n2. Check if all prerequisite ADRs are now written. If yes, include a \"Start writing GDDs\" option.\n3. List ALL remaining priority ADRs as individual options — not just the next one or two.\n\nWidget format:\n```\nADR-[NNNN] written and registry updated. What would you like to do next?\n[1] Write [next-priority-adr-name] — [brief description from prerequisites list]\n[2] Write [another-priority-adr] — [brief description] (include ALL remaining ones)\n[N] Start writing GDDs — run `/design-system [first-undesigned-system]` (only show if all prerequisite ADRs are written)\n[N+1] Stop here for this session\n```\n\nIf there are no remaining priority ADRs and no undesigned GDD systems, offer only \"Stop here\" and suggest running `/architecture-review` in a fresh session.\n\n**Always include this fixed notice in the closing output (do NOT omit it):**\n\n> To validate ADR coverage against your GDDs, open a **fresh Claude Code session**\n> and run `/architecture-review`.\n>\n> **Never run `/architecture-review` in the same session as `/architecture-decision`.**\n> The reviewing agent must be independent of the authoring context to give an unbiased\n> assessment. Running it here would invalidate the review.\n\n**Do NOT unblock stories here.** This ADR is `Proposed` — Step 5 guarantees it,\nand a story blocked *pending this decision* is still pending it. Unblocking on\nauthoring defeats the guard at the moment it becomes relevant: the pipeline\nappears to flow while running on decisions nobody has accepted.\n\nInstead, tell the user what is now waiting on acceptance:\n\n> \"ADR-NNNN is written and `Proposed`. [N] stories remain `Blocked` pending it.\n> Run `/architecture-decision accept ADR-NNNN` when the decision is settled —\n> that is what moves them to `Ready`.\"\n\nList the blocked stories by path so the cost of leaving it Proposed is visible.\n(Acceptance has consequences enforced across many skills and an authority\nrecorded in only a few, so the route between them must stay explicit.)\n","frontmatter":{"name":"architecture-decision","description":"Create an ADR documenting a technical decision: context, alternatives considered, consequences.","argument-hint":"[title | retrofit | accept ] [--review full|lean|solo]","user-invocable":true,"allowed-tools":"Read, Glob, Grep, Write, Edit, Agent, AskUserQuestion, Bash(wc -c *), Bash(bash \"*/.claude/skills/architecture-decision/../../hooks/yaml-helper.sh\" resolve_config *), Bash(bash .claude/scripts/registry.sh *)","model":"sonnet","allowedTools":["Read,","Glob,","Grep,","Write,","Edit,","Agent,","AskUserQuestion,","Bash(wc","-c","*),","Bash(bash","\"*/.claude/skills/architecture-decision/../../hooks/yaml-helper.sh\"","resolve_config","*),","Bash(bash",".claude/scripts/registry.sh","*)"]},"allowedTools":["Read,","Glob,","Grep,","Write,","Edit,","Agent,","AskUserQuestion,","Bash(wc","-c","*),","Bash(bash","\"*/.claude/skills/architecture-decision/../../hooks/yaml-helper.sh\"","resolve_config","*),","Bash(bash",".claude/scripts/registry.sh","*)"],"isInternal":false,"tokens":1653,"sizeBytes":6849},{"name":"1-load.md","path":".claude/skills/architecture-review/references/1-load.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/architecture-review/references/1-load.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# /architecture-review — Phase 1: Load Everything\n\n> Part of `/architecture-review`. `SKILL.md` names when to read this file; the settings it\n> resolved and the rules under its later headings still apply here.\n\n## Phase 1: Load Everything\n\n**In this file:**\n\n- Phase 1a — L0: Summary Scan (fast, low tokens)\n- Phase 1b — L1/L2: Targeted Section Load\n- Design Documents\n- Architecture Documents\n- Engine Reference\n- Project Standards\n\n### Phase 1a — L0: Summary Scan (fast, low tokens)\n\n**Freshness check before any scan.** A prior report can stand in for this run\nonly if nothing it rests on has changed: the documents, the engine reference,\nthe project config, this skill, and the kind of review that produced it.\n\nIn `rtm` mode, skip the check and say so — *\"Freshness check: not run — rtm\nbuilds the matrix fresh, because stories and tests change without any review\ninput changing.\"*\n\nOtherwise locate the latest prior report — Glob\n`docs/architecture/architecture-review-*.md` and take the newest — and check\n**the review inputs**: every file the phases below read that can change a\nfinding or the verdict. `[engine]` is the lowercased `engine.name` from\n`project.yaml`, the value Phase 5 uses; with no engine configured, leave the two\nengine-reference paths out.\n\n```\nBash: bash .claude/scripts/review-receipts.sh check \"[latest-report]\" docs/architecture/adr-*.md design/gdd/*.md docs/architecture/tr-registry.yaml docs/architecture/architecture.md docs/engine-reference/[engine]/*.md docs/engine-reference/[engine]/modules/*.md project.yaml .claude/docs/technical-preferences.md docs/consistency-failures.md .claude/skills/architecture-review/SKILL.md .claude/skills/architecture-review/references/*.md\n```\n\nPhase 8 stamps the same list into this run's report; keep the two identical,\nand add any file a phase starts reading to both. The check also compares every\nfile the prior report stamped, named here or not, and prints `GONE:` for one\nthat no longer exists.\n\nThen read the prior report's `Mode:` and `Workflow:` lines. It **covers** this\nrun only when its Mode is this run's mode (for `single-gdd`, the same path) or\n`full`, and its Workflow is this run's resolved `workflow` or `full`. A report\nwithout those lines was written before they existed and covers nothing.\n\n- **Any `UNRESOLVED`** — check this FIRST; it disqualifies every option\n below. A glob matched no file, so that whole document class was never\n examined and the comparison covered less than it appears to. Say which\n pattern came back unresolved, and neither stand on the prior report nor\n scope a re-run from it: an ADR or GDD directory that is empty, renamed or\n misspelled is a finding about the project. Run the review as asked; its\n verdict is NOT ASSESSED for the missing class (Phase 7), never a stop with\n no report. Never read a set of `UNCHANGED` lines as\n \"everything is current\" while an `UNRESOLVED` line is present — the set\n compared was not the set requested.\n- **The prior report does not cover this run** — check this second, whatever\n the other lines say. Say why: *\"The last report was a [mode] review at\n workflow [tier]; it does not cover this run.\"* Run the review as asked.\n Never offer to stand on it or to scope a re-run from it.\n- **Everything `UNCHANGED`** — nothing this review reads has changed since\n that report; re-running reproduces it. Surface the prior report's date,\n mode and verdict and offer via `AskUserQuestion`: `[A] Stand on the prior\n report (Recommended)` / `[B] Re-run the full review anyway` — `guided`\n proceeds with [A] and notes it; `autonomous` logs via `log_decision` and\n stands on the prior report.\n- **Only GDDs or ADRs `CHANGED`/`NEW`** — name them, then scope instead of\n re-running everything: recommend `/architecture-review single-gdd [path]`\n for just the changed systems. A full re-run stays available on request, and\n a `NEW` ADR warrants one.\n- **Anything else `CHANGED`, `NEW` or `GONE`** — a deleted GDD or ADR, the TR\n registry, `architecture.md`, the engine reference, `project.yaml`,\n `technical-preferences.md`, `consistency-failures.md`, or this skill's own\n files. These reach every phase, so recommend re-running the review as\n asked, never a `single-gdd` scope, and name each input with what it\n affects — e.g. *\"The engine reference changed after the\n last report: its deprecated-API audit, which `/gate-check` reads, was made\n against the old one.\"*\n- **`RECEIPT: NONE`** — no prior report, or one written before receipts\n existed. Proceed with the full review; this run's report will carry the\n first stamps.\n\nBefore reading any full document, use Grep to extract `## Summary` sections\nfrom all GDDs and ADRs:\n\n```\nGrep pattern=\"## Summary\" glob=\"design/gdd/*.md\" output_mode=\"content\" -A 4\nGrep pattern=\"## Summary\" glob=\"docs/architecture/adr-*.md\" output_mode=\"content\" -A 3\n```\n\n**Fail open on a missing Summary.** Establish the denominator: glob\n`design/gdd/*.md` and count **N**. A scan matching fewer than N means those GDDs\npredate `## Summary` (`/design-system` emits it, but older GDDs lack it) — never\ntreat an absent Summary as a system out of scope. A zero-match scan means \"no GDD\ncarries a Summary yet\", not \"nothing to review\": full-read the unmatched set.\n\nFor `single-gdd [path]` mode: use the target GDD's summary to identify which\nADRs reference the same system (Grep ADRs for the system name), then load only\nthose ADRs' sections per Phase 1b. Skip unrelated GDDs entirely.\n\nFor `engine` mode: load ADR sections only — GDDs are not needed for engine checks.\nIn practice this is the `## Engine Compatibility` scan alone.\n\nFor `coverage` or `full` mode: proceed to Phase 1b for the full in-scope set.\n**This is a section load, not a full-file load** — see below for why, and for the\nnarrow cases that still justify escalating to a whole document.\n\n### Phase 1b — L1/L2: Targeted Section Load\n\nLoad the sections the later phases actually consume — **not whole files**. This\nskill reads the two largest document sets in the project (every GDD *and* every\nADR); at realistic sizes a full load of both exhausts the context window before\nPhase 2 starts, and most of what it loads is narrative this skill never uses.\n\n**Establish the denominator first.** Glob `design/gdd/*.md` and count **N_gdd**;\nglob `docs/architecture/adr-*.md` and count **N_adr**. Report both. A section\nscan matching fewer than the denominator means those documents lack the section —\n**never treat an absent section as an absent document.** The scan narrows the\n*read* set; it never shrinks the *in-scope* set.\n\n### Design Documents\n\nPhase 2 extracts *technical requirements* — data structures, performance\nconstraints, engine capabilities, cross-system communication, persistence,\nthreading, platform needs. Those live in a known set of sections; Overview and\nPlayer Fantasy are narrative and yield none.\n\n```\nGrep pattern=\"^## (Detailed Rules|Detailed Design|Formulas|Dependencies|Tuning Knobs|Acceptance Criteria)\" glob=\"design/gdd/*.md\" output_mode=\"content\" -A 40\n```\n\nAccept **either** `## Detailed Rules` or `## Detailed Design` — the design\nstandard and the GDD template disagree on the name and they denote the same\nrequired section. Full-read a single GDD only when a scanned section\ncross-references material outside itself, or when a GDD matched zero sections\n(it predates the template — read it whole and say so).\n\n- `design/gdd/systems-index.md` — the authoritative list of systems; read whole (small, and it is an index)\n\n### Architecture Documents\n\nPhases 3–5 need the traceability table, the decision itself, engine claims, and\nthe dependency edges — not Context, Consequences, Alternatives, Migration Plan or\nValidation Criteria, which explain *why* a decision was made.\n\n```\nGrep pattern=\"^## (Status|Decision|GDD Requirements Addressed|Engine Compatibility|ADR Dependencies|Performance Implications)\" glob=\"docs/architecture/adr-*.md\" output_mode=\"content\" -A 30\n```\n\nInterpret against **N_adr**, and distinguish the two zero-match cases — they are\nnot the same finding:\n\n| Result | Meaning | Action |\n|---|---|---|\n| N_adr matches | Normal. | Proceed on the scanned sections. |\n| Some ADRs match, some do not | Those ADRs are missing sections. | Record each as a **structural gap** in the Phase 7 report — a missing `## GDD Requirements Addressed` is itself a traceability finding. |\n| **0 matches, N_adr > 0** | **Malformed ADRs**, not \"no architecture\". | \"[N_adr] ADRs found, none carries a scannable section — run `/architecture-decision retrofit [file]` on each.\" Do **not** report zero coverage; that would read as a design failure when it is a format failure. |\n\nEscalate to a full read of one ADR only when judging a conflict needs its\nreasoning (Phase 4) — that is a per-ADR decision, not a blanket load.\n\n- `docs/architecture/architecture.md` if it exists\n\n### Engine Reference\n- `docs/engine-reference/[engine]/VERSION.md`\n- `docs/engine-reference/[engine]/breaking-changes.md`\n- `docs/engine-reference/[engine]/deprecated-apis.md`\n- **Only the module docs the in-scope ADRs actually name** — take the union of\n each ADR's `References Consulted` and `Post-Cutoff APIs Used` fields (already\n captured by the `## Engine Compatibility` scan above) and read those files.\n Reading the whole `modules/` directory loads engine subsystems the project may\n not use at all. If no ADR names any module, read none and note it: Phase 5\n cannot cross-check engine claims that were never made.\n\n### Project Standards\n- `project.yaml` — `naming.*` and `performance.*`; plus `.claude/docs/technical-preferences.md` for those keys when absent and for forbidden patterns / allowed libraries\n\nReport a count: \"Loaded [N] GDDs, [M] ADRs, engine: [name + version].\"\n\n**Also read `docs/consistency-failures.md`** if it exists. Extract entries with\nDomain matching the systems under review (Architecture, Engine, or any GDD domain\nbeing covered). Surface recurring patterns as a \"Known conflict-prone areas\" note\nat the top of the Phase 4 conflict detection output.\n\n---\n","isInternal":false,"tokens":2549,"sizeBytes":10130},{"name":"2-extract-requirements.md","path":".claude/skills/architecture-review/references/2-extract-requirements.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/architecture-review/references/2-extract-requirements.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# /architecture-review — Phase 2: Extract Technical Requirements\n\n> Part of `/architecture-review`. `SKILL.md` names when to read this file; the settings it\n> resolved and the rules under its later headings still apply here.\n\n## Phase 2: Extract Technical Requirements from Every GDD\n\n### Pre-load the TR Registry\n\nBefore extracting any requirements, read `docs/architecture/tr-registry.yaml`\nif it exists. Index existing entries by `id` and by normalized `requirement`\ntext (lowercase, trimmed). This prevents ID renumbering across review runs.\n\nThen read the Technical Requirements Baseline in `docs/architecture/architecture.md`\nif it exists. `/create-architecture` numbers each requirement the registry did not\nhold as `(provisional)`, from the registry's next free ID, and ADRs written from\nthe baseline may already cite those IDs.\n\nFor each requirement you extract, the matching rule is:\n1. **Exact/near match** to an existing registry entry for the same system →\n reuse that entry's TR-ID unchanged. Update the `requirement` text in the\n registry only if the GDD wording changed (same intent, clearer phrasing) —\n add a `revised: [date]` field.\n2. **Match to a provisional baseline row** (same system, same intent) → keep that\n ID when the registry holds no entry with it, active or retired: registering it\n is what makes it permanent. When the ID is taken, assign the next available one\n and list the rename (`TR-[system]-004 (provisional) → TR-[system]-006`) in the\n report, so the ADRs and stories that cite it can be updated.\n3. **No match** → assign a new ID: next available `TR-[system]-NNN` for that\n system, starting from the highest existing sequence + 1, skipping any ID a\n provisional baseline row holds.\n4. **Ambiguous** (partial match, intent unclear) → ask the user:\n > \"Does '[new requirement text]' refer to the same requirement as\n > `TR-[system]-NNN: [existing text]'`, or is it a new requirement?\"\n User answers: \"Same requirement\" (reuse ID) or \"New requirement\" (new ID).\n\nFor any requirement with `status: deprecated` in the registry — skip it.\nIt was removed from the GDD intentionally.\n\nFor each GDD, read it and extract all **technical requirements** — things the\narchitecture must provide for the system to work. A technical requirement is any\nstatement that implies a specific architectural decision.\n\nCategories to extract:\n\n| Category | Example |\n|----------|---------|\n| **Data structures** | \"Each entity has health, max health, status effects\" → needs a component/data schema |\n| **Performance constraints** | \"Collision detection must run at 60fps with 200 entities\" → physics budget ADR |\n| **Engine capability** | \"Inverse kinematics for character animation\" → IK system ADR |\n| **Cross-system communication** | \"Damage system notifies UI and audio simultaneously\" → event/signal architecture ADR |\n| **State persistence** | \"Player progress persists between sessions\" → save system ADR |\n| **Threading/timing** | \"AI decisions happen off the main thread\" → concurrency ADR |\n| **Platform requirements** | \"Supports keyboard, gamepad, touch\" → input system ADR |\n\nFor each GDD, produce a structured list:\n\n```\nGDD: [filename]\nSystem: [system name]\nTechnical Requirements:\n TR-[GDD]-001: [requirement text] → Domain: [Physics/Rendering/etc]\n TR-[GDD]-002: [requirement text] → Domain: [...]\n```\n\nThis becomes the **requirements baseline** — the complete set of what the\narchitecture must cover.\n\n---\n","isInternal":false,"tokens":818,"sizeBytes":3505},{"name":"3-traceability.md","path":".claude/skills/architecture-review/references/3-traceability.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/architecture-review/references/3-traceability.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# /architecture-review — Phases 3 and 3b: Traceability Matrix and Story Linkage\n\n> Part of `/architecture-review`. `SKILL.md` names when to read this file; the settings it\n> resolved and the rules under its later headings still apply here.\n\n## Phase 3: Build the Traceability Matrix\n\n**In this file:**\n\n- Step 3b-1 — Load stories\n- Step 3b-2 — Load test files\n- Step 3b-3 — Build the extended RTM\n\nFor each technical requirement extracted in Phase 2, search the ADRs:\n\n1. Use the ADRs **already loaded in Phase 1b** — do not re-read them. Extract each\n ADR's \"GDD Requirements Addressed\" section from what is already in context.\n (If Phase 1b ran in a mode that did not load every ADR, `Grep pattern=\"## GDD\n Requirements Addressed\" glob=\"docs/architecture/adr-*.md\" output_mode=\"content\"\n -A 15` fills the gap without a full re-read.)\n2. Check if it explicitly references the requirement or its GDD\n3. Check if the ADR's decision text implicitly covers the requirement\n4. Mark coverage status:\n\n| Status | Meaning |\n|--------|---------|\n| ✅ **Covered** | An **Accepted** ADR explicitly addresses this requirement |\n| 🟡 **Covered (Proposed)** | An ADR addresses it, but that ADR is still `Proposed` |\n| ⚠️ **Partial** | An ADR partially covers this, or coverage is ambiguous |\n| ❌ **Gap** | No ADR addresses this requirement |\n| ❓ **Not assessed** | The ADR is unreadable, or has no `## Status` section |\n\n> **Read each ADR's `## Status` before marking coverage — an unaccepted decision\n> is not coverage.** If `✅` meant only that *an ADR addresses this*, with no\n> status qualification, a requirement covered entirely by `Proposed` ADRs would\n> count as covered and this review could return **PASS: All requirements\n> covered** over an architecture nobody had accepted. Four skills downstream\n> (`create-control-manifest`, `create-epics`, `create-stories`, `gate-check`)\n> require `Accepted`, so a PASS on that basis sends work forward that every one\n> of them will refuse.\n>\n> `🟡` is **not** a pass state: it caps the verdict at **CONCERNS**, and names the\n> route out — `/architecture-decision accept ADR-NNNN`. That route is the only\n> thing that moves an ADR to `Accepted`; without it, grading `Proposed` as\n> covered would be the only option, which is why it must never be graded so.\n\nBuild the full matrix:\n\n```\n## Traceability Matrix\n\n| Requirement ID | GDD | System | Requirement | ADR Coverage | Status |\n|---------------|-----|--------|-------------|--------------|--------|\n| TR-combat-001 | combat.md | Combat | Hitbox detection < 1 frame | ADR-0003 | ✅ |\n| TR-combat-002 | combat.md | Combat | Combo window timing | — | ❌ GAP |\n| TR-inventory-001 | inventory.md | Inventory | Persistent item storage | ADR-0005 | ✅ |\n```\n\nCount the totals: X covered, Y partial, Z gaps.\n\n---\n\n## Phase 3b: Story and Test Linkage (RTM mode only)\n\n*Skip this phase unless the argument is `rtm` or `full` with stories present.*\n\nThis phase extends the Phase 3 matrix to include the story that implements\neach requirement and the test that verifies it — producing the full\nRequirements Traceability Matrix (RTM).\n\n### Step 3b-1 — Load stories\n\nGlob `production/epics/**/*.md` (excluding EPIC.md index files) to establish the\ndenominator. Then collect the fields with **targeted section greps, not a full\nread of each story** — the same two-grep form `/test-evidence-review` uses for\nthis identical extraction:\n\n```\nGrep pattern=\"## Test Evidence\" glob=\"production/epics/**/story-*.md\" output_mode=\"content\" -A 8\nGrep pattern=\"TR-\" glob=\"production/epics/**/story-*.md\" output_mode=\"content\"\n```\n\n- **TR-ID** — from the second grep.\n- **Test file path** — under `## Test Evidence`, captured by the first grep's `-A 8`.\n- **Status** — from the story header; add `Grep pattern=\"^> \\*\\*Status\\*\\*\"` if not already captured.\n- **Story path and title** — from the file name and path; no read at all.\n\nFull-read a story only when its Test Evidence section is missing or ambiguous.\n\n### Step 3b-2 — Load test files\n\nGlob the engine's test root (`.claude/docs/directory-structure.md`): Godot\n`tests/unit/**/*_test.*` and `tests/integration/**/*_test.*`; Unity\n`Assets/Tests/**/*Tests.cs`; Unreal `Source/*/Private/Tests/**/*.cpp`. With no\nengine configured, say the test index could not be built rather than reading an\nempty glob as \"no tests\". Build an index: system → [test file paths].\n\nFor each test file path from Step 3b-1, confirm via Glob whether the file\nactually exists. Note MISSING if the stated path does not exist.\n\n### Step 3b-3 — Build the extended RTM\n\nFor each TR-ID in the Phase 3 matrix, add:\n- **Story**: the story file path(s) that reference this TR-ID (may be multiple)\n- **Test File**: the test file path stated in the story's Test Evidence section\n- **Test Status**: COVERED (test file exists) / MISSING (path stated but not\n found) / NONE (no test path stated, story type may be Visual/Feel/UI) /\n NO STORY (requirement has no story yet — pre-production gap)\n\nExtended matrix format:\n\n```\n## Requirements Traceability Matrix (RTM)\n\n| TR-ID | GDD | Requirement | ADR | Story | Test File | Test Status |\n|-------|-----|-------------|-----|-------|-----------|-------------|\n| TR-combat-001 | combat.md | Hitbox < 1 frame | ADR-0003 | story-001-hitbox.md | tests/unit/combat/hitbox_test.gd | COVERED |\n| TR-combat-002 | combat.md | Combo window | — | story-002-combo.md | — | NONE (Visual/Feel) |\n| TR-inventory-001 | inventory.md | Persistent storage | ADR-0005 | — | — | NO STORY |\n```\n\nRTM coverage summary:\n- COVERED: [N] — requirements with ADR + story + passing test\n- MISSING test: [N] — story exists but test file not found\n- NO STORY: [N] — requirements with ADR but no story yet\n- NO ADR: [N] — requirements without architectural coverage (from Phase 3 gaps)\n- Full chain complete (COVERED): [N/total] ([%])\n\n---\n","isInternal":false,"tokens":1572,"sizeBytes":5918},{"name":"4-conflicts.md","path":".claude/skills/architecture-review/references/4-conflicts.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/architecture-review/references/4-conflicts.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# /architecture-review — Phase 4: Cross-ADR Conflict Detection\n\n> Part of `/architecture-review`. `SKILL.md` names when to read this file; the settings it\n> resolved and the rules under its later headings still apply here.\n\n## Phase 4: Cross-ADR Conflict Detection\n\nCompare every ADR against every other ADR to detect contradictions. A conflict\nexists when:\n\n- **Data ownership conflict**: Two ADRs claim exclusive ownership of the same data\n- **Integration contract conflict**: ADR-A assumes System X has interface Y, but\n ADR-B defines System X with a different interface\n- **Performance budget conflict**: ADR-A allocates N ms to physics, ADR-B allocates\n N ms to AI, together they exceed the total frame budget\n- **Dependency cycle**: ADR-A says System X initialises before Y; ADR-B says Y\n initialises before X\n- **Architecture pattern conflict**: ADR-A uses event-driven communication for a\n subsystem; ADR-B uses direct function calls to the same subsystem\n- **State management conflict**: Two ADRs define authority over the same game state\n (e.g. both Combat ADR and Character ADR claim to own the health value)\n\nFor each conflict found:\n\n```\n## Conflict: [ADR-NNNN] vs [ADR-MMMM]\nType: [Data ownership / Integration / Performance / Dependency / Pattern / State]\nADR-NNNN claims: [...]\nADR-MMMM claims: [...]\nImpact: [What breaks if both are implemented as written]\nResolution options:\n 1. [Option A]\n 2. [Option B]\n```\n\n### ADR Dependency Ordering\n\nAfter conflict detection, analyse the dependency graph across all ADRs.\n\n**Build the graph deterministically — do not trace it by hand:**\n\n```\nBash: bash .claude/scripts/adr-dep-graph.sh\n```\n\nIt collects every `Depends On` edge, finds the cycles and the order, and emits\n`ADRS:` / `EDGES:` / `NO_DEPS_SECTION:` / `UNFILLED_DEPS:` / `CYCLE:` /\n`BLOCKED_BY_CYCLE:` / `ORDER:`. A model tracing A→B→C→A across\na dozen ADRs eventually misses an edge; the algorithm cannot. It reports\nobservations, not a verdict — you apply the meaning below.\n\n**`NO_DEPS_SECTION` and `UNFILLED_DEPS` are load-bearing**: they make \"no cycles\nbecause the graph is clean\" distinguishable from \"no cycles because half the ADRs\ndeclare no dependencies, or left the template's placeholder in the row\". Report\nthe second case as a structural gap, never as a clean graph, and name each\n`UNFILLED_DEPS` ADR as unfilled: what it depends on is unknown, not none.\n\nThen interpret:\n\n1. **Topological sort**: the `ORDER:` row, as emitted — ADRs with no\n dependencies come first (Foundation), ADRs that depend on those come next, etc.\n Do not re-sort it by hand. An ADR in `NO_DEPS_SECTION` or `UNFILLED_DEPS` sits\n in it as if it depended on nothing: mark it so.\n2. **Flag unresolved dependencies**: cross the `EDGES:` list against the `## Status`\n values already scanned in Phase 1b. If ADR-A depends on an ADR that is still\n `Proposed` or does not exist, flag it:\n ```\n ⚠️ ADR-0005 depends on ADR-0002 — but ADR-0002 is still Proposed.\n ADR-0005 cannot be safely implemented until ADR-0002 is Accepted.\n ```\n3. **Cycle detection**: every `CYCLE:` line the script emitted is a\n `DEPENDENCY CYCLE` — report each one, with the edges its line shows (one of\n them is the edge to cut). A `BLOCKED_BY_CYCLE:` ADR is on no cycle: it waits\n for one to break, so list it as blocked, never as part of the cycle, and never\n suggest cutting its own edges. Do not re-derive them by hand:\n ```\n 🔴 DEPENDENCY CYCLE: ADR-0003 → ADR-0006 → ADR-0003\n This cycle must be broken before either can be implemented.\n ```\n4. **Output recommended implementation order**:\n ```\n ### Recommended ADR Implementation Order (topologically sorted)\n Foundation (no dependencies):\n 1. ADR-0001: [title]\n 2. ADR-0003: [title]\n Depends on Foundation:\n 3. ADR-0002: [title] (requires ADR-0001)\n 4. ADR-0005: [title] (requires ADR-0003)\n Feature layer:\n 5. ADR-0004: [title] (requires ADR-0002, ADR-0005)\n ```\n\n---\n","isInternal":false,"tokens":1083,"sizeBytes":4011},{"name":"5-engine.md","path":".claude/skills/architecture-review/references/5-engine.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/architecture-review/references/5-engine.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# /architecture-review — Phases 5 and 5b: Engine Cross-Check and Design Revision Flags\n\n> Part of `/architecture-review`. `SKILL.md` names when to read this file; the settings it\n> resolved and the rules under its later headings still apply here.\n\n## Phase 5: Engine Compatibility Cross-Check\n\n**In this file:**\n\n- Version Consistency\n- Post-Cutoff API Consistency\n- Deprecated API Check\n- Missing Engine Compatibility Sections\n- Engine Specialist Consultation\n\nAcross all ADRs, check for engine consistency:\n\n### Version Consistency\n- Do all ADRs that mention an engine version agree on the same version?\n- If any ADR was written for an older engine version, flag it as potentially stale\n\n### Post-Cutoff API Consistency\n- Collect all \"Post-Cutoff APIs Used\" fields from all ADRs\n- For each, verify against the relevant module reference doc\n- Check that no two ADRs make contradictory assumptions about the same post-cutoff API\n\n### Deprecated API Check\n- Grep all ADRs for API names listed in `deprecated-apis.md`\n- Flag any ADR referencing a deprecated API\n\n### Missing Engine Compatibility Sections\n- List all ADRs that are missing the Engine Compatibility section entirely\n- These are blind spots — their engine assumptions are unknown\n\nOutput format:\n```\n### Engine Audit Results\nEngine: [name + version]\nADRs with Engine Compatibility section: X / Y total\n\nDeprecated API References:\n - ADR-0002: uses [deprecated API] — deprecated since [version]\n\nStale Version References:\n - ADR-0001: written for [older version] — current project version is [version]\n\nPost-Cutoff API Conflicts:\n - ADR-0004 and ADR-0007 both use [API] with incompatible assumptions\n```\n\n---\n\n### Engine Specialist Consultation\n\nAfter completing the engine audit above, spawn the **primary engine specialist** via `Agent` for a domain-expert second opinion:\n- Resolve the primary specialist: `-specialist` derived from `engine.name` in `project.yaml` (Godot→`godot-specialist`, Unity→`unity-specialist`, Unreal→`unreal-specialist`); if `engine.name` is absent or empty, read the Primary line of the `## Engine Specialists` section in `.claude/docs/technical-preferences.md`\n- If no engine is configured (neither source yields an engine), skip this consultation **Record ``Engine validation: NOT ASSESSED — no engine configured (`engine.name` unset in `project.yaml`)`` in this run's output.** A skipped check that says nothing is indistinguishable from a check that passed; the reader cannot tell engine guidance was never sought.\n- Spawn `subagent_type: [primary specialist]` with: all ADRs that contain engine-specific decisions or `Post-Cutoff APIs Used` fields, the engine reference docs, and the Phase 5 audit findings. Ask them to:\n 1. Confirm or challenge each audit finding — specialists may know of engine nuances not captured in the reference docs\n 2. Identify engine-specific anti-patterns in the ADRs that the audit may have missed (e.g., using the wrong Godot node type, Unity component coupling, Unreal subsystem misuse)\n 3. Flag ADRs that make assumptions about engine behaviour that differ from the actual pinned version\n\nIncorporate additional findings under `### Engine Specialist Findings` in the Phase 5 output. These feed into the final verdict — specialist-identified issues carry the same weight as audit-identified issues.\n\n---\n\n## Phase 5b: Design Revision Flags (Architecture → GDD Feedback)\n\nFor each **HIGH RISK engine finding** from Phase 5, check whether any GDD makes an\nassumption that the verified engine reality contradicts.\n\nSpecific cases to check:\n\n1. **Post-cutoff API behaviour differs from training-data assumptions**: If an ADR\n records a verified API behaviour that differs from the default LLM assumption,\n check all GDDs that reference the related system. Look for design rules written\n around the old (assumed) behaviour.\n\n2. **Known engine limitations in ADRs**: If an ADR records a known engine limitation\n (e.g. \"Jolt ignores HingeJoint3D damp\", \"D3D12 is now the default backend\"), check\n GDDs that design mechanics around the affected feature.\n\n3. **Deprecated API conflicts**: If Phase 5 flagged a deprecated API used in an ADR,\n check whether any GDD contains mechanics that assume the deprecated API's behaviour.\n\nFor each conflict found, record it in the GDD Revision Flags table:\n\n```\n### GDD Revision Flags (Architecture → Design Feedback)\nThese GDD assumptions conflict with verified engine behaviour or accepted ADRs.\nThe GDD should be revised before its system enters implementation.\n\n| GDD | Assumption | Reality (from ADR/engine-reference) | Action |\n|-----|-----------|--------------------------------------|--------|\n| combat.md | \"Use HingeJoint3D damp for weapon recoil\" | Jolt ignores damp — ADR-0003 | Revise GDD |\n```\n\nIf no revision flags are found, write: \"No GDD revision flags — all GDD assumptions\nare consistent with verified engine behaviour.\"\n\nBefore asking, display the proposed change inline — show the current systems-index row for each flagged GDD and the proposed updated row side by side so the user can see exactly what will change.\n\nThen use `AskUserQuestion`:\n- \"I found [N] GDD revision flag(s). May I update the systems index?\"\n - [A] Yes — apply all [N] updates to the systems index now\n - [B] Show me the full diff first, then ask again\n - [C] No — leave the systems index unchanged for now\n\nIf [A]: apply the updates. Status field must be exactly `Needs Revision` — no parentheticals\n(other skills match that exact string and parentheticals break the match).\nIf [B]: display the complete proposed systems-index section, then re-ask with `AskUserQuestion`.\n\n---\n","isInternal":false,"tokens":1297,"sizeBytes":5693},{"name":"6-document-coverage.md","path":".claude/skills/architecture-review/references/6-document-coverage.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/architecture-review/references/6-document-coverage.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# /architecture-review — Phase 6: Architecture Document Coverage\n\n> Part of `/architecture-review`. `SKILL.md` names when to read this file; the settings it\n> resolved and the rules under its later headings still apply here.\n\n## Phase 6: Architecture Document Coverage\n\n**If `docs/architecture/architecture.md` does not exist, say so in the report** —\n`Architecture document coverage: NOT ASSESSED — no docs/architecture/architecture.md`\n— and carry it into the Phase 7 verdict per the trigger list below. Silently\nproducing no Phase 6 findings reads as an architecture document that was checked\nand found clean, which is the opposite of what happened.\n\nIf it exists, validate it against GDDs:\n\n- Does every system from `systems-index.md` appear in the architecture layers?\n- Does the data flow section cover all cross-system communication defined in GDDs?\n- Do the API boundaries support all integration requirements from GDDs?\n- Are there systems in the architecture doc that have no corresponding GDD\n (orphaned architecture)?\n\n---\n","isInternal":false,"tokens":226,"sizeBytes":1044},{"name":"7-report.md","path":".claude/skills/architecture-review/references/7-report.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/architecture-review/references/7-report.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# /architecture-review — Phase 7: Output the Review Report\n\n> Part of `/architecture-review`. `SKILL.md` names when to read this file; the settings it\n> resolved and the rules under its later headings still apply here.\n\n## Phase 7: Output the Review Report\n\n```\n## Architecture Review Report\nDate: [date]\nMode: [full / coverage / consistency / engine / single-gdd path/to/gdd.md]\nWorkflow: [the resolved workflow tier]\nEngine: [name + version, or \"none configured\"]\nGDDs Reviewed: [N]\nADRs Reviewed: [M]\n\n[the receipt — one Reviewed-Content-Hash line per review input, taken in\n Phase 8 when the report is written, never in this draft. Phase 1a's freshness\n check reads them, with the Mode and Workflow lines, on the next run]\n\n---\n\n### Traceability Summary\nTotal requirements: [N]\n✅ Covered: [X]\n⚠️ Partial: [Y]\n❌ Gaps: [Z]\n\n### Coverage Gaps (no ADR exists)\nFor each gap:\n ❌ TR-[id]: [GDD] → [system] → [requirement]\n Suggested ADR: \"/architecture-decision [suggested title]\"\n Domain: [Physics/Rendering/etc]\n Engine Risk: [LOW/MEDIUM/HIGH]\n\n### Cross-ADR Conflicts\n[List all conflicts from Phase 4]\n\n### ADR Dependency Order\n[Topologically sorted implementation order from Phase 4 — dependency ordering section]\n[Unresolved dependencies and cycles if any]\n\n### GDD Revision Flags\n[GDD assumptions that conflict with verified engine behaviour — from Phase 5b]\n[Or: \"None — all GDD assumptions consistent with verified engine behaviour\"]\n\n### Engine Compatibility Issues\n[List all engine issues from Phase 5]\n\n### Architecture Document Coverage\n[List missing systems and orphaned architecture from Phase 6]\n\n---\n\n### Verdict: [PASS / NOT ASSESSED / CONCERNS / FAIL]\n\nPASS: All requirements covered by **Accepted** ADRs, no conflicts, engine consistent\nNOT ASSESSED: The review could not be performed over its stated scope — name why\nCONCERNS: Some gaps, partial coverage, or coverage resting on `Proposed` ADRs,\n but no blocking conflicts\nFAIL: Critical gaps (Foundation/Core layer requirements uncovered),\n or blocking cross-ADR conflicts detected\n\n**`NOT ASSESSED` ranks above PASS and below CONCERNS and FAIL.** Emit it when:\n\n- **No ADRs exist, or none could be read.** Zero requirements traced is not full\n coverage — it is an untraced architecture, and a matrix of `❌ Gap` rows at\n least says so while an empty matrix says nothing.\n- **The requirement source is missing** — no `tr-registry.yaml` and no GDD\n requirements to trace *from*. A review with no left-hand column cannot report\n coverage; it can only report that it had nothing to compare.\n- **An ADR is unreadable or has no `## Status`**, so its rows are `❓` and their\n coverage is unknown rather than absent.\n- **Phase 6 could not run** — no `docs/architecture/architecture.md`. It must\n appear as a named `NOT ASSESSED` **line item** in the report rather than as\n absent findings. ADR traceability can still be complete, so a CONCERNS or FAIL\n finding elsewhere still stands; but in `full` mode, whose scope includes\n Phase 6, the verdict cannot be PASS — a review that could not look at part of\n its scope has not shown that part is sound, so it is NOT ASSESSED.\n- **No engine is configured** (`full` and `engine` modes) — Phase 5 has no pinned\n engine reference to audit the ADRs against, and the specialist consultation was\n skipped. Record the `Engine validation: NOT ASSESSED` line item; like Phase 6\n above, it keeps the verdict from PASS.\n\nDo not resolve any of these to PASS on the grounds that no gap was *found*. No\ngap was looked for.\n\n### Blocking Issues (must resolve before PASS)\n[List items that must be resolved — FAIL verdict only]\n\n### Required ADRs\n[Prioritised list of ADRs to create, most foundational first]\n```\n\n---\n","isInternal":false,"tokens":941,"sizeBytes":3785},{"name":"8-write.md","path":".claude/skills/architecture-review/references/8-write.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/architecture-review/references/8-write.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# /architecture-review — Phase 8: Write and Update Traceability Index\n\n> Part of `/architecture-review`. `SKILL.md` names when to read this file; the settings it\n> resolved and the rules under its later headings still apply here.\n\n## Phase 8: Write and Update Traceability Index\n\n**In this file:**\n\n- The receipt is taken last\n- RTM Output (rtm mode only)\n- TR Registry Update\n- Reflexion Log Update\n- Session State Update\n\nUse `AskUserQuestion` for the write approval:\n- \"Review complete. What would you like to write?\"\n - [A] Write all three files — review report (`docs/architecture/architecture-review-[date].md`), traceability index (`docs/architecture/requirements-traceability.md`), TR registry (`docs/architecture/tr-registry.yaml`)\n - [B] Write review report only — `docs/architecture/architecture-review-[date].md`\n - [C] Don't write anything yet — I need to review the findings first\n\n**A `single-gdd` run saw one system**, so in that mode [A] writes the review\nreport and only that system's share of the other two files. Name it so in the\noption: \"…update [system]'s rows in the traceability index and its TR registry\nentries\". In `requirements-traceability.md`, replace that system's matrix rows\nand recompute the Coverage Summary, keeping every other system's rows as they\nare. When the index does not exist yet, write the report and the registry only,\nand say a full review creates the index. In the TR registry, append, update and\ndeprecate only that system's entries: another system's GDD was not read, so its\nentries are never proposed for deprecation.\n\nWhen Phase 4 found a 🔴 conflict and `docs/consistency-failures.md` exists, name\nthat file in option [A] as well — \"…and append [N] conflict entr(y/ies) to\n`docs/consistency-failures.md`\". Only [A] appends there (see Reflexion Log\nUpdate); [B] writes the report and nothing else.\n\n### The receipt is taken last\n\nWrite the review report after the TR registry update and the\n`consistency-failures.md` entries, and take its receipt lines at that moment —\nnever from the Phase 7 draft. Both files are review inputs: a receipt taken\nbefore this run edited them records the old content, and the next run reads\nthis run's own edit as `CHANGED`.\n\n```\nBash: bash .claude/scripts/review-receipts.sh hash docs/architecture/adr-*.md design/gdd/*.md docs/architecture/tr-registry.yaml docs/architecture/architecture.md docs/engine-reference/[engine]/*.md docs/engine-reference/[engine]/modules/*.md project.yaml .claude/docs/technical-preferences.md docs/consistency-failures.md .claude/skills/architecture-review/SKILL.md .claude/skills/architecture-review/references/*.md\n```\n\nIt is the same list as Phase 1a's check, with `[engine]` filled in the same way.\nAn optional input that does not exist prints `not stamped, no such file` and is\nleft out; that is expected. Paste the stamp lines into the report under its\nheader, where the Phase 7 template shows them.\n\n### RTM Output (rtm mode only)\n\nFor `rtm` mode, use `AskUserQuestion`:\n- \"May I write the full Requirements Traceability Matrix?\"\n - [A] Yes — write to `docs/architecture/requirements-traceability.md`\n - [B] Not yet — show me the full RTM data first, then ask again\n\nRTM file format:\n\n```markdown\n# Requirements Traceability Matrix (RTM)\n\n> Last Updated: [date]\n> Mode: /architecture-review rtm\n> Coverage: [N]% full chain complete (GDD → ADR → Story → Test)\n\n## How to read this matrix\n\n| Column | Meaning |\n|--------|---------|\n| TR-ID | Stable requirement ID from tr-registry.yaml |\n| GDD | Source design document |\n| ADR | Architectural decision governing implementation |\n| Story | Story file that implements this requirement |\n| Test File | Automated test file path |\n| Test Status | COVERED / MISSING / NONE / NO STORY |\n\n## Full Traceability Matrix\n\n| TR-ID | GDD | Requirement | ADR | Story | Test File | Status |\n|-------|-----|-------------|-----|-------|-----------|--------|\n[Full matrix rows from Phase 3b]\n\n## Coverage Summary\n\n| Status | Count | % |\n|--------|-------|---|\n| COVERED — full chain complete | [N] | [%] |\n| MISSING test — story exists, no test | [N] | [%] |\n| NO STORY — ADR exists, not yet implemented | [N] | [%] |\n| NO ADR — architectural gap | [N] | [%] |\n| **Total requirements** | **[N]** | **100%** |\n\n## Uncovered Requirements (Priority Fix List)\n\nRequirements where the full chain is broken, prioritised by layer:\n\n### Foundation layer gaps\n[list with suggested action per gap]\n\n### Core layer gaps\n[list]\n\n### Feature / Presentation layer gaps\n[list — lower priority]\n\n## History\n\n| Date | Full Chain % | Notes |\n|------|-------------|-------|\n| [date] | [%] | Initial RTM |\n```\n\n### TR Registry Update\n\nAlso ask: \"May I update `docs/architecture/tr-registry.yaml` with new requirement\nIDs from this review?\"\n\nIf yes, read the current `docs/architecture/tr-registry.yaml` again first:\nthe review read it at the start, and another skill or session may have changed\nit since. Build the update from that fresh read, never from the earlier copy,\nand keep every entry already in it. Then:\n- **Append** any new TR-IDs that weren't in the registry before this review\n- **Update** `requirement` text and `revised` date for any entries whose GDD\n wording changed (ID stays the same)\n- **Mark** `status: deprecated` for any registry entries whose GDD requirement\n no longer exists (confirm with user before marking deprecated; in `single-gdd`\n mode, only the reviewed system's entries)\n- **Mark** `status: \"superseded-by: TR-[system]-NNN\"` for an entry whose\n requirement was split or replaced, naming the new TR-ID(s). Keep the quotes:\n unquoted, the second colon makes the file invalid YAML\n- **Never** renumber or delete existing entries\n- Update the `last_updated` and `version` fields at the top\n\nAfter writing, run `bash .claude/scripts/registry.sh validate` and fix every row\nabout an entry this write added or changed (a DUPLICATE, STATUS or LAYOUT row,\nor a PATH_MISSING row for a path it named) before you go on; name rows about\nother entries to the user rather than fixing them unasked. If the script is\nmissing or prints nothing, say the registry check did not run, then re-read the\nentries you wrote against the rules in the file's header.\n\nThis ensures all future story files can reference stable TR-IDs that persist\nacross every subsequent architecture review.\n\n### Reflexion Log Update\n\nWhen the user chose Phase 8's [A] — the option that named this file — append\nany 🔴 CONFLICT entries found in Phase 4 to `docs/consistency-failures.md` (if\nthe file exists), before writing the review report (its receipt is taken last):\n\n```markdown\n### [YYYY-MM-DD] — /architecture-review — 🔴 CONFLICT\n**Domain**: Architecture / [specific domain e.g. State Ownership, Performance]\n**Documents involved**: [ADR-NNNN] vs [ADR-MMMM]\n**What happened**: [specific conflict — what each ADR claims]\n**Resolution**: [how it was or should be resolved]\n**Pattern**: [generalised lesson for future ADR authors in this domain]\n```\n\nOnly append CONFLICT entries — do not log GAP entries (missing ADRs are expected\nbefore the architecture is complete). Do not create the file if missing — only\nappend when it already exists.\n\n### Session State Update\n\nAfter writing all approved files, silently append to\n`production/session-state/active.md`:\n\n ## Session Extract — /architecture-review [date]\n - Verdict: [PASS / NOT ASSESSED / CONCERNS / FAIL]\n - Requirements: [N] total — [X] covered, [Y] partial, [Z] gaps\n - New TR-IDs registered: [N, or \"None\"]\n - GDD revision flags: [comma-separated GDD names, or \"None\"]\n - Top ADR gaps: [top 3 gap titles from the report, or \"None\"]\n - Report: docs/architecture/architecture-review-[date].md\n\nIf `active.md` does not exist, create it with this block as the initial content.\nConfirm in conversation: \"Session state updated.\"\n\nThe traceability index — written to `docs/architecture/requirements-traceability.md`,\nthe path `/propagate-design-change` and the Pre-Production gate read; `rtm` mode\nlater extends the same file with story and test columns — uses this format:\n\n```markdown\n# Architecture Traceability Index\nLast Updated: [date]\nEngine: [name + version]\n\n## Coverage Summary\n- Total requirements: [N]\n- Covered: [X] ([%])\n- Partial: [Y]\n- Gaps: [Z]\n\n## Full Matrix\n[Complete traceability matrix from Phase 3]\n\n## Known Gaps\n[All ❌ items with suggested ADRs]\n\n## Superseded Requirements\n[Requirements whose GDD was changed after the ADR was written]\n```\n\n---\n","isInternal":false,"tokens":2114,"sizeBytes":8548},{"name":"9-handoff.md","path":".claude/skills/architecture-review/references/9-handoff.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/architecture-review/references/9-handoff.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# /architecture-review — Phase 9: Handoff\n\n> Part of `/architecture-review`. `SKILL.md` names when to read this file; the settings it\n> resolved and the rules under its later headings still apply here.\n\n## Phase 9: Handoff\n\nAfter completing the review and writing approved files, present:\n\n1. **Immediate actions**: List the top 3 ADRs to create (highest-impact gaps first,\n Foundation layer before Feature layer)\n2. **Pre-gate checklist**: Check whether these exist via Glob and mark each ✅ or ❌:\n - the engine's test root — `tests/unit/` and `tests/integration/` (Godot), `Assets/Tests/EditMode/` and `Assets/Tests/PlayMode/` (Unity), `Source//Private/Tests/` (Unreal) — if ❌: run `/test-setup`\n - `.github/workflows/tests.yml` — if ❌: run `/test-setup`\n - `design/accessibility-requirements.md` — if ❌: run `/ux-design`\n - `design/ux/interaction-patterns.md` — if ❌: run `/ux-design`\n Present ❌ items as required steps before gate-check. Do not offer `/gate-check`\n as an option if any item is ❌ — offer the missing skill to run instead.\n3. **Rerun trigger**: \"Re-run `/architecture-review` after each new ADR is written\n to verify coverage improves\"\n\nThen close with `AskUserQuestion` tailored to the pre-gate checklist state:\n- If ADR gaps remain or any pre-gate item is ❌:\n - \"Architecture review complete. What would you like to do next?\"\n - [A] Write a missing ADR — open a fresh session and run `/architecture-decision [system]`\n - [B] Run `/test-setup` — required before gate-check (only show if test infrastructure is ❌)\n - [C] Run `/ux-design` — required before gate-check (only show if UX/accessibility files are ❌)\n - [D] Stop here for this session\n- If all pre-gate checklist items are ✅ and no blocking ADR gaps remain:\n - \"Architecture review complete. All pre-gate items confirmed. What would you like to do next?\"\n - [A] Run `/gate-check pre-production`\n - [B] Write a missing ADR — open a fresh session and run `/architecture-decision [system]`\n - [C] Stop here for this session\n\n---\n","isInternal":false,"tokens":543,"sizeBytes":2097},{"name":"SKILL.md","path":".claude/skills/architecture-review/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/architecture-review/SKILL.md","title":"architecture-review","category":"anthropic-skill","format":"markdown","content":"---\nname: architecture-review\ndescription: \"Traceability matrix mapping GDD requirements to ADRs. Finds gaps, cross-ADR conflicts, engine compatibility. PASS/CONCERNS/NOT ASSESSED/FAIL.\"\nargument-hint: \"[focus: full | coverage | consistency | engine | rtm | single-gdd path/to/gdd.md]\"\nuser-invocable: true\nallowed-tools: Read, Glob, Grep, Write, Edit, Agent, AskUserQuestion, Bash(bash \"*/.claude/skills/architecture-review/../../hooks/yaml-helper.sh\" resolve_config *), Bash(bash .claude/scripts/review-receipts.sh check *), Bash(bash .claude/scripts/review-receipts.sh hash *), Bash(bash .claude/scripts/adr-dep-graph.sh*), Bash(bash .claude/scripts/registry.sh validate*)\nmodel: opus\n---\n\n!`bash \"${CLAUDE_SKILL_DIR}/../../hooks/yaml-helper.sh\" resolve_config --keys automation,workflow`\n\n# Architecture Review\n\nThe architecture review validates that the complete body of architectural decisions\ncovers all game design requirements, is internally consistent, and correctly targets\nthe project's pinned engine version. It is the quality gate between Technical Setup\nand Pre-Production.\n\n**Argument modes:**\n- **No argument / `full`**: Full review — all phases\n- **`coverage`**: Traceability only — which GDD requirements have no ADR\n- **`consistency`**: Cross-ADR conflict detection only\n- **`engine`**: Engine compatibility audit only\n- **`single-gdd [path]`**: Review architecture coverage for one specific GDD\n- **`rtm`**: Requirements Traceability Matrix — extends the standard matrix\n to include story file paths and test file paths; outputs\n `docs/architecture/requirements-traceability.md` with the full\n GDD requirement → ADR → Story → Test chain. Use in Production phase when\n stories and tests exist.\n\n---\n\nEvery `AskUserQuestion` call follows `.claude/docs/automation-modes.md`\n(collaborative asks always · guided major-only · autonomous logs and proceeds;\n`automation_always_ask` categories always prompt).\n\n**`workflow`** (see `.claude/docs/workflow-modes.md`):\n- `full` — full traceability matrix across all GDDs and all ADRs.\n- `standard` — reduced scope: architecture doc + critical ADRs only.\n- `minimal` — not applicable (no architecture doc required).\n\n## Phase 1: Load Everything\n\n**Read `references/1-load.md` now and follow it** — this phase's steps are in that file, not here. Read it again if the conversation was compacted or resumed during this phase.\n\n## Phase 2: Extract Technical Requirements from Every GDD\n\n**Read `references/2-extract-requirements.md` now and follow it** — this phase's steps are in that file, not here. Read it again if the conversation was compacted or resumed during this phase.\n\n## Phase 3: Build the Traceability Matrix\n\n**Read `references/3-traceability.md` now and follow it** — this phase's steps are in that file, not here. Read it again if the conversation was compacted or resumed during this phase.\n\n## Phase 4: Cross-ADR Conflict Detection\n\n**Read `references/4-conflicts.md` now and follow it** — this phase's steps are in that file, not here. Read it again if the conversation was compacted or resumed during this phase.\n\n## Phase 5: Engine Compatibility Cross-Check\n\n**Read `references/5-engine.md` now and follow it** — this phase's steps are in that file, not here. Read it again if the conversation was compacted or resumed during this phase.\n\n## Phase 6: Architecture Document Coverage\n\n**Read `references/6-document-coverage.md` now and follow it** — this phase's steps are in that file, not here. Read it again if the conversation was compacted or resumed during this phase.\n\n## Phase 7: Output the Review Report\n\n**Read `references/7-report.md` now and follow it** — this phase's steps are in that file, not here. Read it again if the conversation was compacted or resumed during this phase.\n\n## Phase 8: Write and Update Traceability Index\n\n**Read `references/8-write.md` now and follow it** — this phase's steps are in that file, not here. Read it again if the conversation was compacted or resumed during this phase.\n\n## Phase 9: Handoff\n\n**Read `references/9-handoff.md` now and follow it** — this phase's steps are in that file, not here. Read it again if the conversation was compacted or resumed during this phase.\n\n## Error Recovery Protocol\n\n**First, verify the artifact.** If the return contract named a path, check the\npath exists before treating the phase as done — **a named artifact that is not\non disk is a failed phase, however fluent the response reads.** An agent can\nburn a full phase and return a plausible preamble having written nothing, which\nis neither BLOCKED nor an error nor \"fails to complete\", so the trigger below\nnever fires. Resume it naming the unmet contract; the context is\nusually still there.\n\nIf any spawned agent returns BLOCKED, errors, or fails to complete: **surface it\nimmediately, don't proceed past a dependency it blocks, and always produce a\npartial report** (retry scope here = fewer GDDs / single-system). Full procedure:\n`.claude/docs/error-recovery-protocol.md`.\n\n---\n\n## Collaborative Protocol\n\n**Applies in `collaborative` mode (the default).** For `guided` and\n`autonomous` modes, see `.claude/docs/automation-modes.md` — the rules below\ndescribe what collaborative mode requires, not universal behavior.\n\n1. **Read silently** — do not narrate every file read\n2. **Show the matrix** — present the full traceability matrix before any write\n approval; let the user see the state\n3. **Don't guess** — if a requirement is ambiguous, ask: \"Is [X] a technical\n requirement or a design preference?\"\n4. **Draft before approval** — always show the content that will be written (the\n report, the updated ADR section, the systems-index row) inline in the conversation\n before requesting approval. Never ask to write something the user has not yet seen.\n5. **Use `AskUserQuestion` for write approvals** — plain text \"May I?\" is not\n sufficient. Use the structured tool with labeled options [A]/[B]/[C] so the\n user can choose between \"write now\", \"show full draft first\", and \"not yet\".\n Multi-file changesets must list every file and what changes, then ask once\n with grouped options — not a separate plain-text question per file.\n6. **Non-blocking** — the verdict is advisory; the user decides whether to continue\n despite CONCERNS or even FAIL findings\n","frontmatter":{"name":"architecture-review","description":"Traceability matrix mapping GDD requirements to ADRs. Finds gaps, cross-ADR conflicts, engine compatibility. PASS/CONCERNS/NOT ASSESSED/FAIL.","argument-hint":"[focus: full | coverage | consistency | engine | rtm | single-gdd path/to/gdd.md]","user-invocable":true,"allowed-tools":"Read, Glob, Grep, Write, Edit, Agent, AskUserQuestion, Bash(bash \"*/.claude/skills/architecture-review/../../hooks/yaml-helper.sh\" resolve_config *), Bash(bash .claude/scripts/review-receipts.sh check *), Bash(bash .claude/scripts/review-receipts.sh hash *), Bash(bash .claude/scripts/adr-dep-graph.sh*), Bash(bash .claude/scripts/registry.sh validate*)","model":"opus","allowedTools":["Read,","Glob,","Grep,","Write,","Edit,","Agent,","AskUserQuestion,","Bash(bash","\"*/.claude/skills/architecture-review/../../hooks/yaml-helper.sh\"","resolve_config","*),","Bash(bash",".claude/scripts/review-receipts.sh","check","*),","Bash(bash",".claude/scripts/review-receipts.sh","hash","*),","Bash(bash",".claude/scripts/adr-dep-graph.sh*),","Bash(bash",".claude/scripts/registry.sh","validate*)"]},"allowedTools":["Read,","Glob,","Grep,","Write,","Edit,","Agent,","AskUserQuestion,","Bash(bash","\"*/.claude/skills/architecture-review/../../hooks/yaml-helper.sh\"","resolve_config","*),","Bash(bash",".claude/scripts/review-receipts.sh","check","*),","Bash(bash",".claude/scripts/review-receipts.sh","hash","*),","Bash(bash",".claude/scripts/adr-dep-graph.sh*),","Bash(bash",".claude/scripts/registry.sh","validate*)"],"isInternal":false,"tokens":1505,"sizeBytes":6351},{"name":"SKILL.md","path":".claude/skills/art-bible/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/art-bible/SKILL.md","title":"art-bible","category":"anthropic-skill","format":"markdown","content":"---\nname: art-bible\ndescription: \"Author the Art Bible — visual identity gating asset production. Run before /map-systems.\"\nargument-hint: \"[--review full|lean|solo]\"\nuser-invocable: true\nallowed-tools: Read, Glob, Grep, Write, Edit, Agent, AskUserQuestion, Bash(bash \"*/.claude/skills/art-bible/../../hooks/yaml-helper.sh\" resolve_config *)\nmodel: sonnet\n---\n\n!`bash \"${CLAUDE_SKILL_DIR}/../../hooks/yaml-helper.sh\" resolve_config --keys review_mode,automation,workflow,docs.density`\n\nResolved above — use as-is; `--review` overrides `review_mode`. No block →\ndefaults in `.claude/docs/config-resolution.md`.\n\n# Art Bible\n\n\n## Phase 0: Parse Arguments and Context Check\n\n\nSee `.claude/docs/director-gates.md` for the full check pattern. Individual gate definitions live in `.claude/docs/director-gates/[gate-id].md` — the spawned agent reads its own gate file; do not read it in the parent session.\n\n\nEvery `AskUserQuestion` call follows `.claude/docs/automation-modes.md`\n(collaborative asks always · guided major-only · autonomous logs and proceeds;\n`automation_always_ask` categories always prompt).\n\n**`docs.density`** — it controls per-section *depth*, where `workflow`\ncontrols which sections exist. `modes.rigor` sets both together; set\n`docs.density` explicitly to vary depth alone: `terse` (the default, via `rigor: minimal`) = each section a bulleted list of\nconstraints + references; `balanced` = paragraphs explaining each visual choice\n(`rigor: standard`); `thorough` = full prose including style explorations, references, and\nrationale per choice. Apply it to every section you author.\n\n**`workflow`** (see `.claude/docs/workflow-modes.md`):\n- `full` — all 9 art bible sections required.\n- `standard` — required only if visual asset stories exist in the project;\n sections 1–4 are the minimum when required. `workflow_overrides.art_bible_strict:\n true` forces all 9 sections regardless of tier.\n- `minimal` — not required. Can still be run voluntarily.\n\nRead `design/gdd/game-concept.md` — or `design/game-brief.md`, the one-page brief\nthat replaces it at `rigor: minimal`. Read it by section: find the headings you need\nwith the Grep tool (pattern `^#`, content mode) and Read those ranges with offset\nand limit. If neither exists, fail with:\n> \"No game concept found. Run `/brainstorm` first — the art bible is authored after the game concept is approved.\"\n\nExtract from game-concept.md (from the brief: working title, pitch, \"Who it's for /\nwhat they feel\" line and \"Art & audio direction\" line — it has no pillars, Visual\nIdentity Anchor or platform):\n- Game title (working title)\n- Core fantasy and elevator pitch\n- Game pillars (all of them)\n- **Visual Identity Anchor** section if present (from brainstorm Phase 4 art-director output)\n- Target platform (if noted)\n\n**Retrofit mode detection**: Glob `design/art/art-bible.md`. If the file exists,\nbuild the status table **without reading the document** — you are about to author\nonly the *incomplete* sections, so loading the complete ones is loading exactly\nwhat you will not touch:\n\n```\nGrep pattern=\"^## \" path=\"design/art/art-bible.md\" output_mode=\"content\" -n\nGrep pattern=\"\\[To be designed\\]|\\[TBD\\]|\\[To be written\\]|^_?TODO\" path=\"design/art/art-bible.md\" output_mode=\"content\" -n\n```\n\n- The first grep gives the section headings and their line numbers — the gap\n between consecutive headings is that section's size.\n- The second gives placeholder markers and where they fall.\n- A section is **Complete** if it has substantive distance to the next heading and\n no placeholder marker inside it; **Placeholder** if a marker falls in its range;\n **Empty** if consecutive headings sit adjacent.\n- Where the two greps leave a section genuinely ambiguous, read *that section's*\n line range with `Read(offset, limit)` — never the whole file.\n- Build a section status table:\n\n```\nSection | Status\n--------|--------\n1. Visual Identity Statement | [Complete / Empty / Placeholder]\n2. Mood & Atmosphere | ...\n3. Shape Language | ...\n4. Color System | ...\n5. Character Design Direction | ...\n6. Environment Design Language | ...\n7. UI/HUD Visual Direction | ...\n8. Asset Standards | ...\n9. Reference Direction | ...\n```\n\n- Present this table to the user:\n > \"Found existing art bible at `design/art/art-bible.md`. [N] sections are complete, [M] need content. I'll work on the incomplete sections only — existing content will not be touched.\"\n- Only work on sections with Status: Empty or Placeholder. Do not re-author sections that are already complete.\n\nIf the file does not exist, this is a fresh authoring session. The first\napproved section creates the file from `.claude/docs/templates/art-bible.md`,\nwhose nine `## N. Name` headings are the ones retrofit mode reads — ask first:\n\"May I create `design/art/art-bible.md` from the art bible template?\" Each\napproved section then replaces its own `[To be designed]` line with `Edit`;\nkeep the headings as the template has them.\n\n**A section's approval names its write.** Every section is approved through an\n`AskUserQuestion` whose approving option is `[A] Lock this in and write it to\ndesign/art/art-bible.md` (Section 1's full option list is below). Choosing it is\nthe approval to write that section; no section is written without it, fresh or\nretrofit.\n\nExtract performance budgets and the engine for asset standard constraints: read `performance.*` and `engine.name` from `project.yaml`; for any key absent or empty (including when `project.yaml` has no `performance` or `engine` block), fall back to `.claude/docs/technical-preferences.md`.\n\n---\n\n## Phase 1: Framing\n\nPresent the session context and ask two questions before authoring anything:\n\nUse `AskUserQuestion` with two tabs:\n- Tab **\"Scope\"** — \"Which sections need to be authored today?\"\n Options: `Full bible — all 9 sections` / `Visual identity core (sections 1–4 only)` / `Asset standards only (section 8)` / `Resume — fill in missing sections`\n\n **Mark the option the resolved `workflow` tier actually requires as\n (Recommended), and say why** — the tier already decides this and the user\n should not have to know the tier table to answer:\n - `full` → **Full bible** — all 9 sections are required at this tier.\n - `standard` → **Visual identity core (sections 1–4 only)** — that is the\n documented minimum when an art bible is required at all. Say: \"Sections 1–4\n are what `standard` requires; 5–9 are available if you want them.\"\n - `minimal` → no art bible is required. Say so before asking, and offer\n sections 1–4 as the useful-if-you-want-it option rather than defaulting to 9.\n - `workflow_overrides.art_bible_strict: true` → **Full bible** regardless of tier.\n\n This is the single biggest cost lever in this skill: every authored section\n carries a specialist spawn, so authoring 9 sections where the tier requires 4\n more than doubles the run for artifacts nothing downstream will check.\n- Tab **\"References\"** — \"Do you have reference games, films, or art that define the visual direction?\"\n (Free text — let the user type specific titles. Do NOT preset options here.)\n\nIf the game-concept.md has a Visual Identity Anchor section, note it:\n> \"Found a visual identity anchor from brainstorm: '[anchor name] — [one-line rule]'. I'll use this as the foundation for the art bible.\"\n\n**Author only the sections in the chosen scope.** Phases 2–4 run only the\nsections inside it — for `Resume`, the Empty and Placeholder rows of the\nretrofit table — and skip every other section, and any phase left with none.\nPhase 6 names each section not authored this run and why.\n\n---\n\n## Phase 2: Visual Identity Foundation (Sections 1–4)\n\nThese four sections define the core visual language. **All other sections flow from them.** Author and write each to file before moving to the next.\n\n> **Spawn policy for this phase.** Section 1 is delegated on its own — it is\n> foundational and the user chooses between anchor directions before anything\n> else can build on it. Sections 2–4 are then delegated in **one** `art-director`\n> call, not three: they are the same agent receiving the same inputs (Visual\n> Identity Statement + pillars), and mood, shape and colour are interdependent —\n> an art director defines them together, not in isolation. Separate calls would\n> ask the agent to reason about colour without knowing the shape language it\n> had just written.\n>\n> **This is not reduced specialist involvement** — every section is still\n> authored by the specialist, which is the point `.claude/docs/effects-map.md`\n> makes about art-bible delegation being mandatory. It is one call instead of\n> three for the same three sections. Per-section user approval and\n> write-to-file-immediately are unchanged.\n\n### Section 1: Visual Identity Statement\n\n**Goal**: A one-line visual rule plus 2–3 supporting principles that resolve visual ambiguity.\n\nIf a visual anchor exists from game-concept.md: present it and ask:\n- \"Build directly from this anchor?\"\n- \"Revise it before expanding?\"\n- \"Start fresh with new options?\"\n\n**Agent delegation (MANDATORY)**: Spawn `art-director` via `Agent`:\n- Provide: game concept (elevator pitch, core fantasy), full pillar set, platform target, any reference games/art from Phase 1 framing, the visual anchor if it exists\n- Ask: \"Draft a Visual Identity Statement for this game. Provide: (1) a one-line visual rule that could resolve any visual decision ambiguity, (2) 2–3 supporting visual principles, each with a one-sentence design test ('when X is ambiguous, this principle says choose Y'). Anchor all principles directly in the stated pillars — each principle must serve a specific pillar. (From a one-page brief, which has no pillars, anchor them in its pitch and \"what they feel\" line.)\"\n\nPresent the art-director's draft to the user. Use `AskUserQuestion`:\n- Options: `[A] Lock this in and write it to design/art/art-bible.md` / `[B] Revise the one-liner` / `[C] Revise a supporting principle` / `[D] Describe my own direction`\n\nWrite the approved section to file immediately.\n\n### Section 2: Mood & Atmosphere\n\n**Goal**: Emotional targets by game state — specific enough for a lighting artist to work from.\n\nFor each major game state (e.g., exploration, combat, victory, defeat, menus — adapt to this game's states), define:\n- Primary emotion/mood target\n- Lighting character (time of day, color temperature, contrast level)\n- Atmospheric descriptors (3–5 adjectives)\n- Energy level (frenetic / measured / contemplative / etc.)\n\n**Agent delegation for Sections 2–4 — one call, issued here.** Spawn\n`art-director` via `Agent` with the locked Visual Identity Statement and pillar set,\nand ask for all three sections in a single brief:\n\n1. **Mood & atmosphere** — \"Define mood and atmosphere targets for each major game state in this game. Be specific — 'dark and foreboding' is not enough. Name the exact emotional target, the lighting character (warm/cool, high/low contrast, time of day direction), and at least one visual element that carries the mood. Each game state must feel visually distinct from the others.\"\n2. **Shape language** — \"Define the shape language for this game. Connect each shape principle back to the visual identity statement and a specific game pillar. Explain what these shape choices communicate to the player emotionally.\"\n3. **Colour system** — \"Design the color system for this game. Every semantic color assignment must be explained — why does this color mean danger/safety/reward in this world? Identify which color pairs might fail colorblind players and specify what backup cues are needed.\"\n\nRequire the three to be **mutually consistent** — the palette must serve the mood\ntargets and the shape hierarchy — and returned as three separately labelled\nblocks so each can be approved and written on its own.\n\nThen present **Section 2** to the user, approve it, and write it to file\nimmediately before moving to Section 3. Do not present all three at once: the\nbatching is in the delegation, not in the review.\n\n### Section 3: Shape Language\n\n**Goal**: The geometric vocabulary that makes this game's world visually coherent and distinguishable.\n\nCover:\n- Character silhouette philosophy (how readable at thumbnail size? Distinguishing trait per archetype?)\n- Environment geometry (angular/curved/organic/geometric — which dominates and why?)\n- UI shape grammar (does UI echo the world aesthetic, or is it a distinct HUD language?)\n- Hero shapes vs. supporting shapes (what draws the eye, what recedes?)\n\n**Draft source**: the Sections 2–4 delegation issued under Section 2 — use the\nshape-language block it returned. Do not spawn again.\n\nWrite the approved section to file immediately.\n\n### Section 4: Color System\n\n**Goal**: A complete, producible palette system that serves both aesthetic and communication needs.\n\nCover:\n- Primary palette (5–7 colors with roles — not just hex codes, but what each color means in this world)\n- Semantic color usage (what does red communicate? Gold? Blue? White? Establish the color vocabulary)\n- Per-biome or per-area color temperature rules (if the game has distinct areas)\n- UI palette (may differ from world palette — define the divergence explicitly)\n- Colorblind safety: which semantic colors need shape/icon/sound backup\n\n**Draft source**: the Sections 2–4 delegation issued under Section 2 — use the\ncolour-system block it returned. Do not spawn again.\n\nWrite the approved section to file immediately.\n\n---\n\n## Phase 3: Production Guides (Sections 5–8)\n\nThese sections translate the visual identity into concrete production rules. They should be specific enough that an outsourcing team can follow them without additional briefing.\n\n### Section 5: Character Design Direction\n\n**Agent delegation for Sections 5–6 — one call, issued here.** Both sections\nneed the **same agent with the same input** (`sections 1–4`), so a second call\nwould only re-send the whole visual identity. Spawn `art-director` once with\nsections 1–4 and ask for both:\n\n1. **Character design direction** — \"Cover: visual archetype for the player character (if any), distinguishing feature rules per character type (how do players tell enemies/NPCs/allies apart at a glance?), expression/pose style targets (stiff/expressive/realistic/exaggerated), and LOD philosophy (how much detail is preserved at game camera distance?).\"\n2. **Environment design language** — \"Cover: architectural style and its relationship to the world's culture/history, texture philosophy (painted vs. PBR vs. stylized — why this choice for this game?), prop density rules (sparse/dense — what drives the choice per area type?), and environmental storytelling guidelines (what visual details should tell the story without text?).\"\n\nRequire characters and environments to be **legible against each other** — a\ncharacter silhouette must read against the environment texture density the same\nbrief defines. Return two separately labelled blocks.\n\nPresent **Section 5** first, approve, write to file, then Section 6.\n\n### Section 6: Environment Design Language\n\n**Draft source**: the Sections 5–6 delegation issued under Section 5 — use the\nenvironment block it returned. Do not spawn again.\n\nWrite the approved section to file.\n\n### Section 7: UI/HUD Visual Direction\n\n**Agent delegation**: Spawn in parallel:\n- **`art-director`**: Visual style for UI — diegetic vs. screen-space HUD, typography direction (font personality, weight, size hierarchy), iconography style (flat/outlined/illustrated/photorealistic), animation feel for UI elements\n- **`ux-designer`**: UX alignment check — does the visual direction support the interaction patterns this game requires? Flag any conflicts between art direction and readability/accessibility needs.\n\nCollect both. If they conflict (e.g., art-director wants elaborate diegetic UI but ux-designer flags it would reduce combat readability), surface the conflict explicitly with both positions. Do NOT silently resolve — use `AskUserQuestion` to let the user decide.\n\nWrite the approved section to file.\n\n### Section 8: Asset Standards\n\n**Agent delegation**: Spawn in parallel:\n- **`art-director`**: File format preferences, naming convention direction, texture resolution tiers, LOD level expectations, export settings philosophy\n- **`technical-artist`**: Engine-specific hard constraints — poly count budgets per asset category, texture memory limits, material slot counts, importer constraints, anything from the performance budgets (`performance.*` in `project.yaml`, falling back to `.claude/docs/technical-preferences.md`)\n\nIf any art preference conflicts with a technical constraint (e.g., art-director wants 4K textures but performance budget requires 2K for mobile), surface the conflict explicitly with both positions — the ideal and the constrained standard, and the tradeoff. Do NOT silently resolve it — use `AskUserQuestion` to let the user pick (options: the ideal standard, the constrained standard, or document both and let per-asset judgment apply). Ambiguity in asset standards is where production costs are born.\n\nWrite the approved section to file.\n\n---\n\n## Phase 4: Reference Direction (Section 9)\n\n**Goal**: A curated reference set that is specific about what to take and what to avoid from each source.\n\n**Agent delegation**: Spawn `art-director` via `Agent` with the completed sections 1–8. Ask: \"Compile a reference direction for this game. Provide 3–5 reference sources (games, films, art styles, or specific artists). For each: name it, specify exactly what visual element to draw from it (not 'the general aesthetic' — a specific technique, color choice, or compositional rule), and specify what to explicitly avoid or diverge from (to prevent the 'trying to copy X' reading). References should be additive — no two references should be pointing in exactly the same direction.\"\n\nWrite the approved section to file.\n\n---\n\n## Phase 5: Art Director Sign-Off\n\n**Review mode check** — apply before spawning AD-ART-BIBLE:\n- `solo` → skip. Note: \"AD-ART-BIBLE skipped — Solo mode.\" Then record the skip\n (below) and proceed to Phase 6.\n- `lean` → skip (not a PHASE-GATE). Note: \"AD-ART-BIBLE skipped — Lean mode.\"\n Then record the skip (below) and proceed to Phase 6.\n- `full` → spawn as normal.\n\nOn either skip, ask \"May I record the skipped sign-off in\n`design/art/art-bible.md`'s header?\" and, on yes, replace the header's\n`> **Art Director Sign-Off (AD-ART-BIBLE)**: [Not yet reviewed]` with\n`> **Art Director Sign-Off (AD-ART-BIBLE)**: SKIPPED [date] — [solo|lean] mode`\n— the gate accepts either form as a recorded sign-off.\n\nAfter all sections are complete (or the scoped set from Phase 1 is complete), spawn `art-director` via `Agent` using gate **AD-ART-BIBLE** (`.claude/docs/director-gates/ad-art-bible.md`).\n\nPass: the art bible path (`design/art/art-bible.md`); the game pillars and core\nfantasy; the platform and performance constraints (`platform.*` and\n`performance.*` from `project.yaml`, falling back to\n`.claude/docs/technical-preferences.md`); and the visual identity anchor. When\nPhase 0 read the one-page brief, pass its pitch and \"what they feel\" line as the\npillars and fantasy, and its \"Art & audio direction\" line as the anchor.\n\nHandle verdict per standard rules in `director-gates.md`.\nOn `Revise flagged items`, or to resolve a REJECT, the section's own specialist\n— `art-director`, with `ux-designer` for Section 7 and `technical-artist` for\nSection 8 — re-drafts each flagged section, which is then presented, approved\nand written like any other section before `REVISED [date]` is recorded.\nA `NOT ASSESSED` answer is never an approval: name the missing input, then\nsupply it and re-run the gate, or record `NOT ASSESSED`.\nRecord the verdict in the art bible's status header:\n`> **Art Director Sign-Off (AD-ART-BIBLE)**: APPROVED [date] / CONCERNS (accepted) [date] / REVISED [date] / NOT ASSESSED [date] — [missing input]`\n\n---\n\n## Phase 6: Close\n\nFirst, name each of the nine sections not authored this run and why — outside\nthe chosen scope, or already complete — e.g. *\"Not authored this run: sections\n5–9 (outside the chosen scope; `standard` requires 1–4).\"* A run that stopped\nafter Section 4 must not read like a finished bible.\n\nBefore presenting next steps, check project state:\n- Does `design/gdd/systems-index.md` exist? → map-systems is done, skip that option\n- Is an engine configured — `engine.name` present in `project.yaml`, or a configured Engine field (not `[TO BE CONFIGURED]`) in `.claude/docs/technical-preferences.md`? → setup-engine is done, skip that option\n- Does `design/gdd/` contain any `*.md` files? → design-system has been run, skip that option\n- Does `design/gdd/gdd-cross-review-*.md` exist? → review-all-gdds is done\n- Do GDDs exist (check above)? → include /consistency-check option\n\nUse `AskUserQuestion` for next steps. Only include options that are genuinely next based on the state check above:\n\nAt `workflow: minimal`, the pool is `/create-stories` (no stories yet) or\n`/dev-story [next story]`, plus Stop here — the GDD/architecture pool below is\n`standard`/`full` only.\n\n**Option pool — include only if not already done:**\n- `[_] Run /map-systems — decompose the concept into systems before writing GDDs` (skip if systems-index.md exists)\n- `[_] Run /setup-engine — configure the engine (asset standards may need revisiting after engine is set)` (skip if engine configured)\n- `[_] Run /design-system — start the first GDD` (skip if any GDDs exist)\n- `[_] Run /review-all-gdds — cross-GDD consistency check (required before Technical Setup gate)` (skip if gdd-cross-review-*.md exists)\n- `[_] Run /asset-spec — generate per-asset visual specs and AI generation prompts from approved GDDs` (include if GDDs exist)\n- `[_] Run /consistency-check — scan existing GDDs against the art bible for visual direction conflicts` (include if GDDs exist)\n- `[_] Run /create-architecture — author the master architecture document (next Technical Setup step)`\n- `[_] Stop here`\n\nAssign letters A, B, C… only to the options actually included. Mark the most logical pipeline-advancing option as `(recommended)`.\n\n> **Always include** (`standard`/`full` only) `/create-architecture` and Stop here as options — these are always valid next steps once the art bible is complete.\n\n---\n\n## Collaborative Protocol\n\n**Applies in `collaborative` mode (the default).** For `guided` and\n`autonomous` modes, see `.claude/docs/automation-modes.md` — the rules below\ndescribe what collaborative mode requires, not universal behavior.\n\nEvery section follows: **Question → Options → Decision → Draft (from art-director agent) → Approval → Write to file**\n\n- Never draft a section yourself — every section's content comes from the\n relevant specialist. One delegation may cover several sections (2–4 share a\n call, as do 5–6), but no section may be written from the orchestrator's own\n judgement instead of an agent's.\n- Write each section to file immediately after approval — do not batch **the\n writes or the approvals**. Batching applies only to the delegation call; the\n user still sees, approves and commits one section at a time.\n- Surface all agent disagreements to the user — never silently resolve conflicts between art-director and technical-artist\n- The art bible is a constraint document: it restricts future decisions in exchange for visual coherence. Every section should feel like it narrows the solution space productively.\n\n---\n\n## Recommended Next Steps\n\nAfter the art bible is approved:\n- Run `/map-systems` to decompose the concept into game systems before authoring GDDs\n- Run `/setup-engine` if the engine is not yet configured (asset standards may need revisiting after engine selection)\n- Run `/design-system [first-system]` to start authoring per-system GDDs\n- Run `/consistency-check` once GDDs exist to validate them against the art bible's visual rules\n- Run `/create-architecture` to produce the master architecture document\n","frontmatter":{"name":"art-bible","description":"Author the Art Bible — visual identity gating asset production. Run before /map-systems.","argument-hint":"[--review full|lean|solo]","user-invocable":true,"allowed-tools":"Read, Glob, Grep, Write, Edit, Agent, AskUserQuestion, Bash(bash \"*/.claude/skills/art-bible/../../hooks/yaml-helper.sh\" resolve_config *)","model":"sonnet","allowedTools":["Read,","Glob,","Grep,","Write,","Edit,","Agent,","AskUserQuestion,","Bash(bash","\"*/.claude/skills/art-bible/../../hooks/yaml-helper.sh\"","resolve_config","*)"]},"allowedTools":["Read,","Glob,","Grep,","Write,","Edit,","Agent,","AskUserQuestion,","Bash(bash","\"*/.claude/skills/art-bible/../../hooks/yaml-helper.sh\"","resolve_config","*)"],"isInternal":false,"tokens":5588,"sizeBytes":24184},{"name":"SKILL.md","path":".claude/skills/asset-audit/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/asset-audit/SKILL.md","title":"asset-audit","category":"anthropic-skill","format":"markdown","content":"---\nname: asset-audit\ndescription: \"Audit assets against naming conventions, file size budgets, format standards. Finds orphaned assets, missing references.\"\nargument-hint: \"[category|all]\"\nuser-invocable: true\nallowed-tools: Read, Glob, Grep, Bash(stat *), Bash(file *), Bash(od *), Bash(wc *), Bash(du *)\nmodel: sonnet\n# Read-only diagnostic skill — no specialist agent delegation needed\n---\n\n# Asset Audit\n\n## Measuring file sizes and formats requires Bash\n\nThis skill's report asks for **file sizes against budgets**, **texture dimensions**\n(power-of-two), **audio sample rates**, and **last-modified times** for orphan\ndetection. None of those are obtainable from `Read`/`Glob`/`Grep` — they need\n`stat` or a binary header read, so the read-only measuring commands (`stat`,\n`file`, `od`, `wc`, `du`) are pre-approved above; list files with Glob. Anything\nelse asks first.\n\n**If you cannot take a measurement, the cell is `NOT ASSESSED`, never an\nestimate.** A size budget table filled from guesses is worse than an empty one:\nit looks like evidence. This is a live fabrication vector even on a project full\nof real assets: if the template demands tables of numbers the tool allowlist\ncannot produce, the only way to complete it is to invent them.\n\n---\n\n## Insufficient input — check this before producing any report\n\n**If the inputs this skill needs do not exist, the answer is \"could not run\" —\nnot a filled-in report.** Check first, and stop if the check fails.\n\n1. List the inputs this skill reads (data files, prior reports, profiler output,\n test results, registries, source code).\n2. For each, record `FOUND` or `ABSENT` — not \"assumed present\".\n3. If any input required for a section is ABSENT, that section is\n **`NOT ASSESSED — NO DATA`**. Do not estimate it, do not infer it from an\n adjacent artifact, and do not leave a mandated cell to be filled by whoever\n reads the template next.\n4. If **every** required input is ABSENT, stop and report\n **`NOT ASSESSED — NO DATA`** as the whole verdict, naming what was missing and\n which skill produces it.\n\n**A verdict of `NOT ASSESSED` is a success.** It is the correct, useful answer to\n\"what does the data say?\" when there is no data. The failure mode this prevents is\nspecific: a report whose verdict enum has no \"could not run\" state produces\n**false clean passes** — an asset audit returning COMPLIANT on a project with no\nassets and no standards, or a performance profile reporting \">99% headroom against\na 16.67ms budget\" with zero profiler data and no budget ever set.\n\n**Absence of evidence is never evidence of absence.** A scan that finds no\nmatches because there are no files to scan has not verified anything. Say which of\nthe two happened — a reader cannot tell from a green result.\n\n---\n\n## Phase 1: Read Standards\n\nRead the art bible's Asset Standards section (`design/art/art-bible.md`) and any\nasset standards in the relevant design docs — size budgets and format rules come\nfrom there. The naming patterns are the ones in Phase 3 below, unless the art\nbible states its own. Read the art bible by section: find the heading with\nthe Grep tool (pattern `^#`, content mode) and Read that range with offset\nand limit.\n\nIf neither states a size budget — or there is no art bible — the Size section is\n`NOT ASSESSED — no size budget set`, and the report names `/art-bible`, whose\nAsset Standards section sets budgets, formats and the naming convention.\n\n---\n\n## Phase 2: Scan Asset Directories\n\nAssets live under the engine's asset root: `assets/` on Godot, `Assets/` on\nUnity, `Content/` on Unreal. Resolve the engine and its code root per\n`.claude/docs/code-root-resolution.md`; that code root is the one Phase 3's\norphan and missing-asset searches read. If it is unresolved, stop:\n`NOT ASSESSED — engine unresolved`, naming `/setup-engine`.\n\nScan the asset root using Glob:\n\n- **Godot** — `assets/art/**/*`, `assets/audio/**/*`, `assets/vfx/**/*`,\n `assets/shaders/**/*`, `assets/data/**/*`\n- **Unity** — `Assets/**/*`, leaving out scripts (`*.cs`, `*.asmdef`) and `*.meta` files\n- **Unreal** — `Content/**/*.uasset` and `Content/**/*.umap`\n\nThe files matched are `Total assets scanned`. If there are none, the checks on\nscanned files — Naming, Size, Format, Orphaned — are\n`NOT ASSESSED — no assets under `; the missing-asset search still runs.\n\n---\n\n## Phase 3: Run Compliance Checks\n\n**Naming conventions:**\n- Art: `[category]_[name]_[variant]_[size].[ext]`\n- Audio: `[category]_[context]_[name]_[variant].[ext]`\n- All files must be lowercase with underscores\n\nThese are Godot's conventions. Unity and Unreal name assets in PascalCase, so on\nthose engines check names only against a naming rule the art bible states; with\nnone, Naming is `NOT ASSESSED — no naming rule for ` (name `/art-bible`).\n\n**File standards:**\n- Textures: Power-of-two dimensions, correct format (PNG for UI, compressed for 3D), within size budget\n- Audio: Correct sample rate, format (OGG for SFX, OGG/MP3 for music), within duration limits.\n `file` reports an audio file's format and sample rate but not its length, and no\n pre-approved tool here does; a duration budget is therefore\n `NOT ASSESSED — duration not measurable here`, naming the files it covers.\n- Data: Valid JSON/YAML, schema-compliant\n\nOn Unreal an asset file (`.uasset`, `.umap`) does not keep its source file's\nformat or dimensions, so Format is `NOT ASSESSED` there; its size is still measured.\n\n**Orphaned assets:** Search the code root for references to each asset file. Flag any with no references.\n\n**Missing assets:** Search the code root for asset references and verify the files exist.\n\nBoth searches need code: if the code root holds no source files, Orphaned and\nMissing are `NOT ASSESSED — no code to search`. On Unity and Unreal most asset\nreferences live in scenes, prefabs and other assets rather than code, so an\nasset no code names may still be in use: Orphaned is `NOT ASSESSED` there.\n\n---\n\n## Phase 4: Output Audit Report\n\n```markdown\n# Asset Audit Report -- [Category] -- [Date]\n\n## Summary\n- **Total assets scanned**: [N]\n- **Naming violations**: [N]\n- **Size violations**: [N]\n- **Format violations**: [N]\n- **Orphaned assets**: [N]\n- **Missing assets**: [N]\n- **Sections not assessed**: [none | each section and why]\n\n## Naming Violations\n| File | Expected Pattern | Issue |\n|------|-----------------|-------|\n\n## Size Violations\n| File | Budget | Actual | Overage |\n|------|--------|--------|---------|\n\n## Format Violations\n| File | Expected Format | Actual Format |\n|------|----------------|---------------|\n\n## Orphaned Assets (no code references found)\n| File | Last Modified | Size | Recommendation |\n|------|-------------|------|---------------|\n\n## Missing Assets (referenced but not found)\n| Reference Location | Expected Path |\n|-------------------|---------------|\n\n## Recommendations\n[Prioritized list of fixes, one per violation, each naming the change — the\ntarget resolution or compression for a size violation, the corrected name for a\nnaming violation, the target format for a format violation]\n\n## Verdict: [NOT ASSESSED / COMPLIANT / WARNINGS / NON-COMPLIANT]\n```\n\nChoose the verdict by the findings, first match wins:\n- **NON-COMPLIANT** — any size violation, or any asset that code references but that does not exist\n- **WARNINGS** — only naming, format or orphaned-asset findings\n- **NOT ASSESSED** — the audit did not cover its scope: no data at all (the path\n above), zero assets scanned, or any section `NOT ASSESSED` — name which. It\n ranks below the two finding verdicts, because a measured violation is more\n actionable than a gap, and above COMPLIANT\n- **COMPLIANT** — at least one asset scanned, every section assessed, no findings\n\nThis skill is read-only — it produces a report but does not write files.\n\n---\n\n## Phase 5: Next Steps\n\n- Fix naming violations using the Phase 3 patterns (or the art bible's, where it states its own).\n- If standards were missing, run `/art-bible` to write its Asset Standards section.\n- Delete confirmed orphaned assets after manual review.\n- Run `/content-audit` to cross-check asset counts against GDD-specified requirements.\n","frontmatter":{"name":"asset-audit","description":"Audit assets against naming conventions, file size budgets, format standards. Finds orphaned assets, missing references.","argument-hint":"[category|all]","user-invocable":true,"allowed-tools":"Read, Glob, Grep, Bash(stat *), Bash(file *), Bash(od *), Bash(wc *), Bash(du *)","model":"sonnet","allowedTools":["Read,","Glob,","Grep,","Bash(stat","*),","Bash(file","*),","Bash(od","*),","Bash(wc","*),","Bash(du","*)"]},"allowedTools":["Read,","Glob,","Grep,","Bash(stat","*),","Bash(file","*),","Bash(od","*),","Bash(wc","*),","Bash(du","*)"],"isInternal":false,"tokens":2020,"sizeBytes":8235},{"name":"SKILL.md","path":".claude/skills/asset-spec/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/asset-spec/SKILL.md","title":"asset-spec","category":"anthropic-skill","format":"markdown","content":"---\nname: asset-spec\ndescription: \"Per-asset visual specs plus AI generation prompts from GDDs and character profiles. After the art bible.\"\nargument-hint: \"[system: | level: | character:] [--review full|lean|solo]\"\nuser-invocable: true\nallowed-tools: Read, Glob, Grep, Write, Edit, Agent, AskUserQuestion, Bash(bash \"*/.claude/skills/asset-spec/../../hooks/yaml-helper.sh\" resolve_config *)\nmodel: sonnet\n---\n\n!`bash \"${CLAUDE_SKILL_DIR}/../../hooks/yaml-helper.sh\" resolve_config --keys review_mode,automation`\n\n# Asset Spec\n\n\n\nIf no argument is provided, check whether `design/assets/entity-inventory.md` exists:\n- If it exists: read it, find the first entity or screen with status \"Needed\" but no spec file yet, and use `AskUserQuestion`:\n - Prompt: \"The next unspecced item is **[name]**. Generate specs for it?\"\n - Options: `[A] Yes — spec [name]` / `[B] Pick a different item` / `[C] Stop here`\n- If no entity inventory: check `design/assets/asset-manifest.md`. If manifest exists, same flow above but reading from manifest.\n- If neither exists: **start the Entity & Screen Inventory flow** (Phase 0b below) rather than failing.\n\n---\n\nEvery `AskUserQuestion` call follows `.claude/docs/automation-modes.md`\n(collaborative asks always · guided major-only · autonomous logs and proceeds;\n`automation_always_ask` categories always prompt). **Note**: actually invoking an external image\ngenerator (calling an image API) always prompts regardless of\n`modes.automation` — it is an irreversible external action guarded\nunconditionally, independent of whether `external_calls` is listed in\n`automation_always_ask`. (Today this skill only emits generation-prompt\n*text*; the guard applies if live generation is ever wired in.)\n\n## Phase 0b: Entity & Screen Inventory (runs when no arguments and no existing inventory)\n\nThis flow produces `design/assets/entity-inventory.md` — the master list of everything\nthe game needs visually. Run once before asset spec work begins.\n\n### Step 1 — Gather from docs\nRead all available source material in parallel, each doc by section: find the\nheadings you need with the Grep tool (pattern `^#`, content mode) and Read those\nranges with offset and limit.\n- `design/gdd/systems-index.md` — extract every system listed\n- GDD asset content — do **not** full-read every GDD. The two wanted sections are\n standard headings, and named entities live in the registry:\n ```\n Grep pattern=\"## (Visual/Audio Requirements|UI Requirements)\" glob=\"design/gdd/*.md\" output_mode=\"content\" -A 25\n ```\n For named entities (characters, enemies, buildings, items), read\n `design/registry/entities.yaml` (`entities`/`items`) if it exists and has\n entries; otherwise grep the GDDs for named content. Full-read a GDD only when\n its Visual/Audio section is missing or reads `[To be designed]` (Phase 1 already\n handles that case). VFX events surface in the Visual/Audio grep context.\n- `design/art/art-bible.md` — extract: any named visual categories, asset type expectations\n- `design/narrative/` — scan for any character or world entity documents if they exist (optional — not required)\n\n### Step 2 — Build proposed inventory\nOrganize everything found into categories:\n\n```\nCharacters / Protagonists\nEnemies / Creatures\nBuildings / Structures\nEnvironment / Terrain\nItems / Props\nVFX / Particles\nUI Screens (list each screen by name)\nHUD Elements\nAudio (SFX, music — descriptions only, no generation prompts)\nOther\n```\n\nFor each item, note the source doc it was found in.\n\n### Step 3 — Present and collaborate\nPresent the full proposed inventory to the user in conversation. Then use `AskUserQuestion`:\n- Prompt: \"I found **[N] visual entities and [N] UI screens** across your GDDs and art bible. Review the list — what's missing, what's not needed?\"\n- Options:\n - `[A] Looks good — save this inventory`\n - `[B] Add items I'll describe`\n - `[C] Remove items that don't apply`\n - `[D] Both add and remove — let me edit`\n\nIf [B] or [D]: ask the user to describe additional items. Accept brief descriptions (\"a medieval keep, used as a level background\") or detailed ones — either works. Work through them collaboratively until the user is satisfied.\n\nIf [C] or [D]: ask which items to remove and why. Remove them from the list.\n\n### Step 4 — Write inventory\nAfter user approval, ask: \"May I write the entity inventory to `design/assets/entity-inventory.md`?\"\n\nWrite the file:\n\n```markdown\n# Visual Entity & Screen Inventory\n\n> Generated: [date]\n> Sources: [list of source docs read]\n\n## Entities\n\n| # | Name | Type | Description | Source | Status |\n|---|------|------|-------------|--------|--------|\n| 1 | [name] | Character / Enemy / Building / Environment / Item / Other | [brief description] | [source doc] | Needed |\n\n## UI Screens\n\n| # | Screen Name | Description | Source | Status |\n|---|-------------|-------------|--------|--------|\n| 1 | Main Menu | [description] | [source] | Needed |\n\n## HUD Elements\n\n| # | Element | Description | Source | Status |\n|---|---------|-------------|--------|--------|\n\n## Audio\n\n| # | Name | Type (SFX / Music / Ambient) | Description | Source | Status |\n|---|------|------------------------------|-------------|--------|--------|\n```\n\nAfter writing, tell the user:\n> \"Entity inventory saved. Next steps:\n> - Run `/ux-design [screen name]` for each UI screen in the inventory\n> - Run `/asset-spec system:[name]`, `level:[name]` or `character:[name]` for each\n> visual entity — whichever of the three the entity belongs to\n> - Or run `/asset-spec` again to work through the inventory one item at a time\"\n\n---\n\n## Phase 0: Parse Arguments\n\nExtract:\n- **Target type**: `system`, `level`, or `character`\n- **Target name**: the name after the colon (normalize to kebab-case)\n- **Review mode**: `--review [full|lean|solo]` if present\n\nThe effective mode is the one already resolved at the top of this skill via\n`resolve_config --keys review_mode`, which applies the full chain; with nothing\nset it follows `modes.rigor` — `solo` at `minimal` (the default), `lean` at\n`standard`, `full` at `full`. A `--review` argument overrides it for this\nrun only.\n\n**Mode behavior:**\n- `full`: spawn both `art-director` and `technical-artist` in parallel\n- `lean`: spawn `art-director` only — faster, skips technical constraint pass\n- `solo`: no agent spawning — main session writes specs from art bible rules alone. Use for simple asset categories or when speed matters more than depth.\n\n---\n\n## Phase 1: Gather Context\n\nRead all source material **before** asking the user anything. Read the art bible and\nthe GDD by section: find the headings you need with the Grep tool (pattern `^#`,\ncontent mode) and Read those ranges with offset and limit.\n\n### Required reads:\n- **Art bible**: Read `design/art/art-bible.md` — fail if missing:\n > \"No art bible found. Run `/art-bible` first — asset specs are anchored to the art bible's visual rules and asset standards.\"\n\n **Exception — the minimal path.** If there is no art bible but\n `design/game-brief.md` exists (at `rigor: minimal` no art bible is required),\n do not fail: anchor the specs in the brief's **Art & audio direction** line,\n and say so at the top of the output — \"Anchored to the brief's one-line art\n direction; there is no art bible, so colour, shape and asset-standard rules\n below are proposals, not constraints.\" Offer `/art-bible` once, as optional.\n The written spec follows the same anchor: its header reads\n `> **Art direction**: design/game-brief.md (Art & audio direction) — no art bible`\n in place of the `> **Art Bible**:` line, each asset carries\n `**Brief anchor:** [the brief line applied]` in place of the **Art Bible\n Anchors** block, and no spec cites an Art Bible section or §8 tier.\n Extract: Visual Identity Statement, Color System (semantic colors), Shape Language, Asset Standards (art bible Section 8 — dimensions, formats, polycount budgets, texture resolution tiers).\n\n- **Project config**: Read `performance.*` and `naming.*` from `project.yaml`; for any key absent or empty (including when `project.yaml` has no `performance` or `naming` block), fall back to `.claude/docs/technical-preferences.md`. Extract performance budgets and naming conventions.\n\n### Source doc reads (by target type):\n- **system**: Read `design/gdd/[target-name].md`. Extract the **Visual/Audio Requirements** section. If it doesn't exist or reads `[To be designed]`:\n > \"The Visual/Audio section of `design/gdd/[target-name].md` is empty. Either run `/design-system [target-name]` to complete the GDD, or describe the visual needs manually.\"\n Use `AskUserQuestion`: `[A] Describe needs manually` / `[B] Stop — complete the GDD first`\n- **level**: Read `design/levels/[target-name].md`. Extract art requirements, asset list, VFX needs, and the art-director's production concept specs from Step 4.\n- **character** or **entity**: Read `design/narrative/characters/[target-name].md` or search `design/narrative/` and `design/assets/entity-inventory.md` for a matching entry. Extract visual description, role, and any specified distinguishing features.\n - **If no source doc exists**: do not fail. Instead, use `AskUserQuestion`:\n - Prompt: \"No profile found for **[name]**. Describe it briefly — a sentence or two is enough.\"\n - Options: `[A] Describe it now` / `[B] Skip this entity` / `[C] Stop here`\n - If [A]: the user's description becomes the source. Brief answers produce concise specs; detailed answers produce detailed specs. Accept whatever level of detail the user provides and work from it.\n\n### Optional reads:\n- **This target's existing spec**: if `design/assets/specs/[target-name]-assets.md` exists, read it — this is a re-run, and Phase 2 proposes only what is new or changed since (Phase 5 updates the file in place).\n- **Existing manifest**: Read `design/assets/asset-manifest.md` if it exists — extract already-specced assets for this target to avoid duplicates.\n- **Related specs**: Glob `design/assets/specs/*.md` — scan for assets that could be shared (e.g., a common UI element specced for one system might apply here too).\n\n### Present context summary:\n> **Asset Spec: [Target Type] — [Target Name]**\n> - Source doc: [path] — [N] asset types identified\n> - Art bible: found — Asset Standards at Section 8\n> - Existing specs for this target: [N already specced / none]\n> - Shared assets found in other specs: [list or \"none\"]\n\n---\n\n## Phase 2: Asset Identification\n\nFrom the source doc, extract every asset type mentioned — explicit and implied.\n\n**For systems**: look for VFX events, sprite references, UI elements, audio triggers, particle effects, icon needs, and any \"visual feedback\" language.\n\n**For levels**: look for unique environment props, atmospheric VFX, lighting setups, ambient audio, skybox/background, and any area-specific materials.\n\n**For characters**: look for sprite sheets (idle, walk, attack, death), portrait/avatar, VFX attached to abilities, UI representation (icon, health bar skin).\n\nGroup assets into categories:\n- **Sprite / 2D Art** — character sprites, UI icons, tile sheets\n- **VFX / Particles** — hit effects, ambient particles, screen effects\n- **Environment** — props, tiles, backgrounds, skyboxes\n- **UI** — HUD elements, menu art, fonts (if custom)\n- **Audio** — SFX, music tracks, ambient loops *(note: audio specs are descriptions only — no generation prompts)*\n- **3D Assets** — meshes, materials (if applicable per engine)\n\nPresent the full identified list to the user. Use `AskUserQuestion`:\n- Prompt: \"I identified [N] assets across [N] categories for **[target]**. Review before speccing:\"\n- Show the grouped list in conversation text first\n- Options: `[A] Proceed — spec all of these` / `[B] Remove some assets` / `[C] Add assets I didn't catch` / `[D] Adjust categories`\n\nDo NOT proceed to Phase 3 without user confirmation of the asset list.\n\n---\n\n## Phase 3: Spec Generation\n\nSpawn specialist agents based on review mode. **Issue all `Agent` calls simultaneously — do not wait for one before starting the next.**\n\n### Full mode — spawn in parallel:\n\n**`art-director`** via `Agent`:\n- Provide: full asset list from Phase 2, art bible Visual Identity Statement, Color System, Shape Language, the source doc's visual requirements, and any reference games/art mentioned in the art bible Section 9\n- Ask: \"For each asset in this list, produce: (1) a 2–3 sentence visual description anchored to the art bible's shape language and color system — be specific enough that two different artists would produce consistent results; (2) a generation prompt ready for use with AI image tools (Midjourney/Stable Diffusion style — include style keywords, composition, color palette anchors, negative prompts); (3) which art bible rules directly govern this asset (cite by section). For audio assets, describe the sonic character instead of a generation prompt.\"\n\n**`technical-artist`** via `Agent`:\n- Provide: full asset list, art bible Asset Standards (Section 8), performance budgets (`performance.*` from `project.yaml`, else `technical-preferences.md`), engine name and version\n- Ask: \"For each asset in this list, specify: (1) exact dimensions or polycount (match the art bible Asset Standards tiers — do not invent new sizes); (2) file format and export settings; (3) naming convention (`naming.*` from `project.yaml`, else `technical-preferences.md`); (4) any engine-specific constraints this asset type must respect; (5) LOD requirements if applicable. Flag any asset type where the art bible's preferred standard conflicts with the engine's constraints.\"\n\n### Lean mode — spawn art-director only (skip technical-artist).\n\n### Solo mode — skip both. Derive specs from art bible rules alone, noting that technical constraints were not validated.\n\n**Announce every skipped agent by name in the output**, before the specs:\n\"technical-artist skipped — Lean mode: technical constraints not validated.\" /\n\"art-director and technical-artist skipped — Solo mode: specs derived in this\nsession; technical constraints not validated.\" A spec drafted without an agent\nmust not read like one an agent reviewed.\n\n**Collect both responses before Phase 4.** If any conflict exists between art-director and technical-artist (e.g., art-director specifies 4K textures but technical-artist flags the engine budget requires 512px), surface it explicitly — do NOT silently resolve.\n\n---\n\n## Phase 4: Compile and Review\n\nCombine the agent outputs into a draft spec per asset. Present all specs in conversation text using this format:\n\n```\n## ASSET-[NNN] — [Asset Name]\n\n| Field | Value |\n|-------|-------|\n| Category | [Sprite / VFX / Environment / UI / Audio / 3D] |\n| Dimensions | [e.g. 256×256px, 4-frame sprite sheet] |\n| Format | [PNG / SVG / WAV / etc.] |\n| Naming | [e.g. vfx_frost_hit_01.png] |\n| Polycount | [if 3D — e.g. <800 tris] |\n| Texture Res | [e.g. 512px — matches Art Bible §8 Tier 2] |\n\n**Visual Description:**\n[2–3 sentences. Specific enough for two artists to produce consistent results.]\n\n**Art Bible Anchors:**\n- §3 Shape Language: [relevant rule applied]\n- §4 Color System: [color role — e.g. \"uses Threat Blue per semantic color rules\"]\n\n**Generation Prompt:**\n[Ready-to-use prompt. Include: style keywords, composition notes, color palette anchors, lighting direction, negative prompts.]\n\n**Status:** Needed\n```\n\nAfter presenting all specs, use `AskUserQuestion`:\n- Prompt: \"Asset specs for **[target]** — [N] assets. Review complete?\"\n- Options: `[A] Approve all — write to file` / `[B] Revise a specific asset` / `[C] Regenerate with different direction`\n\nIf [B]: ask which asset and what to change. Revise inline and re-present. Do NOT re-spawn agents for minor text revisions — only re-spawn if the visual direction itself needs to change.\n\nIf [C]: ask what direction to change. Re-spawn the relevant agent with the updated brief.\n\n---\n\n## Phase 5: Write Spec File\n\nAfter approval, ask: \"May I write the spec to `design/assets/specs/[target-name]-assets.md`?\"\n\n**If that file already exists** (a re-run for the same target), update it in\nplace — never overwrite it wholesale. Keep its existing `ASSET-NNN` blocks and\nIDs, apply only the changes the user approved, and append new assets with the\nnext project-wide IDs. Show what changes, then ask \"May I update\n`design/assets/specs/[target-name]-assets.md`?\" instead of \"May I write\".\n\nWrite the file with:\n\n```markdown\n# Asset Specs — [Target Type]: [Target Name]\n\n> **Source**: [path to source GDD/level/character doc]\n> **Art Bible**: design/art/art-bible.md\n> **Generated**: [date]\n> **Status**: [N] assets specced / [N] approved / [N] in production / [N] done\n\n[all asset specs in ASSET-NNN format]\n```\n\nThen update `design/assets/asset-manifest.md`. If it doesn't exist, create it:\n\n```markdown\n# Asset Manifest\n\n> Last updated: [date]\n\n## Progress Summary\n\n| Total | Needed | In Progress | Done | Approved |\n|-------|--------|-------------|------|----------|\n| [N] | [N] | [N] | [N] | [N] |\n\n## Assets by Context\n\n### [Target Type]: [Target Name]\n| Asset ID | Name | Category | Status | Spec File |\n|----------|------|----------|--------|-----------|\n| ASSET-001 | [name] | [category] | Needed | design/assets/specs/[target]-assets.md |\n```\n\nIf the manifest already exists, append the new context block — on a re-run for this target, add the new rows to its existing block instead of appending a second one — and update the Progress Summary counts.\n\nAsk: \"May I update `design/assets/asset-manifest.md`?\"\n\n---\n\n## Phase 6: Close\n\nUse `AskUserQuestion`:\n- Prompt: \"Asset specs complete for **[target]**. What's next?\"\n- Options:\n - `[A] Spec another system — /asset-spec system:[next-system]`\n - `[B] Spec a level — /asset-spec level:[level-name]`\n - `[C] Spec a character — /asset-spec character:[character-name]`\n - `[D] Run /asset-audit — validate delivered assets against specs`\n - `[E] Stop here`\n\n---\n\n## Asset ID Assignment\n\nAsset IDs are assigned sequentially across the entire project — not per-context. Read the manifest before assigning IDs to find the current highest number:\n\n```\nGrep pattern=\"ASSET-\" path=\"design/assets/asset-manifest.md\"\n```\n\nStart new assets from `ASSET-[highest + 1]`. This ensures IDs are stable and unique across the whole project.\n\nIf no manifest exists yet, start from `ASSET-001`.\n\n---\n\n## Shared Asset Protocol\n\nBefore speccing an asset, check if an equivalent already exists in another context's spec:\n\n- Common UI elements (health bars, score displays) are often shared across systems\n- Generic environment props may appear in multiple levels\n- Character VFX (hit sparks, death effects) may reuse a base spec with color variants\n\nIf a match is found: reference the existing ASSET-ID rather than creating a duplicate. Note the shared usage in the manifest's referenced-by column.\n\n> \"ASSET-012 (Generic Hit Spark) already specced for Combat system. Reusing for Tower Defense — adding tower-defense to referenced-by.\"\n\n---\n\n## Error Recovery Protocol\n\nIf any spawned agent returns BLOCKED or cannot complete:\n\n1. Surface immediately: \"[AgentName]: BLOCKED — [reason]\"\n2. In `lean` mode or if `technical-artist` blocks: proceed with art-director output only — note that technical constraints were not validated\n3. In `solo` mode or if `art-director` blocks: derive descriptions from art bible rules — flag as \"Art director not consulted — verify against art bible before production\"\n4. Always produce a partial spec — never discard work because one agent blocked\n\n---\n\n## Collaborative Protocol\n\n**Applies in `collaborative` mode (the default).** For `guided` and\n`autonomous` modes, see `.claude/docs/automation-modes.md` — the rules below\ndescribe what collaborative mode requires, not universal behavior.\n\nEvery phase follows: **Identify → Confirm → Generate → Review → Approve → Write**\n\n- Never spec assets without first confirming the asset list with the user\n- Always anchor specs to the art bible — a spec that contradicts the art bible is wrong\n- Surface all agent disagreements — do not silently pick one\n- Write the spec file only after explicit approval\n- Update the manifest immediately after writing the spec\n\n---\n\n## Recommended Next Steps\n\n- Run `/asset-spec [next-context]` to continue speccing remaining systems, levels, or characters\n- Run `/asset-audit` to validate delivered assets against the written specs and identify gaps or mismatches\n","frontmatter":{"name":"asset-spec","description":"Per-asset visual specs plus AI generation prompts from GDDs and character profiles. After the art bible.","argument-hint":"[system: | level: | character:] [--review full|lean|solo]","user-invocable":true,"allowed-tools":"Read, Glob, Grep, Write, Edit, Agent, AskUserQuestion, Bash(bash \"*/.claude/skills/asset-spec/../../hooks/yaml-helper.sh\" resolve_config *)","model":"sonnet","allowedTools":["Read,","Glob,","Grep,","Write,","Edit,","Agent,","AskUserQuestion,","Bash(bash","\"*/.claude/skills/asset-spec/../../hooks/yaml-helper.sh\"","resolve_config","*)"]},"allowedTools":["Read,","Glob,","Grep,","Write,","Edit,","Agent,","AskUserQuestion,","Bash(bash","\"*/.claude/skills/asset-spec/../../hooks/yaml-helper.sh\"","resolve_config","*)"],"isInternal":false,"tokens":4931,"sizeBytes":20565},{"name":"SKILL.md","path":".claude/skills/balance-check/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/balance-check/SKILL.md","title":"balance-check","category":"anthropic-skill","format":"markdown","content":"---\nname: balance-check\ndescription: \"Find balance outliers, broken progressions, degenerate strategies, economy imbalances in formulas and data. 'Check game balance'.\"\nargument-hint: \"[system-name|path-to-data-file]\"\nuser-invocable: true\nallowed-tools: Read, Glob, Grep, Write, AskUserQuestion, Bash(bash \"*/.claude/skills/balance-check/../../hooks/yaml-helper.sh\" resolve_config *)\nmodel: sonnet\n---\n\n!`bash \"${CLAUDE_SKILL_DIR}/../../hooks/yaml-helper.sh\" resolve_config --keys automation`\n\n# Balance Check\n\n\n\nEvery `AskUserQuestion` call follows `.claude/docs/automation-modes.md`\n(collaborative asks always · guided major-only · autonomous logs and proceeds;\n`automation_always_ask` categories always prompt).\n\n## Insufficient input — check this before producing any report\n\n**If the inputs this skill needs do not exist, the answer is \"could not run\" —\nnot a filled-in report.** Check first, and stop if the check fails.\n\n1. List the inputs this skill reads (data files, prior reports, profiler output,\n test results, registries, source code).\n2. For each, record `FOUND` or `ABSENT` — not \"assumed present\".\n3. If any input required for a section is ABSENT, that section is\n **`NOT ASSESSED — NO DATA`**. Do not estimate it, do not infer it from an\n adjacent artifact, and do not leave a mandated cell to be filled by whoever\n reads the template next.\n4. If **every** required input is ABSENT, stop and report\n **`NOT ASSESSED — NO DATA`** as the whole verdict, naming what was missing and\n which skill produces it.\n\n**A verdict of `NOT ASSESSED` is a success.** It is the correct, useful answer to\n\"what does the data say?\" when there is no data. The failure mode this prevents is\nspecific: a report whose verdict enum has no \"could not run\" state produces\n**false clean passes** — an asset audit returning COMPLIANT on a project with no\nassets and no standards, or a performance profile reporting \">99% headroom against\na 16.67ms budget\" with zero profiler data and no budget ever set.\n\n**Absence of evidence is never evidence of absence.** A scan that finds no\nmatches because there are no files to scan has not verified anything. Say which of\nthe two happened — a reader cannot tell from a green result.\n\n---\n\n## Phase 1: Identify Balance Domain\n\nDetermine the balance domain from `$ARGUMENTS` — the whole string, since a data-file path may contain spaces:\n\n- **Combat** → weapon/ability DPS, time-to-kill, damage type interactions\n- **Economy** → resource faucets/sinks, acquisition rates, item pricing\n- **Progression** → XP/power curves, dead zones, power spikes\n- **Loot** → rarity distribution, pity timers, inventory pressure\n- **File path given** → load that file directly and infer domain from content\n\nIf no argument, ask the user which system to check.\n\n---\n\n## Phase 2: Read Data Files\n\nRead relevant files from `assets/data/` and `design/balance/` for the identified domain.\nNote every file read — they will appear in the Data Sources section of the report.\n\n---\n\n## Phase 3: Read Design Document\n\n**Registry first.** If `design/registry/entities.yaml` exists, read it before the\nGDD. Its `constants` and `formulas` sections hold the cross-GDD named values and\noutput ranges — the balance targets — already distilled, each with a `source:`\nGDD and any `revised:` date:\n```\nGrep pattern=\"^ - name:\" path=\"design/registry/entities.yaml\" output_mode=\"content\" -A 6\n```\nTake the intended values from the registry for any constant or formula it lists\n(the `constants:` and `formulas:` blocks); these are the authoritative cross-doc\nfigures a GDD must not contradict. **If `design/registry/entities.yaml` does not\nexist or has no entries** (it ships as an empty stub until `/design-system`\npopulates it), skip this and use the GDD alone.\n\nThen read the GDD for the system from `design/gdd/` to understand intended design\ntargets, tuning knobs, and expected value ranges — for anything the registry did\nnot already supply. This is the baseline for \"correct\" behaviour. Read it by section:\nfind the headings you need with the Grep tool (pattern `^#`, content mode) and\nRead those ranges with offset and limit.\n\nIf the data files are FOUND but neither source gives targets for this domain,\nthe sections that judge against targets (Outliers Detected, and Progression\nAnalysis where the domain has a curve) are `NOT ASSESSED — NO DATA`. Each one names what was missing — the\nGDD it looked for in `design/gdd/`, and whether the registry was absent or empty\n— and names `/design-system`, which writes both.\n\n---\n\n## Phase 4: Perform Analysis\n\n**Every domain: compare each value with its target.** For each named value in the\ndata files, take its target from Phase 3 — a registry constant's `value`, a\nregistry formula's `output_range`, or the range the GDD states — and compare. A\nvalue outside its target is a row in Outliers Detected (`player_damage_base` 140\nagainst 90–110). A value with no target anywhere is neither in range nor an\noutlier: list it under Values That Need Attention as `no stated range — not judged`.\n\nThen run domain-specific checks:\n\n**Combat balance:**\n- Calculate DPS for all weapons/abilities at each power tier\n- Check time-to-kill at each tier\n- Identify any options that dominate all others (strictly better)\n- Check if defensive options can create unkillable states\n- Verify damage type/resistance interactions are balanced\n\n**Economy balance:**\n- Map all resource faucets and sinks with flow rates\n- Project resource accumulation over time\n- Check for infinite resource loops\n- Verify gold sinks scale with gold generation\n- Check if any items are never worth purchasing\n\n**Progression balance:**\n- Plot the XP curve and power curve\n- Check for dead zones (no meaningful progression for too long)\n- Check for power spikes (sudden jumps in capability)\n- Verify content gates align with expected player power\n- Check if skip/grind strategies break intended pacing\n\n**Loot balance:**\n- Calculate expected time to acquire each rarity tier\n- Check pity timer math\n- Verify no loot is strictly useless at any stage\n- Check inventory pressure vs acquisition rate\n\n---\n\n## Phase 5: Output the Analysis\n\n```\n## Balance Check: [System Name]\n\n### Data Sources Analyzed\n- [List of files read]\n\n### Health Summary: [NOT ASSESSED / HEALTHY / CONCERNS / CRITICAL ISSUES]\n\n### Outliers Detected\n| Item/Value | Expected Range | Actual | Issue |\n|-----------|---------------|--------|-------|\n\n### Degenerate Strategies Found\n- [Strategy description and why it is problematic]\n\n### Progression Analysis\n[Graph description or table showing progression curve health]\n\n### Recommendations\n| Priority | Issue | Suggested Fix | Impact |\n|----------|-------|--------------|--------|\n\n### Values That Need Attention\n[Specific values with suggested adjustments and rationale]\n```\n\nChoose the Health Summary by the worst finding, first match wins:\n- **CRITICAL ISSUES** — a degenerate strategy (one choice dominates every\n alternative), a progression that stalls or cannot be completed, or an economy\n loop with no sink\n- **CONCERNS** — outliers or curve problems a tuning pass can fix, with no\n finding of the critical kind\n- **NOT ASSESSED** — nothing to analyze (the no-data path above), a section that\n needs targets is `NOT ASSESSED — NO DATA`, or a value had no stated range to\n judge it against; name which. It ranks below the two finding verdicts, because\n a measured problem is more actionable than a gap, and above HEALTHY\n- **HEALTHY** — every value judged against a stated target, no outliers, no\n degenerate strategies, progression within the stated targets\n\n---\n\n## Phase 6: Fix & Verify Cycle\n\nAfter presenting the report, use `AskUserQuestion`:\n- Prompt: \"Balance check complete. What would you like to do next?\"\n- Options:\n - `[A] Fix highest-priority issue now — walk me through it`\n - `[B] Save report to design/balance/balance-check-[system]-[date].md`\n - `[C] Stop here — I'll review the findings manually`\n\n**Run as a subagent?** `game-designer` preloads this skill, and a subagent has\nno `AskUserQuestion`. End your reply with the question and these three options\nas a short list, and stop: whoever called you asks the user and passes the\nanswer back.\n\nIf [A]:\n- Ask which issue to address first (refer to the Recommendations table by priority row)\n- Guide the user to update the relevant data file in `assets/data/` or formula in `design/balance/`\n- After each fix, offer to re-run the relevant balance checks to verify no new outliers were introduced\n- If the fix changes a tuning knob defined in a GDD or referenced by an ADR, remind the user:\n > \"This value is defined in a design document. Run `/propagate-design-change [path]` on the affected GDD to find downstream impacts before committing.\"\n\nIf [B]:\n- Write the report to `design/balance/balance-check-[system]-[date].md` (create the directory if needed). Use the current date for [date] in YYYY-MM-DD format.\n- Confirm the file was written, then end with: \"Re-run `/balance-check` after fixes to verify.\"\n\nIf [C]:\n- Summarize open issues and end with: \"Re-run `/balance-check` after fixes to verify.\"\n","frontmatter":{"name":"balance-check","description":"Find balance outliers, broken progressions, degenerate strategies, economy imbalances in formulas and data. 'Check game balance'.","argument-hint":"[system-name|path-to-data-file]","user-invocable":true,"allowed-tools":"Read, Glob, Grep, Write, AskUserQuestion, Bash(bash \"*/.claude/skills/balance-check/../../hooks/yaml-helper.sh\" resolve_config *)","model":"sonnet","allowedTools":["Read,","Glob,","Grep,","Write,","AskUserQuestion,","Bash(bash","\"*/.claude/skills/balance-check/../../hooks/yaml-helper.sh\"","resolve_config","*)"]},"allowedTools":["Read,","Glob,","Grep,","Write,","AskUserQuestion,","Bash(bash","\"*/.claude/skills/balance-check/../../hooks/yaml-helper.sh\"","resolve_config","*)"],"isInternal":false,"tokens":2160,"sizeBytes":9187},{"name":"full-concept.md","path":".claude/skills/brainstorm/references/full-concept.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/brainstorm/references/full-concept.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# Full concept flow (`workflow: standard` or `full`)\n\n**In this file:** start · Phase 1 Creative discovery · Phase 2 Concept generation · Phase 3 Core loop ·\nPhase 4 Pillars and boundaries · Phase 5 Player types · Phase 6 Scope and feasibility · Phase 7\nWrite the concept · Phase 8 Next steps\n\nThe output is `design/gdd/game-concept.md`, written from the game-concept template SKILL.md names.\nAsk at each phase; never generate the whole concept silently. You facilitate, the user decides.\nWrite the analysis in your reply first, then ask with short option labels.\n\n## Start\n\n1. The text typed after the skill name may hold a genre or theme hint (`roguelike`, `cozy\n farming`). `open` or nothing: start from scratch.\n2. If `design/gdd/game-concept.md` or `design/gdd/game-pillars.md` exists, read it by section (find\n the headings with the Grep tool with pattern `^#` in content mode, then read those ranges)\n and resume or build on it instead of restarting.\n\n## Phase 1: Creative discovery\n\nStart with the person, not the game. Ask conversationally:\n- A moment in a game that moved or thrilled them, and what created it.\n- A fantasy they have always wanted in a game and never found.\n- The three games they spent the most time with, and why. Ask this as plain text, never with\n preset options: they must be able to type any game.\n- Genres they love or avoid. Then ask: challenge, relax, story or self-expression?\n\nThen ask these three questions together:\n- \"What kind of experience do you most want players to have?\" Challenge & Mastery / Story &\n Discovery / Expression & Creativity / Relaxation & Flow\n- \"What's your realistic development timeline?\" Weeks / Months / 1-2 years / Multi-year\n- \"Where are you in your dev journey?\" First game / Shipped before / Professional background\n\nSum the answers up as a **Creative Brief** of 3 to 5 sentences (emotional goals, taste,\nconstraints), read it back and confirm it.\n\n## Phase 2: Concept generation\n\nGenerate **three** distinct concepts from the brief, each in a different direction, using:\n- **Verb-first:** start from the core verb (build, fight, explore, solve, survive, manage).\n- **Mashup:** genre A + theme B; the tension is the hook (\"farming sim + cosmic horror\").\n- **Experience-first (MDA backward):** start from the aesthetic (sensation, fantasy, narrative,\n challenge, fellowship, discovery, expression, submission) and work back to mechanics.\n\nEach concept has: Working Title · Elevator Pitch (1-2 sentences, passes the 10-second test) · Core\nVerb · Core Fantasy · Unique Hook (\"like X, and also Y\") · Primary MDA Aesthetic · Estimated Scope\n(small / medium / large) · Why It Could Work (one sentence) · Biggest Risk (one sentence).\n\nPresent all three, then ask one question with these five options: \"Which concept resonates with\nyou? You can pick one, combine elements, or ask for fresh directions.\" `Concept 1 — [Title]` /\n`Concept 2 — [Title]` / `Concept 3 — [Title]` / `Combine elements across concepts` / `Generate\nfresh directions`. Ask it in every automation mode: no rule can pick the user's creative\ndirection. Do not push toward a choice.\n\n## Phase 3: Core loop\n\nFor the chosen concept, ask with options derived from the concept, each with an `I'll describe it`\noption:\n1. \"What's the primary feel of the core action?\" (3-4 options that fit the genre and tone)\n2. The concept's most important design variable (world reactivity, pacing, agency), as a question.\n\nThen work through, in the reply:\n- **30-second loop:** is the action satisfying in itself, and why (feedback, timing, depth)?\n- **5-minute loop:** what turns moments into cycles; where \"one more run\" starts; the choices made.\n- **Session loop (30-120 minutes):** a full session, its stopping points, the hook between sessions.\n- **Progression loop:** how the player grows, the long-term goal, when the game is done.\n- **Motivation (self-determination theory):** autonomy, competence, relatedness.\n\n## Phase 4: Pillars and boundaries\n\nDraft **3 to 5 pillars**, each with a name, a one-sentence definition and a design test (\"debating\nX or Y, this pillar picks __\"). Pillars should pull against each other a little. Add **3 or more\nanti-pillars**: \"We will NOT do [thing] because it would compromise [pillar].\"\n\nAsk: \"Do these pillars feel right for your game?\" `Lock these in` / `Rename or reframe one` /\n`Swap a pillar out` / `Something else`. After a revision ask: \"Pillars updated. Ready to lock these\nin?\" `Lock these in` / `Revise another pillar` / `Something else`.\n- `collaborative`: repeat until the user picks `Lock these in`.\n- `guided`: ask once, apply the revision, lock them in.\n- `autonomous`: do not ask; lock the draft in and log the decision with the alternatives.\n\n**Review mode** (from the settings block or `--review`):\n- `solo` or `lean`: print these two lines, with the mode's name, and go on to Phase 5:\n `CD-PILLARS skipped — Solo mode.` and `AD-CONCEPT-VISUAL skipped — Solo mode.`\n- `full`: hand the pillar review to the `creative-director` agent (gate CD-PILLARS; brief: the\n pillars with design tests, anti-pillars, core fantasy and hook) and the visual review to the\n `art-director` agent (gate AD-CONCEPT-VISUAL; brief: the pitch, pillars, target platform if\n known, reference games mentioned). Each reads its own gate file and returns its verdict; neither\n edits files. They are independent: hand them out together where you can, otherwise one after\n another.\n\nWith both reports, when CD-PILLARS returns APPROVE, ask these two questions together:\n- **Pillars:** the creative-director's feedback. `Lock in as-is` / `Revise [pillar]` / `Discuss\n further`.\n- **Visual anchor:** the art-director's 2-3 named directions, one option each, plus `Combine\n elements across directions` / `Describe my own direction`. On STRONG mark the dominant one\n `(Recommended)`. On CONCERNS show its reason and offer `Revise pillars` / `Describe my own\n direction`.\n\nIf CD-PILLARS returns CONCERNS or REJECT, settle the pillars first (the Pillars question alone),\nthen ask the Visual anchor question alone. NOT ASSESSED from either gate is not an approval: name\nthe missing input, supply it and run that gate again; failing that, treat CD-PILLARS NOT ASSESSED\nas CONCERNS, and with no art-director directions offer only `Describe my own direction`.\n\nThe chosen direction is the **Visual Identity Anchor**: it goes into the concept and seeds the art\nbible.\n\n## Phase 5: Player types\n\nUsing Bartle's types and the Quantic Foundry model: the primary player who will love it\n(Achievers, Explorers, Socializers, Competitors, Creators, Storytellers), the secondary appeal, who\nit is not for, and successful games that serve the same player.\n\n## Phase 6: Scope and feasibility\n\n- **Platform.** Ask: \"What platforms are you targeting?\" `PC (Steam / Epic)` / `Mobile (iOS /\n Android)` / `Console` / `Web / Browser` / `Multiple platforms`. Record it for `/setup-engine`.\n Note what the platform implies, without recommending an engine: `/setup-engine` makes that call\n against the pinned engine reference.\n- **Engine.** Ask in every automation mode, `autonomous` included: \"Do you already have an engine\n you work in?\" `Godot` / `Unity` / `Unreal Engine 5` / `No preference — help me decide`. Never\n pick an engine for the user. A named engine is recorded as their preference without second\n guessing. No preference: \"Run `/setup-engine` after this session; it walks through the choice\n with your concept and platform.\" Make no recommendation here.\n- Art pipeline and how labour-heavy it is; content scope (levels, items, hours); the MVP (the\n smallest build that tests whether the core loop is fun); the biggest technical, design and market\n risks; scope tiers (full vision, and what ships if time runs out).\n\n**Review mode** before TD-FEASIBILITY: `solo` or `lean` prints `TD-FEASIBILITY skipped — Solo\nmode.` (or `Lean mode`) and goes on to the scope tiers. `full`: after the technical risks, hand the\nfeasibility review to the `technical-director` agent (gate TD-FEASIBILITY; brief: the core loop,\nplatform, engine or \"undecided\", the technical risks). Show its report. HIGH RISK: offer to revisit\nscope. CONCERNS: note and go on. NOT ASSESSED: name the missing input and record feasibility as not\nassessed in the concept's risks, never as VIABLE.\n\n**Review mode** before PR-SCOPE: `solo` or `lean` prints `PR-SCOPE skipped — Solo mode.` (or `Lean\nmode`) and goes on to Phase 7. `full`: hand the scope review to the `producer` agent (gate PR-SCOPE;\nbrief: full vision, MVP, scope tiers, timeline, team size). It answers REALISTIC, OPTIMISTIC or\nUNREALISTIC. UNREALISTIC: ask whether to adjust the MVP or scope tiers or keep them; the user\ndecides and the concept is never rejected for it. OPTIMISTIC: show the producer's adjustments and\nask whether to apply them. NOT ASSESSED: ask for the missing input (timeline, team size) and run it\nagain, or record scope as not assessed, never as REALISTIC.\n\n## Phase 7: Write the concept\n\nFill every section of the template from the conversation, including the MDA analysis, motivation\nprofile and flow design, plus a **Visual Identity Anchor** section: the direction's name, its\none-line visual rule, 2-3 supporting principles with design tests, and the colour philosophy.\n\nThe Core Identity table's Estimated Scope matches the full-vision timeline in Scope Tiers: write\n\"Large (X–Y months, solo)\" or \"Large (X–Y months, team of N)\", not \"Large\".\n\nAsk, as its own question: \"Game concept is ready. May I write it to `design/gdd/game-concept.md`?\"\n`Yes — write it` / `Not yet — revise a section first`. Write only on an explicit yes to this\nquestion. A revision: ask which section (`Elevator Pitch` / `Core Fantasy & Unique Hook` /\n`Pillars` / `Core Loop` / `MVP Definition` / `Scope Tiers` / `Risks` / `Something else — I'll\ndescribe`), show it before and after, then ask \"Ready to write the updated concept document?\"\n`Yes — write it` / `Revise another section`.\n- `collaborative`: repeat until the yes.\n- `guided`: ask once, apply the revision and write.\n- `autonomous`: do not ask; write and log the decision.\n\nWrite the file, creating folders as needed. Never write `design/game-brief.md` at this tier.\n\n## Phase 8: Next steps\n\nList every step, in order.\n\n**Design-first** (the concept is well defined):\n1. `/setup-engine`: configure the engine and its version-aware reference docs\n2. `/art-bible`: the visual identity, before any GDD. Required before the Technical Setup gate at\n `full`; at `standard` only when the game has visual-asset stories\n3. `/design-review design/gdd/game-concept.md`: check the concept is complete\n4. The `creative-director` agent: refine the pillars\n5. `/map-systems`: the systems, their dependencies and priorities, in the systems index\n6. `/design-system`: one GDD per system from step 5\n7. `/create-architecture`: the architecture blueprint and its Required ADR list\n8. `/architecture-decision`: one ADR per decision on that list\n9. `/architecture-review`: the TR registry and traceability matrix (needed before the\n Pre-Production gate)\n10. `/gate-check`: the stage gate before Production\n\n**Prototype-first** (the core mechanic is unproven):\n1. `/setup-engine`\n2. `/prototype [core mechanic]`: is it fun, in a day at most, throwaway code\n3. PROCEED: `/art-bible`, then design-first steps 5-10 with what the prototype taught\n4. PIVOT: `/brainstorm` again with the learnings\n5. After design and architecture, `/vertical-slice` before committing to sprints\n\nThen a summary: the pitch, pillars, primary player type, engine preference, biggest risk and the\nfile path. End with the line `Verdict: COMPLETE — game concept written.`\n\nIf the conversation is getting long before Phase 7, say that anything not yet written to\n`design/gdd/game-concept.md` lives only in this conversation, and write the concept before a fresh\nsession.\n","isInternal":false,"tokens":2961,"sizeBytes":11915},{"name":"SKILL.md","path":".claude/skills/brainstorm/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/brainstorm/SKILL.md","title":"brainstorm","category":"anthropic-skill","format":"markdown","content":"","frontmatter":{"name":"brainstorm","description":"Guides the user through finding and choosing a game concept. Use when the user wants game ideas, a new concept, a game jam idea, or to explore other directions, including dropping the current idea and starting over.","argument-hint":"[genre or theme hint, or 'open'] [--review full|lean|solo]","user-invocable":true,"allowed-tools":"Read, Glob, Grep, Write, WebSearch, Agent, AskUserQuestion, Bash(bash \"*/.claude/skills/brainstorm/../../hooks/yaml-helper.sh\" resolve_config *)","model":"sonnet","allowedTools":["Read,","Glob,","Grep,","Write,","WebSearch,","Agent,","AskUserQuestion,","Bash(bash","\"*/.claude/skills/brainstorm/../../hooks/yaml-helper.sh\"","resolve_config","*)"]},"allowedTools":["Read,","Glob,","Grep,","Write,","WebSearch,","Agent,","AskUserQuestion,","Bash(bash","\"*/.claude/skills/brainstorm/../../hooks/yaml-helper.sh\"","resolve_config","*)"],"isInternal":false,"tokens":1336,"sizeBytes":5245},{"name":"SKILL.md","path":".claude/skills/bug-report/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/bug-report/SKILL.md","title":"bug-report","category":"anthropic-skill","format":"markdown","content":"","frontmatter":{"name":"bug-report","description":"Structured bug report from a description, or analyze code for potential bugs. Reproduction steps, severity.","argument-hint":"[description] | analyze [path-to-file] | verify [BUG-ID] | close [BUG-ID]","user-invocable":true,"allowed-tools":"Read, Glob, Grep, Write, Edit, AskUserQuestion, Bash(bash \"*/.claude/skills/bug-report/../../hooks/yaml-helper.sh\" resolve_config *)","model":"sonnet","allowedTools":["Read,","Glob,","Grep,","Write,","Edit,","AskUserQuestion,","Bash(bash","\"*/.claude/skills/bug-report/../../hooks/yaml-helper.sh\"","resolve_config","*)"]},"allowedTools":["Read,","Glob,","Grep,","Write,","Edit,","AskUserQuestion,","Bash(bash","\"*/.claude/skills/bug-report/../../hooks/yaml-helper.sh\"","resolve_config","*)"],"isInternal":false,"tokens":2661,"sizeBytes":10570},{"name":"SKILL.md","path":".claude/skills/bug-triage/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/bug-triage/SKILL.md","title":"bug-triage","category":"anthropic-skill","format":"markdown","content":"","frontmatter":{"name":"bug-triage","description":"Re-evaluate open bugs — priority vs severity, assign to sprints, surface systemic trends. Run when the count grows.","argument-hint":"[sprint | full | trend]","user-invocable":true,"allowed-tools":"Read, Glob, Grep, Write, Edit, Bash(bash \"*/.claude/skills/bug-triage/../../hooks/yaml-helper.sh\" resolve_config *)","model":"sonnet","allowedTools":["Read,","Glob,","Grep,","Write,","Edit,","Bash(bash","\"*/.claude/skills/bug-triage/../../hooks/yaml-helper.sh\"","resolve_config","*)"]},"allowedTools":["Read,","Glob,","Grep,","Write,","Edit,","Bash(bash","\"*/.claude/skills/bug-triage/../../hooks/yaml-helper.sh\"","resolve_config","*)"],"isInternal":false,"tokens":2419,"sizeBytes":9483},{"name":"SKILL.md","path":".claude/skills/changelog/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/changelog/SKILL.md","title":"changelog","category":"anthropic-skill","format":"markdown","content":"","frontmatter":{"name":"changelog","description":"Auto-generate a changelog from git commits and sprint data. Internal and player-facing versions.","argument-hint":"[version|sprint-number]","user-invocable":true,"allowed-tools":"Read, Glob, Grep, Write, Bash(bash \"*/.claude/skills/changelog/../../hooks/yaml-helper.sh\" resolve_config *), Bash(git log *), Bash(git tag --list*), Bash(git rev-parse *)","model":"sonnet","allowedTools":["Read,","Glob,","Grep,","Write,","Bash(bash","\"*/.claude/skills/changelog/../../hooks/yaml-helper.sh\"","resolve_config","*),","Bash(git","log","*),","Bash(git","tag","--list*),","Bash(git","rev-parse","*)"]},"allowedTools":["Read,","Glob,","Grep,","Write,","Bash(bash","\"*/.claude/skills/changelog/../../hooks/yaml-helper.sh\"","resolve_config","*),","Bash(git","log","*),","Bash(git","tag","--list*),","Bash(git","rev-parse","*)"],"isInternal":false,"tokens":2474,"sizeBytes":10321},{"name":"SKILL.md","path":".claude/skills/code-review/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/code-review/SKILL.md","title":"code-review","category":"anthropic-skill","format":"markdown","content":"","frontmatter":{"name":"code-review","description":"Architectural code review — coding standards, SOLID, testability, performance concerns.","argument-hint":"[path-to-file-or-directory]","user-invocable":true,"allowed-tools":"Read, Glob, Grep, Bash(git log *), Agent, AskUserQuestion, Bash(bash \"*/.claude/skills/code-review/../../hooks/yaml-helper.sh\" resolve_config *)","model":"sonnet","allowedTools":["Read,","Glob,","Grep,","Bash(git","log","*),","Agent,","AskUserQuestion,","Bash(bash","\"*/.claude/skills/code-review/../../hooks/yaml-helper.sh\"","resolve_config","*)"]},"allowedTools":["Read,","Glob,","Grep,","Bash(git","log","*),","Agent,","AskUserQuestion,","Bash(bash","\"*/.claude/skills/code-review/../../hooks/yaml-helper.sh\"","resolve_config","*)"],"isInternal":false,"tokens":3301,"sizeBytes":13882},{"name":"SKILL.md","path":".claude/skills/consistency-check/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/consistency-check/SKILL.md","title":"consistency-check","category":"anthropic-skill","format":"markdown","content":"","frontmatter":{"name":"consistency-check","description":"Scan GDDs against the entity registry for cross-document conflicts. Grep-first approach targets conflicting sections, different stats.","argument-hint":"[full | since-last-review | entity: | item:]","user-invocable":true,"allowed-tools":"Read, Glob, Grep, Write, Edit, AskUserQuestion, Bash(bash \"*/.claude/skills/consistency-check/../../hooks/yaml-helper.sh\" resolve_config *), Bash(git log *), Bash(bash .claude/scripts/registry.sh validate*)","model":"sonnet","allowedTools":["Read,","Glob,","Grep,","Write,","Edit,","AskUserQuestion,","Bash(bash","\"*/.claude/skills/consistency-check/../../hooks/yaml-helper.sh\"","resolve_config","*),","Bash(git","log","*),","Bash(bash",".claude/scripts/registry.sh","validate*)"]},"allowedTools":["Read,","Glob,","Grep,","Write,","Edit,","AskUserQuestion,","Bash(bash","\"*/.claude/skills/consistency-check/../../hooks/yaml-helper.sh\"","resolve_config","*),","Bash(git","log","*),","Bash(bash",".claude/scripts/registry.sh","validate*)"],"isInternal":false,"tokens":3803,"sizeBytes":15351},{"name":"SKILL.md","path":".claude/skills/content-audit/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/content-audit/SKILL.md","title":"content-audit","category":"anthropic-skill","format":"markdown","content":"","frontmatter":{"name":"content-audit","description":"Audit GDD content counts against what's implemented — planned vs built.","argument-hint":"[system-name | --summary | (no arg = full audit)]","user-invocable":true,"allowed-tools":"Read, Glob, Grep, Write, Bash(bash \"*/.claude/skills/content-audit/../../hooks/yaml-helper.sh\" resolve_config *)","model":"sonnet","allowedTools":["Read,","Glob,","Grep,","Write,","Bash(bash","\"*/.claude/skills/content-audit/../../hooks/yaml-helper.sh\"","resolve_config","*)"]},"allowedTools":["Read,","Glob,","Grep,","Write,","Bash(bash","\"*/.claude/skills/content-audit/../../hooks/yaml-helper.sh\"","resolve_config","*)"],"isInternal":false,"tokens":3753,"sizeBytes":14762},{"name":"0-load-context.md","path":".claude/skills/create-architecture/references/0-load-context.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/create-architecture/references/0-load-context.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":2526,"sizeBytes":10563},{"name":"1-layers.md","path":".claude/skills/create-architecture/references/1-layers.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/create-architecture/references/1-layers.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":430,"sizeBytes":2542},{"name":"2-module-ownership.md","path":".claude/skills/create-architecture/references/2-module-ownership.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/create-architecture/references/2-module-ownership.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":272,"sizeBytes":1147},{"name":"3-data-flow.md","path":".claude/skills/create-architecture/references/3-data-flow.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/create-architecture/references/3-data-flow.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":217,"sizeBytes":990},{"name":"4-api-boundaries.md","path":".claude/skills/create-architecture/references/4-api-boundaries.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/create-architecture/references/4-api-boundaries.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":218,"sizeBytes":1017},{"name":"5-adr-audit.md","path":".claude/skills/create-architecture/references/5-adr-audit.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/create-architecture/references/5-adr-audit.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":495,"sizeBytes":1923},{"name":"6-missing-adrs.md","path":".claude/skills/create-architecture/references/6-missing-adrs.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/create-architecture/references/6-missing-adrs.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":170,"sizeBytes":715},{"name":"7-write.md","path":".claude/skills/create-architecture/references/7-write.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/create-architecture/references/7-write.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":1244,"sizeBytes":4864},{"name":"8-handoff.md","path":".claude/skills/create-architecture/references/8-handoff.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/create-architecture/references/8-handoff.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":621,"sizeBytes":2466},{"name":"SKILL.md","path":".claude/skills/create-architecture/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/create-architecture/SKILL.md","title":"create-architecture","category":"anthropic-skill","format":"markdown","content":"","frontmatter":{"name":"create-architecture","description":"Author the architecture blueprint before code is written. Validates decisions against the pinned engine, flags knowledge gaps.","argument-hint":"[focus-area: full | layers | data-flow | api-boundaries | adr-audit] [--review full|lean|solo]","user-invocable":true,"allowed-tools":"Read, Glob, Grep, Write, Edit, AskUserQuestion, Agent, Bash(bash \"*/.claude/skills/create-architecture/../../hooks/yaml-helper.sh\" resolve_config *), Bash(bash .claude/scripts/registry.sh *)","model":"sonnet","allowedTools":["Read,","Glob,","Grep,","Write,","Edit,","AskUserQuestion,","Agent,","Bash(bash","\"*/.claude/skills/create-architecture/../../hooks/yaml-helper.sh\"","resolve_config","*),","Bash(bash",".claude/scripts/registry.sh","*)"]},"allowedTools":["Read,","Glob,","Grep,","Write,","Edit,","AskUserQuestion,","Agent,","Bash(bash","\"*/.claude/skills/create-architecture/../../hooks/yaml-helper.sh\"","resolve_config","*),","Bash(bash",".claude/scripts/registry.sh","*)"],"isInternal":false,"tokens":1712,"sizeBytes":7259},{"name":"SKILL.md","path":".claude/skills/create-control-manifest/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/create-control-manifest/SKILL.md","title":"create-control-manifest","category":"anthropic-skill","format":"markdown","content":"","frontmatter":{"name":"create-control-manifest","description":"Builds a short list of must-do and never-do coding rules per system from accepted ADRs. Use when the user wants programmer rules or a cheat sheet from the ADRs, or needs it regenerated after ADR changes.","argument-hint":"[update — regenerate from current ADRs] [--review full|lean|solo]","user-invocable":true,"allowed-tools":"Read, Glob, Grep, Write, Agent, AskUserQuestion, Bash(bash \"*/.claude/skills/create-control-manifest/../../hooks/yaml-helper.sh\" resolve_config *), Bash(bash .claude/scripts/adr-status.sh*), Bash(bash .claude/scripts/md-section.sh *)","model":"sonnet","allowedTools":["Read,","Glob,","Grep,","Write,","Agent,","AskUserQuestion,","Bash(bash","\"*/.claude/skills/create-control-manifest/../../hooks/yaml-helper.sh\"","resolve_config","*),","Bash(bash",".claude/scripts/adr-status.sh*),","Bash(bash",".claude/scripts/md-section.sh","*)"]},"allowedTools":["Read,","Glob,","Grep,","Write,","Agent,","AskUserQuestion,","Bash(bash","\"*/.claude/skills/create-control-manifest/../../hooks/yaml-helper.sh\"","resolve_config","*),","Bash(bash",".claude/scripts/adr-status.sh*),","Bash(bash",".claude/scripts/md-section.sh","*)"],"isInternal":false,"tokens":3349,"sizeBytes":13476},{"name":"CONTRACT.md","path":".claude/skills/create-epics/CONTRACT.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/create-epics/CONTRACT.md","title":"Create-epics Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":1906,"sizeBytes":7533},{"name":"pr-epic-gate.md","path":".claude/skills/create-epics/references/pr-epic-gate.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/create-epics/references/pr-epic-gate.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":439,"sizeBytes":1657},{"name":"SKILL.md","path":".claude/skills/create-epics/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/create-epics/SKILL.md","title":"create-epics","category":"anthropic-skill","format":"markdown","content":"","frontmatter":{"name":"create-epics","description":"Turns the GDDs and architecture into epics, one per architectural module. Use when the user wants to break the game into epics or plan the work before writing stories. Not for splitting one epic into stories.","argument-hint":"[system-name | layer: foundation|core|feature|presentation | all] [--review full|lean|solo]","user-invocable":true,"allowed-tools":"Read, Glob, Grep, Write, Edit, Agent, AskUserQuestion, Bash(bash \"*/.claude/skills/create-epics/../../hooks/yaml-helper.sh\" resolve_config *), Bash(bash .claude/scripts/gdd-structure-check.sh*), Bash(bash .claude/scripts/adr-status.sh*), Bash(bash .claude/scripts/md-section.sh *), Bash(bash .claude/scripts/write-guard.sh overwrite *)","model":"sonnet","allowedTools":["Read,","Glob,","Grep,","Write,","Edit,","Agent,","AskUserQuestion,","Bash(bash","\"*/.claude/skills/create-epics/../../hooks/yaml-helper.sh\"","resolve_config","*),","Bash(bash",".claude/scripts/gdd-structure-check.sh*),","Bash(bash",".claude/scripts/adr-status.sh*),","Bash(bash",".claude/scripts/md-section.sh","*),","Bash(bash",".claude/scripts/write-guard.sh","overwrite","*)"]},"allowedTools":["Read,","Glob,","Grep,","Write,","Edit,","Agent,","AskUserQuestion,","Bash(bash","\"*/.claude/skills/create-epics/../../hooks/yaml-helper.sh\"","resolve_config","*),","Bash(bash",".claude/scripts/gdd-structure-check.sh*),","Bash(bash",".claude/scripts/adr-status.sh*),","Bash(bash",".claude/scripts/md-section.sh","*),","Bash(bash",".claude/scripts/write-guard.sh","overwrite","*)"],"isInternal":false,"tokens":3264,"sizeBytes":12472},{"name":"CONTRACT.md","path":".claude/skills/create-stories/CONTRACT.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/create-stories/CONTRACT.md","title":"Create-stories Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":2256,"sizeBytes":9010},{"name":"qa-lead-gate.md","path":".claude/skills/create-stories/references/qa-lead-gate.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/create-stories/references/qa-lead-gate.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":823,"sizeBytes":3110},{"name":"SKILL.md","path":".claude/skills/create-stories/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/create-stories/SKILL.md","title":"create-stories","category":"anthropic-skill","format":"markdown","content":"","frontmatter":{"name":"create-stories","description":"Breaks one epic into implementable stories with acceptance criteria. Use when the user wants stories for an epic or the next batch of work to build. Not for turning the whole design into epics.","argument-hint":"[epic-slug | epic-path] [--review full|lean|solo]","user-invocable":true,"allowed-tools":"Read, Glob, Grep, Write, Edit, Agent, AskUserQuestion, Bash(bash \"*/.claude/skills/create-stories/../../hooks/yaml-helper.sh\" resolve_config *), Bash(bash .claude/scripts/adr-status.sh *), Bash(bash .claude/scripts/md-section.sh extract *), Bash(bash .claude/scripts/md-section.sh list *)","model":"sonnet","allowedTools":["Read,","Glob,","Grep,","Write,","Edit,","Agent,","AskUserQuestion,","Bash(bash","\"*/.claude/skills/create-stories/../../hooks/yaml-helper.sh\"","resolve_config","*),","Bash(bash",".claude/scripts/adr-status.sh","*),","Bash(bash",".claude/scripts/md-section.sh","extract","*),","Bash(bash",".claude/scripts/md-section.sh","list","*)"]},"allowedTools":["Read,","Glob,","Grep,","Write,","Edit,","Agent,","AskUserQuestion,","Bash(bash","\"*/.claude/skills/create-stories/../../hooks/yaml-helper.sh\"","resolve_config","*),","Bash(bash",".claude/scripts/adr-status.sh","*),","Bash(bash",".claude/scripts/md-section.sh","extract","*),","Bash(bash",".claude/scripts/md-section.sh","list","*)"],"isInternal":false,"tokens":4426,"sizeBytes":16387},{"name":"SKILL.md","path":".claude/skills/day-one-patch/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/day-one-patch/SKILL.md","title":"day-one-patch","category":"anthropic-skill","format":"markdown","content":"","frontmatter":{"name":"day-one-patch","description":"Day-one launch patch — focused fix for known issues found after gold master. Mini-sprint with QA gate and rollback.","argument-hint":"[scope: known-bugs | cert-feedback | all]","user-invocable":true,"disable-model-invocation":true,"allowed-tools":"Read, Glob, Grep, Write, Edit, Agent, AskUserQuestion","model":"sonnet","allowedTools":["Read,","Glob,","Grep,","Write,","Edit,","Agent,","AskUserQuestion"],"disableModelInvocation":true},"allowedTools":["Read,","Glob,","Grep,","Write,","Edit,","Agent,","AskUserQuestion"],"isInternal":false,"tokens":2770,"sizeBytes":11429},{"name":"SKILL.md","path":".claude/skills/design-review/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/design-review/SKILL.md","title":"design-review","category":"anthropic-skill","format":"markdown","content":"","frontmatter":{"name":"design-review","description":"Reviews one design document for completeness, internal consistency, implementability, and design standards. Before handing to programmers.","argument-hint":"[path-to-design-doc] [--review full|lean|solo]","user-invocable":true,"allowed-tools":"Read, Glob, Grep, Write, Edit, Agent, AskUserQuestion, Bash(bash \"*/.claude/skills/design-review/../../hooks/yaml-helper.sh\" resolve_config *), Bash(bash .claude/scripts/review-receipts.sh check *), Bash(bash .claude/scripts/review-receipts.sh hash *), Bash(bash .claude/scripts/gdd-structure-check.sh *), Bash(grep -E '^ - name:' design/registry/entities.yaml), Bash(grep -n -i -E *)","model":"sonnet","allowedTools":["Read,","Glob,","Grep,","Write,","Edit,","Agent,","AskUserQuestion,","Bash(bash","\"*/.claude/skills/design-review/../../hooks/yaml-helper.sh\"","resolve_config","*),","Bash(bash",".claude/scripts/review-receipts.sh","check","*),","Bash(bash",".claude/scripts/review-receipts.sh","hash","*),","Bash(bash",".claude/scripts/gdd-structure-check.sh","*),","Bash(grep","-E","'^","-","name:'","design/registry/entities.yaml),","Bash(grep","-n","-i","-E","*)"]},"allowedTools":["Read,","Glob,","Grep,","Write,","Edit,","Agent,","AskUserQuestion,","Bash(bash","\"*/.claude/skills/design-review/../../hooks/yaml-helper.sh\"","resolve_config","*),","Bash(bash",".claude/scripts/review-receipts.sh","check","*),","Bash(bash",".claude/scripts/review-receipts.sh","hash","*),","Bash(bash",".claude/scripts/gdd-structure-check.sh","*),","Bash(grep","-E","'^","-","name:'","design/registry/entities.yaml),","Bash(grep","-n","-i","-E","*)"],"isInternal":false,"tokens":6692,"sizeBytes":28052},{"name":"1-parse-arguments.md","path":".claude/skills/design-system/references/1-parse-arguments.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/design-system/references/1-parse-arguments.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":1722,"sizeBytes":7012},{"name":"2-gather-context.md","path":".claude/skills/design-system/references/2-gather-context.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/design-system/references/2-gather-context.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":3057,"sizeBytes":12289},{"name":"3-file-skeleton.md","path":".claude/skills/design-system/references/3-file-skeleton.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/design-system/references/3-file-skeleton.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":771,"sizeBytes":3169},{"name":"4-section-design.md","path":".claude/skills/design-system/references/4-section-design.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/design-system/references/4-section-design.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":6689,"sizeBytes":29624},{"name":"5-post-design.md","path":".claude/skills/design-system/references/5-post-design.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/design-system/references/5-post-design.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":2584,"sizeBytes":10229},{"name":"SKILL.md","path":".claude/skills/design-system/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/design-system/SKILL.md","title":"design-system","category":"anthropic-skill","format":"markdown","content":"","frontmatter":{"name":"design-system","description":"Section-by-section GDD authoring for one system — walks through each required section, cross-references dependencies.","argument-hint":" [--review full|lean|solo]","user-invocable":true,"allowed-tools":"Read, Glob, Grep, Write, Edit, Agent, AskUserQuestion, TaskCreate, TaskGet, TaskList, TaskUpdate, Bash(bash \"*/.claude/skills/design-system/../../hooks/yaml-helper.sh\" resolve_config *), Bash(bash .claude/scripts/registry.sh *)","model":"sonnet","allowedTools":["Read,","Glob,","Grep,","Write,","Edit,","Agent,","AskUserQuestion,","TaskCreate,","TaskGet,","TaskList,","TaskUpdate,","Bash(bash","\"*/.claude/skills/design-system/../../hooks/yaml-helper.sh\"","resolve_config","*),","Bash(bash",".claude/scripts/registry.sh","*)"]},"allowedTools":["Read,","Glob,","Grep,","Write,","Edit,","Agent,","AskUserQuestion,","TaskCreate,","TaskGet,","TaskList,","TaskUpdate,","Bash(bash","\"*/.claude/skills/design-system/../../hooks/yaml-helper.sh\"","resolve_config","*),","Bash(bash",".claude/scripts/registry.sh","*)"],"isInternal":false,"tokens":2174,"sizeBytes":8952},{"name":"CONTRACT.md","path":".claude/skills/dev-story/CONTRACT.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/dev-story/CONTRACT.md","title":"Dev-story Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":3029,"sizeBytes":13024},{"name":"engine-checks.md","path":".claude/skills/dev-story/references/engine-checks.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/dev-story/references/engine-checks.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":393,"sizeBytes":1528},{"name":"version-mismatch.md","path":".claude/skills/dev-story/references/version-mismatch.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/dev-story/references/version-mismatch.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":520,"sizeBytes":2124},{"name":"SKILL.md","path":".claude/skills/dev-story/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/dev-story/SKILL.md","title":"dev-story","category":"anthropic-skill","format":"markdown","content":"","frontmatter":{"name":"dev-story","description":"Implements one story in code with tests, following its ADRs. Use when the user says to build, implement or start working on a story. Not for checking readiness beforehand or closing the story after.","argument-hint":"[story-path]","user-invocable":true,"disable-model-invocation":true,"allowed-tools":"Read, Glob, Grep, Write, Edit, Agent, AskUserQuestion, Bash(bash \"*/.claude/skills/dev-story/../../hooks/yaml-helper.sh\" resolve_config *), Bash(bash .claude/scripts/story-facts.sh *), Bash(bash .claude/scripts/adr-status.sh *), Bash(bash .claude/scripts/md-section.sh *), Bash(bash .claude/scripts/session-state.sh *), Bash(bash .claude/scripts/review-receipts.sh hash *), Bash(godot *), Bash(mkdir -p production/qa/evidence/*)","model":"sonnet","allowedTools":["Read,","Glob,","Grep,","Write,","Edit,","Agent,","AskUserQuestion,","Bash(bash","\"*/.claude/skills/dev-story/../../hooks/yaml-helper.sh\"","resolve_config","*),","Bash(bash",".claude/scripts/story-facts.sh","*),","Bash(bash",".claude/scripts/adr-status.sh","*),","Bash(bash",".claude/scripts/md-section.sh","*),","Bash(bash",".claude/scripts/session-state.sh","*),","Bash(bash",".claude/scripts/review-receipts.sh","hash","*),","Bash(godot","*),","Bash(mkdir","-p","production/qa/evidence/*)"],"disableModelInvocation":true},"allowedTools":["Read,","Glob,","Grep,","Write,","Edit,","Agent,","AskUserQuestion,","Bash(bash","\"*/.claude/skills/dev-story/../../hooks/yaml-helper.sh\"","resolve_config","*),","Bash(bash",".claude/scripts/story-facts.sh","*),","Bash(bash",".claude/scripts/adr-status.sh","*),","Bash(bash",".claude/scripts/md-section.sh","*),","Bash(bash",".claude/scripts/session-state.sh","*),","Bash(bash",".claude/scripts/review-receipts.sh","hash","*),","Bash(godot","*),","Bash(mkdir","-p","production/qa/evidence/*)"],"isInternal":false,"tokens":4599,"sizeBytes":17781},{"name":"SKILL.md","path":".claude/skills/estimate/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/estimate/SKILL.md","title":"estimate","category":"anthropic-skill","format":"markdown","content":"","frontmatter":{"name":"estimate","description":"Estimate task effort from complexity, dependencies, velocity, risk. Structured estimate with confidence levels.","argument-hint":"[task-description]","user-invocable":true,"allowed-tools":"Read, Glob, Grep","model":"sonnet","allowedTools":["Read,","Glob,","Grep"]},"allowedTools":["Read,","Glob,","Grep"],"isInternal":false,"tokens":1382,"sizeBytes":5876},{"name":"CONTRACT.md","path":".claude/skills/gate-check/CONTRACT.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/gate-check/CONTRACT.md","title":"Gate-check Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":2718,"sizeBytes":11733},{"name":"2b-workflow-tier.md","path":".claude/skills/gate-check/references/2b-workflow-tier.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/gate-check/references/2b-workflow-tier.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":1794,"sizeBytes":7310},{"name":"3-run-gate-check.md","path":".claude/skills/gate-check/references/3-run-gate-check.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/gate-check/references/3-run-gate-check.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":2280,"sizeBytes":9391},{"name":"4-assessment.md","path":".claude/skills/gate-check/references/4-assessment.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/gate-check/references/4-assessment.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":2008,"sizeBytes":8006},{"name":"5-verdict.md","path":".claude/skills/gate-check/references/5-verdict.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/gate-check/references/5-verdict.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":2195,"sizeBytes":9027},{"name":"6-update-stage.md","path":".claude/skills/gate-check/references/6-update-stage.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/gate-check/references/6-update-stage.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":814,"sizeBytes":3260},{"name":"7-next-steps.md","path":".claude/skills/gate-check/references/7-next-steps.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/gate-check/references/7-next-steps.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":1961,"sizeBytes":8013},{"name":"gate-polish.md","path":".claude/skills/gate-check/references/gate-polish.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/gate-check/references/gate-polish.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":845,"sizeBytes":3539},{"name":"gate-pre-production.md","path":".claude/skills/gate-check/references/gate-pre-production.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/gate-check/references/gate-pre-production.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":1447,"sizeBytes":5942},{"name":"gate-production.md","path":".claude/skills/gate-check/references/gate-production.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/gate-check/references/gate-production.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":1912,"sizeBytes":7995},{"name":"gate-release.md","path":".claude/skills/gate-check/references/gate-release.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/gate-check/references/gate-release.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":843,"sizeBytes":3562},{"name":"gate-systems-design.md","path":".claude/skills/gate-check/references/gate-systems-design.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/gate-check/references/gate-systems-design.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":440,"sizeBytes":1819},{"name":"gate-technical-setup.md","path":".claude/skills/gate-check/references/gate-technical-setup.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/gate-check/references/gate-technical-setup.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":599,"sizeBytes":2473},{"name":"SKILL.md","path":".claude/skills/gate-check/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/gate-check/SKILL.md","title":"gate-check","category":"anthropic-skill","format":"markdown","content":"","frontmatter":{"name":"gate-check","description":"Ready to advance between development phases? PASS/CONCERNS/NOT ASSESSED/FAIL with blockers and required artifacts. 'Can we move to production?'","argument-hint":"[target-phase: systems-design | technical-setup | pre-production | production | polish | release] [--review full|lean|solo]","user-invocable":true,"allowed-tools":"Read, Glob, Grep, Write, Edit, Agent, AskUserQuestion, Bash(bash \"*/.claude/skills/gate-check/../../hooks/yaml-helper.sh\" resolve_config *), Bash(bash .claude/scripts/artifact-check.sh *), Bash(bash .claude/scripts/gdd-structure-check.sh*), Bash(bash .claude/scripts/adr-dep-graph.sh*), Bash(bash .claude/scripts/set-stage.sh *)","model":"opus","allowedTools":["Read,","Glob,","Grep,","Write,","Edit,","Agent,","AskUserQuestion,","Bash(bash","\"*/.claude/skills/gate-check/../../hooks/yaml-helper.sh\"","resolve_config","*),","Bash(bash",".claude/scripts/artifact-check.sh","*),","Bash(bash",".claude/scripts/gdd-structure-check.sh*),","Bash(bash",".claude/scripts/adr-dep-graph.sh*),","Bash(bash",".claude/scripts/set-stage.sh","*)"]},"allowedTools":["Read,","Glob,","Grep,","Write,","Edit,","Agent,","AskUserQuestion,","Bash(bash","\"*/.claude/skills/gate-check/../../hooks/yaml-helper.sh\"","resolve_config","*),","Bash(bash",".claude/scripts/artifact-check.sh","*),","Bash(bash",".claude/scripts/gdd-structure-check.sh*),","Bash(bash",".claude/scripts/adr-dep-graph.sh*),","Bash(bash",".claude/scripts/set-stage.sh","*)"],"isInternal":false,"tokens":2183,"sizeBytes":9194},{"name":"SKILL.md","path":".claude/skills/help/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/help/SKILL.md","title":"help","category":"anthropic-skill","format":"markdown","content":"","frontmatter":{"name":"help","description":"What should I do next? Use when stuck or you don't know what to do.","argument-hint":"[optional: what you just finished, e.g. 'finished design-review' or 'stuck on ADRs']","user-invocable":true,"allowed-tools":"Read, Glob, Grep, Bash(bash \"*/.claude/skills/help/../../hooks/yaml-helper.sh\" resolve_config *), Bash(bash \"*/.claude/skills/help/../../scripts/story-status.sh\"), Bash(bash .claude/scripts/story-status.sh*), Bash(bash .claude/scripts/artifact-check.sh *), Bash(bash \".claude/scripts/artifact-check.sh\" *), Bash(bash ./.claude/scripts/artifact-check.sh *), Bash(git log *)","model":"haiku","allowedTools":["Read,","Glob,","Grep,","Bash(bash","\"*/.claude/skills/help/../../hooks/yaml-helper.sh\"","resolve_config","*),","Bash(bash","\"*/.claude/skills/help/../../scripts/story-status.sh\"),","Bash(bash",".claude/scripts/story-status.sh*),","Bash(bash",".claude/scripts/artifact-check.sh","*),","Bash(bash","\".claude/scripts/artifact-check.sh\"","*),","Bash(bash","./.claude/scripts/artifact-check.sh","*),","Bash(git","log","*)"]},"allowedTools":["Read,","Glob,","Grep,","Bash(bash","\"*/.claude/skills/help/../../hooks/yaml-helper.sh\"","resolve_config","*),","Bash(bash","\"*/.claude/skills/help/../../scripts/story-status.sh\"),","Bash(bash",".claude/scripts/story-status.sh*),","Bash(bash",".claude/scripts/artifact-check.sh","*),","Bash(bash","\".claude/scripts/artifact-check.sh\"","*),","Bash(bash","./.claude/scripts/artifact-check.sh","*),","Bash(git","log","*)"],"isInternal":false,"tokens":4222,"sizeBytes":16642},{"name":"SKILL.md","path":".claude/skills/hotfix/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/hotfix/SKILL.md","title":"hotfix","category":"anthropic-skill","format":"markdown","content":"","frontmatter":{"name":"hotfix","description":"Emergency fix bypassing normal sprint process — hotfix branch, approvals tracked, backport verified, full audit trail.","argument-hint":"[bug-id or description]","user-invocable":true,"disable-model-invocation":true,"allowed-tools":"Read, Glob, Grep, Write, Edit, Agent, AskUserQuestion, Bash(git rev-parse *), Bash(git tag --list*), Bash(git branch --list *)","model":"sonnet","allowedTools":["Read,","Glob,","Grep,","Write,","Edit,","Agent,","AskUserQuestion,","Bash(git","rev-parse","*),","Bash(git","tag","--list*),","Bash(git","branch","--list","*)"],"disableModelInvocation":true},"allowedTools":["Read,","Glob,","Grep,","Write,","Edit,","Agent,","AskUserQuestion,","Bash(git","rev-parse","*),","Bash(git","tag","--list*),","Bash(git","branch","--list","*)"],"isInternal":false,"tokens":2956,"sizeBytes":11740},{"name":"SKILL.md","path":".claude/skills/launch-checklist/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/launch-checklist/SKILL.md","title":"launch-checklist","category":"anthropic-skill","format":"markdown","content":"","frontmatter":{"name":"launch-checklist","description":"Launch readiness across every department: code, content, store, marketing, community, infrastructure, legal, go/no-go sign-offs.","argument-hint":"[launch-date or 'dry-run']","user-invocable":true,"disable-model-invocation":true,"allowed-tools":"Read, Glob, Grep, Write, AskUserQuestion, Bash(bash \"*/.claude/skills/launch-checklist/../../hooks/yaml-helper.sh\" resolve_config *)","model":"sonnet","allowedTools":["Read,","Glob,","Grep,","Write,","AskUserQuestion,","Bash(bash","\"*/.claude/skills/launch-checklist/../../hooks/yaml-helper.sh\"","resolve_config","*)"],"disableModelInvocation":true},"allowedTools":["Read,","Glob,","Grep,","Write,","AskUserQuestion,","Bash(bash","\"*/.claude/skills/launch-checklist/../../hooks/yaml-helper.sh\"","resolve_config","*)"],"isInternal":false,"tokens":3997,"sizeBytes":16696},{"name":"SKILL.md","path":".claude/skills/localize/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/localize/SKILL.md","title":"localize","category":"anthropic-skill","format":"markdown","content":"","frontmatter":{"name":"localize","description":"Localization pipeline — find hardcoded strings, extract string tables, cultural review, VO, RTL, enforce string freeze.","argument-hint":"[scan|extract|validate|status|brief|cultural-review|vo-pipeline|rtl-check|freeze|qa]","user-invocable":true,"allowed-tools":"Read, Glob, Grep, Write, Agent, AskUserQuestion, Bash(bash \"*/.claude/skills/localize/../../hooks/yaml-helper.sh\" resolve_config *)","model":"sonnet","allowedTools":["Read,","Glob,","Grep,","Write,","Agent,","AskUserQuestion,","Bash(bash","\"*/.claude/skills/localize/../../hooks/yaml-helper.sh\"","resolve_config","*)"]},"allowedTools":["Read,","Glob,","Grep,","Write,","Agent,","AskUserQuestion,","Bash(bash","\"*/.claude/skills/localize/../../hooks/yaml-helper.sh\"","resolve_config","*)"],"isInternal":false,"tokens":4757,"sizeBytes":21111},{"name":"SKILL.md","path":".claude/skills/map-systems/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/map-systems/SKILL.md","title":"map-systems","category":"anthropic-skill","format":"markdown","content":"","frontmatter":{"name":"map-systems","description":"Decompose a concept into individual systems, map dependencies, prioritize design order, create the systems index.","argument-hint":"[next | system-name] [--review full|lean|solo]","user-invocable":true,"allowed-tools":"Read, Glob, Grep, Write, Edit, AskUserQuestion, TaskCreate, TaskGet, TaskList, TaskUpdate, Agent, Bash(bash \"*/.claude/skills/map-systems/../../hooks/yaml-helper.sh\" resolve_config *)","model":"sonnet","allowedTools":["Read,","Glob,","Grep,","Write,","Edit,","AskUserQuestion,","TaskCreate,","TaskGet,","TaskList,","TaskUpdate,","Agent,","Bash(bash","\"*/.claude/skills/map-systems/../../hooks/yaml-helper.sh\"","resolve_config","*)"]},"allowedTools":["Read,","Glob,","Grep,","Write,","Edit,","AskUserQuestion,","TaskCreate,","TaskGet,","TaskList,","TaskUpdate,","Agent,","Bash(bash","\"*/.claude/skills/map-systems/../../hooks/yaml-helper.sh\"","resolve_config","*)"],"isInternal":false,"tokens":5338,"sizeBytes":22585},{"name":"SKILL.md","path":".claude/skills/milestone-review/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/milestone-review/SKILL.md","title":"milestone-review","category":"anthropic-skill","format":"markdown","content":"","frontmatter":{"name":"milestone-review","description":"Milestone progress review — completeness, quality metrics, risk, go/no-go recommendation. At checkpoints or before a deadline.","argument-hint":"[milestone-name|current] [--review full|lean|solo]","user-invocable":true,"allowed-tools":"Read, Glob, Grep, Write, Agent, AskUserQuestion, Bash(bash \"*/.claude/skills/milestone-review/../../hooks/yaml-helper.sh\" resolve_config *)","model":"sonnet","allowedTools":["Read,","Glob,","Grep,","Write,","Agent,","AskUserQuestion,","Bash(bash","\"*/.claude/skills/milestone-review/../../hooks/yaml-helper.sh\"","resolve_config","*)"]},"allowedTools":["Read,","Glob,","Grep,","Write,","Agent,","AskUserQuestion,","Bash(bash","\"*/.claude/skills/milestone-review/../../hooks/yaml-helper.sh\"","resolve_config","*)"],"isInternal":false,"tokens":2656,"sizeBytes":11033},{"name":"SKILL.md","path":".claude/skills/onboard/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/onboard/SKILL.md","title":"onboard","category":"anthropic-skill","format":"markdown","content":"","frontmatter":{"name":"onboard","description":"Onboarding doc for a new contributor or agent — project state, conventions, priorities relevant to the specified role.","argument-hint":"[role|area]","user-invocable":true,"allowed-tools":"Read, Glob, Grep, Write, Bash(bash \"*/.claude/skills/onboard/../../hooks/yaml-helper.sh\" resolve_config *)","model":"haiku","allowedTools":["Read,","Glob,","Grep,","Write,","Bash(bash","\"*/.claude/skills/onboard/../../hooks/yaml-helper.sh\"","resolve_config","*)"]},"allowedTools":["Read,","Glob,","Grep,","Write,","Bash(bash","\"*/.claude/skills/onboard/../../hooks/yaml-helper.sh\"","resolve_config","*)"],"isInternal":false,"tokens":1295,"sizeBytes":5479},{"name":"SKILL.md","path":".claude/skills/patch-notes/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/patch-notes/SKILL.md","title":"patch-notes","category":"anthropic-skill","format":"markdown","content":"","frontmatter":{"name":"patch-notes","description":"Player-facing patch notes from git history and changelogs. Translates developer language into player communication.","argument-hint":"[version] [--style brief|detailed|full]","user-invocable":true,"allowed-tools":"Read, Glob, Grep, Write, Bash(bash \"*/.claude/skills/patch-notes/../../hooks/yaml-helper.sh\" resolve_config *), Bash(git log *)","model":"sonnet","allowedTools":["Read,","Glob,","Grep,","Write,","Bash(bash","\"*/.claude/skills/patch-notes/../../hooks/yaml-helper.sh\"","resolve_config","*),","Bash(git","log","*)"]},"allowedTools":["Read,","Glob,","Grep,","Write,","Bash(bash","\"*/.claude/skills/patch-notes/../../hooks/yaml-helper.sh\"","resolve_config","*),","Bash(git","log","*)"],"isInternal":false,"tokens":2295,"sizeBytes":9762},{"name":"SKILL.md","path":".claude/skills/perf-profile/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/perf-profile/SKILL.md","title":"perf-profile","category":"anthropic-skill","format":"markdown","content":"","frontmatter":{"name":"perf-profile","description":"Performance profiling — find bottlenecks, measure against budgets, produce ranked optimization recommendations.","argument-hint":"[system-name or 'full']","user-invocable":true,"allowed-tools":"Read, Glob, Grep, Write, Bash(bash \"*/.claude/skills/perf-profile/../../hooks/yaml-helper.sh\" resolve_config *), Bash(bash \"*/.claude/skills/perf-profile/../../hooks/yaml-helper.sh\" get_effective_yaml_key *)","model":"sonnet","allowedTools":["Read,","Glob,","Grep,","Write,","Bash(bash","\"*/.claude/skills/perf-profile/../../hooks/yaml-helper.sh\"","resolve_config","*),","Bash(bash","\"*/.claude/skills/perf-profile/../../hooks/yaml-helper.sh\"","get_effective_yaml_key","*)"]},"allowedTools":["Read,","Glob,","Grep,","Write,","Bash(bash","\"*/.claude/skills/perf-profile/../../hooks/yaml-helper.sh\"","resolve_config","*),","Bash(bash","\"*/.claude/skills/perf-profile/../../hooks/yaml-helper.sh\"","get_effective_yaml_key","*)"],"isInternal":false,"tokens":2439,"sizeBytes":10258},{"name":"SKILL.md","path":".claude/skills/playtest-report/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/playtest-report/SKILL.md","title":"playtest-report","category":"anthropic-skill","format":"markdown","content":"","frontmatter":{"name":"playtest-report","description":"Structured playtest report template, or turn existing playtest notes into structured feedback.","argument-hint":"[new|analyze path-to-notes] [--review full|lean|solo]","user-invocable":true,"allowed-tools":"Read, Glob, Grep, Write, Agent, AskUserQuestion, Bash(bash \"*/.claude/skills/playtest-report/../../hooks/yaml-helper.sh\" resolve_config *)","model":"sonnet","allowedTools":["Read,","Glob,","Grep,","Write,","Agent,","AskUserQuestion,","Bash(bash","\"*/.claude/skills/playtest-report/../../hooks/yaml-helper.sh\"","resolve_config","*)"]},"allowedTools":["Read,","Glob,","Grep,","Write,","Agent,","AskUserQuestion,","Bash(bash","\"*/.claude/skills/playtest-report/../../hooks/yaml-helper.sh\"","resolve_config","*)"],"isInternal":false,"tokens":1683,"sizeBytes":6868},{"name":"SKILL.md","path":".claude/skills/project-stage-detect/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/project-stage-detect/SKILL.md","title":"project-stage-detect","category":"anthropic-skill","format":"markdown","content":"","frontmatter":{"name":"project-stage-detect","description":"Analyze project state, detect stage, identify gaps, recommend next steps. 'Where are we in development?'","argument-hint":"[optional: role filter like 'programmer' or 'designer']","user-invocable":true,"allowed-tools":"Read, Glob, Grep, Write, Bash(bash \"*/.claude/skills/project-stage-detect/../../hooks/yaml-helper.sh\" resolve_config *), Bash(bash .claude/scripts/artifact-check.sh), Bash(bash \".claude/scripts/artifact-check.sh\"), Bash(bash ./.claude/scripts/artifact-check.sh), Bash(bash .claude/scripts/artifact-check.sh *), Bash(bash \".claude/scripts/artifact-check.sh\" *), Bash(bash ./.claude/scripts/artifact-check.sh *)","model":"haiku","allowedTools":["Read,","Glob,","Grep,","Write,","Bash(bash","\"*/.claude/skills/project-stage-detect/../../hooks/yaml-helper.sh\"","resolve_config","*),","Bash(bash",".claude/scripts/artifact-check.sh),","Bash(bash","\".claude/scripts/artifact-check.sh\"),","Bash(bash","./.claude/scripts/artifact-check.sh),","Bash(bash",".claude/scripts/artifact-check.sh","*),","Bash(bash","\".claude/scripts/artifact-check.sh\"","*),","Bash(bash","./.claude/scripts/artifact-check.sh","*)"]},"allowedTools":["Read,","Glob,","Grep,","Write,","Bash(bash","\"*/.claude/skills/project-stage-detect/../../hooks/yaml-helper.sh\"","resolve_config","*),","Bash(bash",".claude/scripts/artifact-check.sh),","Bash(bash","\".claude/scripts/artifact-check.sh\"),","Bash(bash","./.claude/scripts/artifact-check.sh),","Bash(bash",".claude/scripts/artifact-check.sh","*),","Bash(bash","\".claude/scripts/artifact-check.sh\"","*),","Bash(bash","./.claude/scripts/artifact-check.sh","*)"],"isInternal":false,"tokens":3170,"sizeBytes":13078},{"name":"SKILL.md","path":".claude/skills/propagate-design-change/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/propagate-design-change/SKILL.md","title":"propagate-design-change","category":"anthropic-skill","format":"markdown","content":"","frontmatter":{"name":"propagate-design-change","description":"Finds architecture decisions (ADRs) made stale by a changed GDD and walks through resolving each. Use when the user changed a number or rule in a GDD and asks which ADRs or architecture decisions are now out of date.","argument-hint":"[path/to/changed-gdd.md] [--review full|lean|solo]","user-invocable":true,"allowed-tools":"Read, Glob, Grep, Write, Edit, Agent, AskUserQuestion, Bash(bash \"*/.claude/skills/propagate-design-change/../../hooks/yaml-helper.sh\" resolve_config *), Bash(git diff *), Bash(git log *), Bash(bash .claude/scripts/adr-status.sh*), Bash(bash .claude/scripts/md-section.sh *)","model":"sonnet","allowedTools":["Read,","Glob,","Grep,","Write,","Edit,","Agent,","AskUserQuestion,","Bash(bash","\"*/.claude/skills/propagate-design-change/../../hooks/yaml-helper.sh\"","resolve_config","*),","Bash(git","diff","*),","Bash(git","log","*),","Bash(bash",".claude/scripts/adr-status.sh*),","Bash(bash",".claude/scripts/md-section.sh","*)"]},"allowedTools":["Read,","Glob,","Grep,","Write,","Edit,","Agent,","AskUserQuestion,","Bash(bash","\"*/.claude/skills/propagate-design-change/../../hooks/yaml-helper.sh\"","resolve_config","*),","Bash(git","diff","*),","Bash(git","log","*),","Bash(bash",".claude/scripts/adr-status.sh*),","Bash(bash",".claude/scripts/md-section.sh","*)"],"isInternal":false,"tokens":2954,"sizeBytes":11361},{"name":"1-question.md","path":".claude/skills/prototype/references/1-question.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/prototype/references/1-question.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":825,"sizeBytes":3599},{"name":"2-load-context.md","path":".claude/skills/prototype/references/2-load-context.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/prototype/references/2-load-context.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":247,"sizeBytes":961},{"name":"3-choose-path.md","path":".claude/skills/prototype/references/3-choose-path.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/prototype/references/3-choose-path.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":1917,"sizeBytes":8398},{"name":"4-plan.md","path":".claude/skills/prototype/references/4-plan.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/prototype/references/4-plan.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":286,"sizeBytes":1336},{"name":"5-implement.md","path":".claude/skills/prototype/references/5-implement.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/prototype/references/5-implement.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":994,"sizeBytes":4349},{"name":"6-debrief.md","path":".claude/skills/prototype/references/6-debrief.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/prototype/references/6-debrief.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":657,"sizeBytes":2621},{"name":"7-report.md","path":".claude/skills/prototype/references/7-report.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/prototype/references/7-report.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":250,"sizeBytes":1042},{"name":"8-cd-review.md","path":".claude/skills/prototype/references/8-cd-review.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/prototype/references/8-cd-review.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":611,"sizeBytes":2414},{"name":"9-summary.md","path":".claude/skills/prototype/references/9-summary.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/prototype/references/9-summary.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":920,"sizeBytes":3765},{"name":"spike-mode.md","path":".claude/skills/prototype/references/spike-mode.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/prototype/references/spike-mode.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":866,"sizeBytes":3705},{"name":"SKILL.md","path":".claude/skills/prototype/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/prototype/SKILL.md","title":"prototype","category":"anthropic-skill","format":"markdown","content":"","frontmatter":{"name":"prototype","description":"Concept prototype before GDDs — throwaway HTML, Engine or Paper build, PROCEED/PIVOT/KILL/NOT ASSESSED. After /brainstorm and /setup-engine.","argument-hint":"[concept-description] [--path html|engine|paper] [--review full|lean|solo] [--spike]","user-invocable":true,"allowed-tools":"Read, Glob, Grep, Write, Edit, Agent, AskUserQuestion, Bash(bash \"*/.claude/skills/prototype/../../hooks/yaml-helper.sh\" resolve_config *)","model":"sonnet","allowedTools":["Read,","Glob,","Grep,","Write,","Edit,","Agent,","AskUserQuestion,","Bash(bash","\"*/.claude/skills/prototype/../../hooks/yaml-helper.sh\"","resolve_config","*)"]},"allowedTools":["Read,","Glob,","Grep,","Write,","Edit,","Agent,","AskUserQuestion,","Bash(bash","\"*/.claude/skills/prototype/../../hooks/yaml-helper.sh\"","resolve_config","*)"],"isInternal":false,"tokens":1261,"sizeBytes":5397},{"name":"SKILL.md","path":".claude/skills/qa-plan/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/qa-plan/SKILL.md","title":"qa-plan","category":"anthropic-skill","format":"markdown","content":"","frontmatter":{"name":"qa-plan","description":"QA test plan for a sprint — classifies stories by Logic/Integration/Visual/UI, covers automated tests, manual cases, smoke scope.","argument-hint":"[sprint | feature: system-name | story: path]","user-invocable":true,"allowed-tools":"Read, Glob, Grep, Write, Edit, AskUserQuestion, Bash(bash \"*/.claude/skills/qa-plan/../../hooks/yaml-helper.sh\" resolve_config *)","model":"sonnet","allowedTools":["Read,","Glob,","Grep,","Write,","Edit,","AskUserQuestion,","Bash(bash","\"*/.claude/skills/qa-plan/../../hooks/yaml-helper.sh\"","resolve_config","*)"]},"allowedTools":["Read,","Glob,","Grep,","Write,","Edit,","AskUserQuestion,","Bash(bash","\"*/.claude/skills/qa-plan/../../hooks/yaml-helper.sh\"","resolve_config","*)"],"isInternal":false,"tokens":4124,"sizeBytes":17505},{"name":"SKILL.md","path":".claude/skills/quick-design/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/quick-design/SKILL.md","title":"quick-design","category":"anthropic-skill","format":"markdown","content":"","frontmatter":{"name":"quick-design","description":"Lightweight spec for small changes — tuning adjustments, minor mechanics. Embeds directly into stories; skips full GDD.","argument-hint":"[brief description of the change]","user-invocable":true,"allowed-tools":"Read, Glob, Grep, Write, Edit, AskUserQuestion, Bash(bash \"*/.claude/skills/quick-design/../../hooks/yaml-helper.sh\" resolve_config *)","model":"sonnet","allowedTools":["Read,","Glob,","Grep,","Write,","Edit,","AskUserQuestion,","Bash(bash","\"*/.claude/skills/quick-design/../../hooks/yaml-helper.sh\"","resolve_config","*)"]},"allowedTools":["Read,","Glob,","Grep,","Write,","Edit,","AskUserQuestion,","Bash(bash","\"*/.claude/skills/quick-design/../../hooks/yaml-helper.sh\"","resolve_config","*)"],"isInternal":false,"tokens":2828,"sizeBytes":11811},{"name":"SKILL.md","path":".claude/skills/regression-suite/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/regression-suite/SKILL.md","title":"regression-suite","category":"anthropic-skill","format":"markdown","content":"","frontmatter":{"name":"regression-suite","description":"Map test coverage to GDD critical paths, find fixed bugs lacking regression tests, flag drift from new features.","argument-hint":"[update | audit | report]","user-invocable":true,"allowed-tools":"Read, Glob, Grep, Write, Edit, AskUserQuestion, Bash(bash \"*/.claude/skills/regression-suite/../../hooks/yaml-helper.sh\" resolve_config *)","model":"sonnet","allowedTools":["Read,","Glob,","Grep,","Write,","Edit,","AskUserQuestion,","Bash(bash","\"*/.claude/skills/regression-suite/../../hooks/yaml-helper.sh\"","resolve_config","*)"]},"allowedTools":["Read,","Glob,","Grep,","Write,","Edit,","AskUserQuestion,","Bash(bash","\"*/.claude/skills/regression-suite/../../hooks/yaml-helper.sh\"","resolve_config","*)"],"isInternal":false,"tokens":3436,"sizeBytes":14092},{"name":"SKILL.md","path":".claude/skills/release-checklist/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/release-checklist/SKILL.md","title":"release-checklist","category":"anthropic-skill","format":"markdown","content":"","frontmatter":{"name":"release-checklist","description":"Pre-release checklist — build verification, certification requirements, store metadata, launch readiness.","argument-hint":"[platform: pc|console|mobile|all]","user-invocable":true,"allowed-tools":"Read, Glob, Grep, Write, Bash(bash \"*/.claude/skills/release-checklist/../../hooks/yaml-helper.sh\" resolve_config *)","model":"sonnet","allowedTools":["Read,","Glob,","Grep,","Write,","Bash(bash","\"*/.claude/skills/release-checklist/../../hooks/yaml-helper.sh\"","resolve_config","*)"]},"allowedTools":["Read,","Glob,","Grep,","Write,","Bash(bash","\"*/.claude/skills/release-checklist/../../hooks/yaml-helper.sh\"","resolve_config","*)"],"isInternal":false,"tokens":3661,"sizeBytes":14903},{"name":"SKILL.md","path":".claude/skills/retrospective/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/retrospective/SKILL.md","title":"retrospective","category":"anthropic-skill","format":"markdown","content":"","frontmatter":{"name":"retrospective","description":"Sprint or milestone retrospective from completed work, velocity, blockers. Actionable insights for the next iteration.","argument-hint":"[sprint-N|milestone-name]","user-invocable":true,"allowed-tools":"Read, Glob, Grep, Write, AskUserQuestion, Bash(bash \"*/.claude/skills/retrospective/../../hooks/yaml-helper.sh\" resolve_config *), Bash(git log *)","model":"sonnet","allowedTools":["Read,","Glob,","Grep,","Write,","AskUserQuestion,","Bash(bash","\"*/.claude/skills/retrospective/../../hooks/yaml-helper.sh\"","resolve_config","*),","Bash(git","log","*)"]},"allowedTools":["Read,","Glob,","Grep,","Write,","AskUserQuestion,","Bash(bash","\"*/.claude/skills/retrospective/../../hooks/yaml-helper.sh\"","resolve_config","*),","Bash(git","log","*)"],"isInternal":false,"tokens":3073,"sizeBytes":12408},{"name":"SKILL.md","path":".claude/skills/reverse-document/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/reverse-document/SKILL.md","title":"reverse-document","category":"anthropic-skill","format":"markdown","content":"","frontmatter":{"name":"reverse-document","description":"Generate missing design or architecture docs from existing implementation — works backwards from code and prototypes.","argument-hint":" (e.g., 'design src/gameplay/combat' or 'architecture Assets/Scripts/Core')","user-invocable":true,"allowed-tools":"Read, Glob, Grep, Write, Edit, Bash(bash \"*/.claude/skills/reverse-document/../../hooks/yaml-helper.sh\" resolve_config *)","model":"sonnet","allowedTools":["Read,","Glob,","Grep,","Write,","Edit,","Bash(bash","\"*/.claude/skills/reverse-document/../../hooks/yaml-helper.sh\"","resolve_config","*)"]},"allowedTools":["Read,","Glob,","Grep,","Write,","Edit,","Bash(bash","\"*/.claude/skills/reverse-document/../../hooks/yaml-helper.sh\"","resolve_config","*)"],"isInternal":false,"tokens":3760,"sizeBytes":15781},{"name":"1-load.md","path":".claude/skills/review-all-gdds/references/1-load.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/review-all-gdds/references/1-load.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":1295,"sizeBytes":5041},{"name":"2-consistency.md","path":".claude/skills/review-all-gdds/references/2-consistency.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/review-all-gdds/references/2-consistency.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":1625,"sizeBytes":6503},{"name":"3-design-holism.md","path":".claude/skills/review-all-gdds/references/3-design-holism.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/review-all-gdds/references/3-design-holism.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":1780,"sizeBytes":7695},{"name":"4-scenarios.md","path":".claude/skills/review-all-gdds/references/4-scenarios.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/review-all-gdds/references/4-scenarios.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":945,"sizeBytes":4485},{"name":"5-report.md","path":".claude/skills/review-all-gdds/references/5-report.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/review-all-gdds/references/5-report.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":1155,"sizeBytes":4662},{"name":"6-write.md","path":".claude/skills/review-all-gdds/references/6-write.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/review-all-gdds/references/6-write.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":653,"sizeBytes":2487},{"name":"7-handoff.md","path":".claude/skills/review-all-gdds/references/7-handoff.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/review-all-gdds/references/7-handoff.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":501,"sizeBytes":2050},{"name":"SKILL.md","path":".claude/skills/review-all-gdds/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/review-all-gdds/SKILL.md","title":"review-all-gdds","category":"anthropic-skill","format":"markdown","content":"","frontmatter":{"name":"review-all-gdds","description":"Holistic cross-GDD review — contradictions between systems, dominant strategies, economic imbalance, cognitive overload, pillar drift.","argument-hint":"[focus: full | consistency | design-theory | since-last-review]","user-invocable":true,"allowed-tools":"Read, Glob, Grep, Write, AskUserQuestion, Agent, Bash(bash \"*/.claude/skills/review-all-gdds/../../hooks/yaml-helper.sh\" resolve_config *), Bash(bash .claude/scripts/review-scope.sh*)","model":"opus","allowedTools":["Read,","Glob,","Grep,","Write,","AskUserQuestion,","Agent,","Bash(bash","\"*/.claude/skills/review-all-gdds/../../hooks/yaml-helper.sh\"","resolve_config","*),","Bash(bash",".claude/scripts/review-scope.sh*)"]},"allowedTools":["Read,","Glob,","Grep,","Write,","AskUserQuestion,","Agent,","Bash(bash","\"*/.claude/skills/review-all-gdds/../../hooks/yaml-helper.sh\"","resolve_config","*),","Bash(bash",".claude/scripts/review-scope.sh*)"],"isInternal":false,"tokens":1769,"sizeBytes":7455},{"name":"SKILL.md","path":".claude/skills/scope-check/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/scope-check/SKILL.md","title":"scope-check","category":"anthropic-skill","format":"markdown","content":"","frontmatter":{"name":"scope-check","description":"Scope creep check — current scope versus the original plan. Flags additions, quantifies bloat, recommends cuts. 'Any scope creep?'","argument-hint":"[feature-name or sprint-N]","user-invocable":true,"allowed-tools":"Read, Glob, Grep, Bash(git log *)","model":"haiku","allowedTools":["Read,","Glob,","Grep,","Bash(git","log","*)"]},"allowedTools":["Read,","Glob,","Grep,","Bash(git","log","*)"],"isInternal":false,"tokens":1689,"sizeBytes":6839},{"name":"SKILL.md","path":".claude/skills/security-audit/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/security-audit/SKILL.md","title":"security-audit","category":"anthropic-skill","format":"markdown","content":"","frontmatter":{"name":"security-audit","description":"Security audit — save tampering, cheat vectors, network exploits, data exposure, input validation. Before public or multiplayer release.","argument-hint":"[full | network | save | input | quick]","user-invocable":true,"allowed-tools":"Read, Glob, Grep, Write, Agent, Bash(bash \"*/.claude/skills/security-audit/../../hooks/yaml-helper.sh\" resolve_config *)","model":"sonnet","allowedTools":["Read,","Glob,","Grep,","Write,","Agent,","Bash(bash","\"*/.claude/skills/security-audit/../../hooks/yaml-helper.sh\"","resolve_config","*)"]},"allowedTools":["Read,","Glob,","Grep,","Write,","Agent,","Bash(bash","\"*/.claude/skills/security-audit/../../hooks/yaml-helper.sh\"","resolve_config","*)"],"isInternal":false,"tokens":5302,"sizeBytes":22328},{"name":"SKILL.md","path":".claude/skills/settings/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/settings/SKILL.md","title":"settings","category":"anthropic-skill","format":"markdown","content":"","frontmatter":{"name":"settings","description":"View or change project config — effective merged values, or set locally in project.local.yaml.","argument-hint":"[key | key=value | --local key=value]","user-invocable":true,"allowed-tools":"Read, Glob, Grep, Write, Edit, AskUserQuestion, Bash(bash \"*/.claude/skills/settings/../../hooks/yaml-helper.sh\" resolve_setting *), Bash(bash \"*/.claude/skills/settings/../../hooks/yaml-helper.sh\" get_yaml_key *), Bash(bash \"*/.claude/skills/settings/../../hooks/yaml-helper.sh\" validate_yaml_enum *), Bash(bash \"*/.claude/skills/settings/../../hooks/yaml-helper.sh\" validate_enum_value *), Bash(bash \"*/.claude/skills/settings/../../hooks/yaml-helper.sh\" is_locally_overridable *), Bash(bash .claude/scripts/config-set.sh *), Bash(grep -B14 '^>","model":"sonnet","allowedTools":["Read,","Glob,","Grep,","Write,","Edit,","AskUserQuestion,","Bash(bash","\"*/.claude/skills/settings/../../hooks/yaml-helper.sh\"","resolve_setting","*),","Bash(bash","\"*/.claude/skills/settings/../../hooks/yaml-helper.sh\"","get_yaml_key","*),","Bash(bash","\"*/.claude/skills/settings/../../hooks/yaml-helper.sh\"","validate_yaml_enum","*),","Bash(bash","\"*/.claude/skills/settings/../../hooks/yaml-helper.sh\"","validate_enum_value","*),","Bash(bash","\"*/.claude/skills/settings/../../hooks/yaml-helper.sh\"","is_locally_overridable","*),","Bash(bash",".claude/scripts/config-set.sh","*),","Bash(grep","-B14","'^>"]},"allowedTools":["Read,","Glob,","Grep,","Write,","Edit,","AskUserQuestion,","Bash(bash","\"*/.claude/skills/settings/../../hooks/yaml-helper.sh\"","resolve_setting","*),","Bash(bash","\"*/.claude/skills/settings/../../hooks/yaml-helper.sh\"","get_yaml_key","*),","Bash(bash","\"*/.claude/skills/settings/../../hooks/yaml-helper.sh\"","validate_yaml_enum","*),","Bash(bash","\"*/.claude/skills/settings/../../hooks/yaml-helper.sh\"","validate_enum_value","*),","Bash(bash","\"*/.claude/skills/settings/../../hooks/yaml-helper.sh\"","is_locally_overridable","*),","Bash(bash",".claude/scripts/config-set.sh","*),","Bash(grep","-B14","'^>"],"isInternal":false,"tokens":5464,"sizeBytes":21500},{"name":"11-upgrade.md","path":".claude/skills/setup-engine/references/11-upgrade.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/setup-engine/references/11-upgrade.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":1032,"sizeBytes":4523},{"name":"12-output-summary.md","path":".claude/skills/setup-engine/references/12-output-summary.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/setup-engine/references/12-output-summary.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":459,"sizeBytes":1741},{"name":"2-guided-mode.md","path":".claude/skills/setup-engine/references/2-guided-mode.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/setup-engine/references/2-guided-mode.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":1965,"sizeBytes":8595},{"name":"3-version.md","path":".claude/skills/setup-engine/references/3-version.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/setup-engine/references/3-version.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":642,"sizeBytes":2574},{"name":"4-claude-md-stack.md","path":".claude/skills/setup-engine/references/4-claude-md-stack.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/setup-engine/references/4-claude-md-stack.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":787,"sizeBytes":3283},{"name":"5-technical-preferences.md","path":".claude/skills/setup-engine/references/5-technical-preferences.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/setup-engine/references/5-technical-preferences.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":2018,"sizeBytes":8691},{"name":"5.5-project-yaml.md","path":".claude/skills/setup-engine/references/5.5-project-yaml.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/setup-engine/references/5.5-project-yaml.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":7955,"sizeBytes":29275},{"name":"6-knowledge-gap.md","path":".claude/skills/setup-engine/references/6-knowledge-gap.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/setup-engine/references/6-knowledge-gap.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":410,"sizeBytes":1736},{"name":"7-reference-docs.md","path":".claude/skills/setup-engine/references/7-reference-docs.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/setup-engine/references/7-reference-docs.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":1410,"sizeBytes":5985},{"name":"7.5-scaffold.md","path":".claude/skills/setup-engine/references/7.5-scaffold.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/setup-engine/references/7.5-scaffold.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":979,"sizeBytes":3980},{"name":"8-verify.md","path":".claude/skills/setup-engine/references/8-verify.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/setup-engine/references/8-verify.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":670,"sizeBytes":2717},{"name":"godot-language-config.md","path":".claude/skills/setup-engine/references/godot-language-config.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/setup-engine/references/godot-language-config.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":1783,"sizeBytes":7516},{"name":"SKILL.md","path":".claude/skills/setup-engine/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/setup-engine/SKILL.md","title":"setup-engine","category":"anthropic-skill","format":"markdown","content":"","frontmatter":{"name":"setup-engine","description":"Configure engine and version. Pins it in CLAUDE.md; WebSearch fills reference docs when the version is beyond LLM training data.","argument-hint":"[engine] | [engine version] | refresh | upgrade [old-version] [new-version] | no args for guided selection","user-invocable":true,"allowed-tools":"Read, Glob, Grep, Write, Edit, WebSearch, WebFetch, Agent, AskUserQuestion, Bash(bash \"*/.claude/skills/setup-engine/../../hooks/yaml-helper.sh\" resolve_config *), Bash(godot --version), Bash(godot --headless --path . --import), Bash(command -v godot), Bash(uname -s), Bash(bash .claude/scripts/project-coherence.sh*)","model":"sonnet","allowedTools":["Read,","Glob,","Grep,","Write,","Edit,","WebSearch,","WebFetch,","Agent,","AskUserQuestion,","Bash(bash","\"*/.claude/skills/setup-engine/../../hooks/yaml-helper.sh\"","resolve_config","*),","Bash(godot","--version),","Bash(godot","--headless","--path",".","--import),","Bash(command","-v","godot),","Bash(uname","-s),","Bash(bash",".claude/scripts/project-coherence.sh*)"]},"allowedTools":["Read,","Glob,","Grep,","Write,","Edit,","WebSearch,","WebFetch,","Agent,","AskUserQuestion,","Bash(bash","\"*/.claude/skills/setup-engine/../../hooks/yaml-helper.sh\"","resolve_config","*),","Bash(godot","--version),","Bash(godot","--headless","--path",".","--import),","Bash(command","-v","godot),","Bash(uname","-s),","Bash(bash",".claude/scripts/project-coherence.sh*)"],"isInternal":false,"tokens":1730,"sizeBytes":7205},{"name":"SKILL.md","path":".claude/skills/skill-improve/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/skill-improve/SKILL.md","title":"skill-improve","category":"anthropic-skill","format":"markdown","content":"","frontmatter":{"name":"skill-improve","description":"Improve a skill via a test-fix-retest loop — static checks, targeted fixes, keep or revert on score change.","argument-hint":"[skill-name]","user-invocable":true,"allowed-tools":"Read, Glob, Grep, Write, Bash(bash \"*/.claude/skills/skill-improve/../../hooks/yaml-helper.sh\" resolve_config *)","model":"sonnet","allowedTools":["Read,","Glob,","Grep,","Write,","Bash(bash","\"*/.claude/skills/skill-improve/../../hooks/yaml-helper.sh\"","resolve_config","*)"]},"allowedTools":["Read,","Glob,","Grep,","Write,","Bash(bash","\"*/.claude/skills/skill-improve/../../hooks/yaml-helper.sh\"","resolve_config","*)"],"isInternal":false,"tokens":1866,"sizeBytes":7352},{"name":"SKILL.md","path":".claude/skills/skill-test/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/skill-test/SKILL.md","title":"skill-test","category":"anthropic-skill","format":"markdown","content":"","frontmatter":{"name":"skill-test","description":"Validate skill files for structural compliance and behavioral correctness. Four modes: static linter, spec, category rubric, audit.","argument-hint":"static [skill-name | all] | spec [skill-or-agent-name] | category [skill-or-agent-name | all] | audit","user-invocable":true,"allowed-tools":"Read, Glob, Grep, Write, Bash(bash \"*/.claude/skills/skill-test/../../hooks/yaml-helper.sh\" resolve_config *), Bash(bash .claude/scripts/agent-check.sh*), Bash(bash .claude/scripts/compat-inventory.sh*)","model":"sonnet","allowedTools":["Read,","Glob,","Grep,","Write,","Bash(bash","\"*/.claude/skills/skill-test/../../hooks/yaml-helper.sh\"","resolve_config","*),","Bash(bash",".claude/scripts/agent-check.sh*),","Bash(bash",".claude/scripts/compat-inventory.sh*)"]},"allowedTools":["Read,","Glob,","Grep,","Write,","Bash(bash","\"*/.claude/skills/skill-test/../../hooks/yaml-helper.sh\"","resolve_config","*),","Bash(bash",".claude/scripts/agent-check.sh*),","Bash(bash",".claude/scripts/compat-inventory.sh*)"],"isInternal":false,"tokens":7235,"sizeBytes":28769},{"name":"1-detect-setup.md","path":".claude/skills/smoke-check/references/1-detect-setup.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/smoke-check/references/1-detect-setup.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":1435,"sizeBytes":5664},{"name":"2-run-tests.md","path":".claude/skills/smoke-check/references/2-run-tests.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/smoke-check/references/2-run-tests.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":3165,"sizeBytes":11804},{"name":"3-coverage.md","path":".claude/skills/smoke-check/references/3-coverage.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/smoke-check/references/3-coverage.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":399,"sizeBytes":1656},{"name":"4-manual-checks.md","path":".claude/skills/smoke-check/references/4-manual-checks.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/smoke-check/references/4-manual-checks.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":1317,"sizeBytes":5769},{"name":"5-report.md","path":".claude/skills/smoke-check/references/5-report.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/smoke-check/references/5-report.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":1757,"sizeBytes":6789},{"name":"6-write-gate.md","path":".claude/skills/smoke-check/references/6-write-gate.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/smoke-check/references/6-write-gate.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":1113,"sizeBytes":4618},{"name":"SKILL.md","path":".claude/skills/smoke-check/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/smoke-check/SKILL.md","title":"smoke-check","category":"anthropic-skill","format":"markdown","content":"","frontmatter":{"name":"smoke-check","description":"Critical-path smoke gate before QA hand-off — runs the automated suite. A failed check means the build is not QA-ready.","argument-hint":"[sprint | quick | --platform pc|console|mobile|all]","user-invocable":true,"allowed-tools":"Read, Glob, Grep, Write, AskUserQuestion, Bash(bash \"*/.claude/skills/smoke-check/../../hooks/yaml-helper.sh\" resolve_config *), Bash(bash .claude/scripts/project-coherence.sh*), Bash(command -v *), Bash(uname -s), Bash(godot --headless --path . --import), Bash(timeout 900 godot --headless *), Bash(timeout 1800 godot --headless *), Bash(grep -q 'com.unity.test-framework' Packages/manifest.json), Bash(echo present), Bash(echo ABSENT)","model":"sonnet","allowedTools":["Read,","Glob,","Grep,","Write,","AskUserQuestion,","Bash(bash","\"*/.claude/skills/smoke-check/../../hooks/yaml-helper.sh\"","resolve_config","*),","Bash(bash",".claude/scripts/project-coherence.sh*),","Bash(command","-v","*),","Bash(uname","-s),","Bash(godot","--headless","--path",".","--import),","Bash(timeout","900","godot","--headless","*),","Bash(timeout","1800","godot","--headless","*),","Bash(grep","-q","'com.unity.test-framework'","Packages/manifest.json),","Bash(echo","present),","Bash(echo","ABSENT)"]},"allowedTools":["Read,","Glob,","Grep,","Write,","AskUserQuestion,","Bash(bash","\"*/.claude/skills/smoke-check/../../hooks/yaml-helper.sh\"","resolve_config","*),","Bash(bash",".claude/scripts/project-coherence.sh*),","Bash(command","-v","*),","Bash(uname","-s),","Bash(godot","--headless","--path",".","--import),","Bash(timeout","900","godot","--headless","*),","Bash(timeout","1800","godot","--headless","*),","Bash(grep","-q","'com.unity.test-framework'","Packages/manifest.json),","Bash(echo","present),","Bash(echo","ABSENT)"],"isInternal":false,"tokens":1253,"sizeBytes":5161},{"name":"SKILL.md","path":".claude/skills/soak-test/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/soak-test/SKILL.md","title":"soak-test","category":"anthropic-skill","format":"markdown","content":"","frontmatter":{"name":"soak-test","description":"Soak test protocol for extended play — what to observe and log for slow leaks, fatigue, late-appearing edge cases.","argument-hint":"[duration: 30m | 1h | 2h | 4h] [focus: memory | stability | balance | all]","user-invocable":true,"allowed-tools":"Read, Glob, Grep, Write, Bash(bash \"*/.claude/skills/soak-test/../../hooks/yaml-helper.sh\" resolve_config *)","model":"sonnet","allowedTools":["Read,","Glob,","Grep,","Write,","Bash(bash","\"*/.claude/skills/soak-test/../../hooks/yaml-helper.sh\"","resolve_config","*)"]},"allowedTools":["Read,","Glob,","Grep,","Write,","Bash(bash","\"*/.claude/skills/soak-test/../../hooks/yaml-helper.sh\"","resolve_config","*)"],"isInternal":false,"tokens":3203,"sizeBytes":12935},{"name":"SKILL.md","path":".claude/skills/sprint-plan/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/sprint-plan/SKILL.md","title":"sprint-plan","category":"anthropic-skill","format":"markdown","content":"","frontmatter":{"name":"sprint-plan","description":"New or updated sprint plan from the current milestone, completed work, and available capacity.","argument-hint":"[new|update|status] [--review full|lean|solo]","user-invocable":true,"allowed-tools":"Read, Glob, Grep, Write, Edit, Agent, AskUserQuestion, Bash(bash \"*/.claude/skills/sprint-plan/../../hooks/yaml-helper.sh\" resolve_config *), Bash(ls production/sprints/*)","model":"sonnet","allowedTools":["Read,","Glob,","Grep,","Write,","Edit,","Agent,","AskUserQuestion,","Bash(bash","\"*/.claude/skills/sprint-plan/../../hooks/yaml-helper.sh\"","resolve_config","*),","Bash(ls","production/sprints/*)"]},"allowedTools":["Read,","Glob,","Grep,","Write,","Edit,","Agent,","AskUserQuestion,","Bash(bash","\"*/.claude/skills/sprint-plan/../../hooks/yaml-helper.sh\"","resolve_config","*),","Bash(ls","production/sprints/*)"],"isInternal":false,"tokens":4878,"sizeBytes":19611},{"name":"SKILL.md","path":".claude/skills/sprint-status/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/sprint-status/SKILL.md","title":"sprint-status","category":"anthropic-skill","format":"markdown","content":"","frontmatter":{"name":"sprint-status","description":"Fast, concise sprint snapshot — burndown and emerging risks for situational awareness. 'How is the sprint going?'","argument-hint":"[sprint-number or blank for current]","user-invocable":true,"allowed-tools":"Read, Glob, Grep, Bash(bash \"*/.claude/skills/sprint-status/../../hooks/yaml-helper.sh\" resolve_config *), Bash(bash \"*/.claude/skills/sprint-status/../../scripts/story-status.sh\"), Bash(bash .claude/scripts/story-status.sh*)","model":"haiku","allowedTools":["Read,","Glob,","Grep,","Bash(bash","\"*/.claude/skills/sprint-status/../../hooks/yaml-helper.sh\"","resolve_config","*),","Bash(bash","\"*/.claude/skills/sprint-status/../../scripts/story-status.sh\"),","Bash(bash",".claude/scripts/story-status.sh*)"]},"allowedTools":["Read,","Glob,","Grep,","Bash(bash","\"*/.claude/skills/sprint-status/../../hooks/yaml-helper.sh\"","resolve_config","*),","Bash(bash","\"*/.claude/skills/sprint-status/../../scripts/story-status.sh\"),","Bash(bash",".claude/scripts/story-status.sh*)"],"isInternal":false,"tokens":2998,"sizeBytes":12066},{"name":"SKILL.md","path":".claude/skills/start/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/start/SKILL.md","title":"start","category":"anthropic-skill","format":"markdown","content":"","frontmatter":{"name":"start","description":"Guides a first-time user through onboarding and picks the right workflow. Use when the user is new, just cloned or installed the studio, has no idea or engine yet, asks where to begin, or wants to bring in an existing game.","argument-hint":"[no arguments]","user-invocable":true,"allowed-tools":"Read, Glob, Grep, AskUserQuestion, Bash(bash .claude/scripts/project-state.sh*), Bash(bash .claude/scripts/set-stage.sh *), Bash(bash .claude/scripts/config-set.sh *)","model":"sonnet","allowedTools":["Read,","Glob,","Grep,","AskUserQuestion,","Bash(bash",".claude/scripts/project-state.sh*),","Bash(bash",".claude/scripts/set-stage.sh","*),","Bash(bash",".claude/scripts/config-set.sh","*)"]},"allowedTools":["Read,","Glob,","Grep,","AskUserQuestion,","Bash(bash",".claude/scripts/project-state.sh*),","Bash(bash",".claude/scripts/set-stage.sh","*),","Bash(bash",".claude/scripts/config-set.sh","*)"],"isInternal":false,"tokens":3144,"sizeBytes":12068},{"name":"CONTRACT.md","path":".claude/skills/story-done/CONTRACT.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/story-done/CONTRACT.md","title":"Story-done Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":2739,"sizeBytes":11877},{"name":"review-gates.md","path":".claude/skills/story-done/references/review-gates.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/story-done/references/review-gates.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":664,"sizeBytes":2464},{"name":"sprint-next.md","path":".claude/skills/story-done/references/sprint-next.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/story-done/references/sprint-next.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":369,"sizeBytes":1492},{"name":"tech-debt-row.md","path":".claude/skills/story-done/references/tech-debt-row.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/story-done/references/tech-debt-row.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":350,"sizeBytes":1329},{"name":"SKILL.md","path":".claude/skills/story-done/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/story-done/SKILL.md","title":"story-done","category":"anthropic-skill","format":"markdown","content":"","frontmatter":{"name":"story-done","description":"Closes a finished story: verifies each acceptance criterion, checks for design or ADR deviations and updates its status. Use when the user says a story is done, finished or ready to close.","argument-hint":"[story-file-path] [--review full|lean|solo]","user-invocable":true,"disable-model-invocation":true,"allowed-tools":"Read, Glob, Grep, Write, Edit, AskUserQuestion, Agent, Bash(bash \"*/.claude/skills/story-done/../../hooks/yaml-helper.sh\" resolve_config *), Bash(bash .claude/scripts/story-facts.sh *), Bash(bash .claude/scripts/story-status.sh*), Bash(bash .claude/scripts/adr-status.sh *), Bash(bash .claude/scripts/md-section.sh *), Bash(bash .claude/scripts/review-receipts.sh check *), Bash(bash .claude/scripts/session-state.sh *), Bash(git status --porcelain*)","model":"sonnet","allowedTools":["Read,","Glob,","Grep,","Write,","Edit,","AskUserQuestion,","Agent,","Bash(bash","\"*/.claude/skills/story-done/../../hooks/yaml-helper.sh\"","resolve_config","*),","Bash(bash",".claude/scripts/story-facts.sh","*),","Bash(bash",".claude/scripts/story-status.sh*),","Bash(bash",".claude/scripts/adr-status.sh","*),","Bash(bash",".claude/scripts/md-section.sh","*),","Bash(bash",".claude/scripts/review-receipts.sh","check","*),","Bash(bash",".claude/scripts/session-state.sh","*),","Bash(git","status","--porcelain*)"],"disableModelInvocation":true},"allowedTools":["Read,","Glob,","Grep,","Write,","Edit,","AskUserQuestion,","Agent,","Bash(bash","\"*/.claude/skills/story-done/../../hooks/yaml-helper.sh\"","resolve_config","*),","Bash(bash",".claude/scripts/story-facts.sh","*),","Bash(bash",".claude/scripts/story-status.sh*),","Bash(bash",".claude/scripts/adr-status.sh","*),","Bash(bash",".claude/scripts/md-section.sh","*),","Bash(bash",".claude/scripts/review-receipts.sh","check","*),","Bash(bash",".claude/scripts/session-state.sh","*),","Bash(git","status","--porcelain*)"],"isInternal":false,"tokens":4704,"sizeBytes":18015},{"name":"CONTRACT.md","path":".claude/skills/story-readiness/CONTRACT.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/story-readiness/CONTRACT.md","title":"Story-readiness Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":1586,"sizeBytes":6616},{"name":"qa-lead-gate.md","path":".claude/skills/story-readiness/references/qa-lead-gate.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/story-readiness/references/qa-lead-gate.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":433,"sizeBytes":1643},{"name":"SKILL.md","path":".claude/skills/story-readiness/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/story-readiness/SKILL.md","title":"story-readiness","category":"anthropic-skill","format":"markdown","content":"","frontmatter":{"name":"story-readiness","description":"Checks whether a story is ready to implement: clear acceptance criteria, no open questions, valid ADR and dependencies. Use when the user asks if a story, or the sprint's stories, are ready to start or build.","argument-hint":"[story-file-path or 'all' or 'sprint'] [--review full|lean|solo]","user-invocable":true,"allowed-tools":"Read, Glob, Grep, AskUserQuestion, Agent, Bash(bash \"*/.claude/skills/story-readiness/../../hooks/yaml-helper.sh\" resolve_config *), Bash(bash .claude/scripts/story-facts.sh *), Bash(bash .claude/scripts/adr-status.sh *)","model":"sonnet","allowedTools":["Read,","Glob,","Grep,","AskUserQuestion,","Agent,","Bash(bash","\"*/.claude/skills/story-readiness/../../hooks/yaml-helper.sh\"","resolve_config","*),","Bash(bash",".claude/scripts/story-facts.sh","*),","Bash(bash",".claude/scripts/adr-status.sh","*)"]},"allowedTools":["Read,","Glob,","Grep,","AskUserQuestion,","Agent,","Bash(bash","\"*/.claude/skills/story-readiness/../../hooks/yaml-helper.sh\"","resolve_config","*),","Bash(bash",".claude/scripts/story-facts.sh","*),","Bash(bash",".claude/scripts/adr-status.sh","*)"],"isInternal":false,"tokens":4086,"sizeBytes":15435},{"name":"SKILL.md","path":".claude/skills/team-audio/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/team-audio/SKILL.md","title":"team-audio","category":"anthropic-skill","format":"markdown","content":"","frontmatter":{"name":"team-audio","description":"Orchestrate the audio team — audio-director, sound-designer, technical-artist, gameplay-programmer — direction through implementation.","argument-hint":"[feature or area to design audio for] [--review full|lean|solo]","user-invocable":true,"allowed-tools":"Read, Glob, Grep, Write, Edit, Agent, AskUserQuestion, TaskCreate, TaskGet, TaskList, TaskUpdate, Bash(bash \"*/.claude/skills/team-audio/../../hooks/yaml-helper.sh\" resolve_config *)","model":"sonnet","allowedTools":["Read,","Glob,","Grep,","Write,","Edit,","Agent,","AskUserQuestion,","TaskCreate,","TaskGet,","TaskList,","TaskUpdate,","Bash(bash","\"*/.claude/skills/team-audio/../../hooks/yaml-helper.sh\"","resolve_config","*)"]},"allowedTools":["Read,","Glob,","Grep,","Write,","Edit,","Agent,","AskUserQuestion,","TaskCreate,","TaskGet,","TaskList,","TaskUpdate,","Bash(bash","\"*/.claude/skills/team-audio/../../hooks/yaml-helper.sh\"","resolve_config","*)"],"isInternal":false,"tokens":3991,"sizeBytes":17619},{"name":"SKILL.md","path":".claude/skills/team-combat/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/team-combat/SKILL.md","title":"team-combat","category":"anthropic-skill","format":"markdown","content":"","frontmatter":{"name":"team-combat","description":"Orchestrate the combat team — game-designer, gameplay-programmer, ai-programmer, technical-artist, sound-designer, qa-tester — design through implement and validate.","argument-hint":"[combat feature description] [--review full|lean|solo]","user-invocable":true,"allowed-tools":"Read, Glob, Grep, Write, Edit, Agent, AskUserQuestion, TaskCreate, TaskGet, TaskList, TaskUpdate, Bash(bash \"*/.claude/skills/team-combat/../../hooks/yaml-helper.sh\" resolve_config *)","model":"sonnet","allowedTools":["Read,","Glob,","Grep,","Write,","Edit,","Agent,","AskUserQuestion,","TaskCreate,","TaskGet,","TaskList,","TaskUpdate,","Bash(bash","\"*/.claude/skills/team-combat/../../hooks/yaml-helper.sh\"","resolve_config","*)"]},"allowedTools":["Read,","Glob,","Grep,","Write,","Edit,","Agent,","AskUserQuestion,","TaskCreate,","TaskGet,","TaskList,","TaskUpdate,","Bash(bash","\"*/.claude/skills/team-combat/../../hooks/yaml-helper.sh\"","resolve_config","*)"],"isInternal":false,"tokens":4384,"sizeBytes":19176},{"name":"SKILL.md","path":".claude/skills/team-level/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/team-level/SKILL.md","title":"team-level","category":"anthropic-skill","format":"markdown","content":"","frontmatter":{"name":"team-level","description":"Orchestrate the level team — level-designer, narrative-director, world-builder, art-director, systems-designer, qa-tester — for complete area creation.","argument-hint":"[level name or area to design] [--review full|lean|solo]","user-invocable":true,"allowed-tools":"Read, Glob, Grep, Write, Edit, Agent, AskUserQuestion, TaskCreate, TaskGet, TaskList, TaskUpdate, Bash(bash \"*/.claude/skills/team-level/../../hooks/yaml-helper.sh\" resolve_config *)","model":"sonnet","allowedTools":["Read,","Glob,","Grep,","Write,","Edit,","Agent,","AskUserQuestion,","TaskCreate,","TaskGet,","TaskList,","TaskUpdate,","Bash(bash","\"*/.claude/skills/team-level/../../hooks/yaml-helper.sh\"","resolve_config","*)"]},"allowedTools":["Read,","Glob,","Grep,","Write,","Edit,","Agent,","AskUserQuestion,","TaskCreate,","TaskGet,","TaskList,","TaskUpdate,","Bash(bash","\"*/.claude/skills/team-level/../../hooks/yaml-helper.sh\"","resolve_config","*)"],"isInternal":false,"tokens":4321,"sizeBytes":19133},{"name":"SKILL.md","path":".claude/skills/team-live-ops/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/team-live-ops/SKILL.md","title":"team-live-ops","category":"anthropic-skill","format":"markdown","content":"","frontmatter":{"name":"team-live-ops","description":"Orchestrate the live-ops team — live-ops-designer, economy-designer, analytics-engineer, community-manager, writer — for a season or live event.","argument-hint":"[season name or event description] [--review full|lean|solo]","user-invocable":true,"allowed-tools":"Read, Glob, Grep, Write, Edit, Agent, AskUserQuestion, TaskCreate, TaskGet, TaskList, TaskUpdate, Bash(bash \"*/.claude/skills/team-live-ops/../../hooks/yaml-helper.sh\" resolve_config *)","model":"sonnet","allowedTools":["Read,","Glob,","Grep,","Write,","Edit,","Agent,","AskUserQuestion,","TaskCreate,","TaskGet,","TaskList,","TaskUpdate,","Bash(bash","\"*/.claude/skills/team-live-ops/../../hooks/yaml-helper.sh\"","resolve_config","*)"]},"allowedTools":["Read,","Glob,","Grep,","Write,","Edit,","Agent,","AskUserQuestion,","TaskCreate,","TaskGet,","TaskList,","TaskUpdate,","Bash(bash","\"*/.claude/skills/team-live-ops/../../hooks/yaml-helper.sh\"","resolve_config","*)"],"isInternal":false,"tokens":3900,"sizeBytes":17049},{"name":"SKILL.md","path":".claude/skills/team-narrative/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/team-narrative/SKILL.md","title":"team-narrative","category":"anthropic-skill","format":"markdown","content":"","frontmatter":{"name":"team-narrative","description":"Orchestrate the narrative team — narrative-director, writer, world-builder, level-designer — for story, world lore, narrative-driven levels.","argument-hint":"[narrative content description] [--review full|lean|solo]","user-invocable":true,"allowed-tools":"Read, Glob, Grep, Write, Edit, Agent, AskUserQuestion, TaskCreate, TaskGet, TaskList, TaskUpdate, Bash(bash \"*/.claude/skills/team-narrative/../../hooks/yaml-helper.sh\" resolve_config *)","model":"sonnet","allowedTools":["Read,","Glob,","Grep,","Write,","Edit,","Agent,","AskUserQuestion,","TaskCreate,","TaskGet,","TaskList,","TaskUpdate,","Bash(bash","\"*/.claude/skills/team-narrative/../../hooks/yaml-helper.sh\"","resolve_config","*)"]},"allowedTools":["Read,","Glob,","Grep,","Write,","Edit,","Agent,","AskUserQuestion,","TaskCreate,","TaskGet,","TaskList,","TaskUpdate,","Bash(bash","\"*/.claude/skills/team-narrative/../../hooks/yaml-helper.sh\"","resolve_config","*)"],"isInternal":false,"tokens":4103,"sizeBytes":18020},{"name":"SKILL.md","path":".claude/skills/team-polish/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/team-polish/SKILL.md","title":"team-polish","category":"anthropic-skill","format":"markdown","content":"","frontmatter":{"name":"team-polish","description":"Orchestrate the polish team — performance-analyst, technical-artist, sound-designer, qa-tester — to optimize and harden a feature or area.","argument-hint":"[feature or area to polish] [--review full|lean|solo]","user-invocable":true,"allowed-tools":"Read, Glob, Grep, Write, Edit, Agent, AskUserQuestion, TaskCreate, TaskGet, TaskList, TaskUpdate, Bash(bash \"*/.claude/skills/team-polish/../../hooks/yaml-helper.sh\" resolve_config *)","model":"sonnet","allowedTools":["Read,","Glob,","Grep,","Write,","Edit,","Agent,","AskUserQuestion,","TaskCreate,","TaskGet,","TaskList,","TaskUpdate,","Bash(bash","\"*/.claude/skills/team-polish/../../hooks/yaml-helper.sh\"","resolve_config","*)"]},"allowedTools":["Read,","Glob,","Grep,","Write,","Edit,","Agent,","AskUserQuestion,","TaskCreate,","TaskGet,","TaskList,","TaskUpdate,","Bash(bash","\"*/.claude/skills/team-polish/../../hooks/yaml-helper.sh\"","resolve_config","*)"],"isInternal":false,"tokens":4194,"sizeBytes":18301},{"name":"SKILL.md","path":".claude/skills/team-qa/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/team-qa/SKILL.md","title":"team-qa","category":"anthropic-skill","format":"markdown","content":"","frontmatter":{"name":"team-qa","description":"Orchestrate the QA team through a full testing cycle — qa-lead strategy and test plan, qa-tester case writing, execution, sign-off.","argument-hint":"[sprint | feature: system-name] [--review full|lean|solo]","user-invocable":true,"allowed-tools":"Read, Glob, Grep, Write, Agent, AskUserQuestion, Bash(bash \"*/.claude/skills/team-qa/../../hooks/yaml-helper.sh\" resolve_config *)","model":"sonnet","allowedTools":["Read,","Glob,","Grep,","Write,","Agent,","AskUserQuestion,","Bash(bash","\"*/.claude/skills/team-qa/../../hooks/yaml-helper.sh\"","resolve_config","*)"]},"allowedTools":["Read,","Glob,","Grep,","Write,","Agent,","AskUserQuestion,","Bash(bash","\"*/.claude/skills/team-qa/../../hooks/yaml-helper.sh\"","resolve_config","*)"],"isInternal":false,"tokens":6288,"sizeBytes":26115},{"name":"SKILL.md","path":".claude/skills/team-release/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/team-release/SKILL.md","title":"team-release","category":"anthropic-skill","format":"markdown","content":"","frontmatter":{"name":"team-release","description":"Orchestrate the release team — release-manager, qa-lead, devops-engineer, producer — to execute a release from candidate to deployment.","argument-hint":"[version number or 'next'] [--review full|lean|solo]","user-invocable":true,"allowed-tools":"Read, Glob, Grep, Write, Edit, Agent, AskUserQuestion, TaskCreate, TaskGet, TaskList, TaskUpdate, Bash(bash \"*/.claude/skills/team-release/../../hooks/yaml-helper.sh\" resolve_config *)","model":"sonnet","allowedTools":["Read,","Glob,","Grep,","Write,","Edit,","Agent,","AskUserQuestion,","TaskCreate,","TaskGet,","TaskList,","TaskUpdate,","Bash(bash","\"*/.claude/skills/team-release/../../hooks/yaml-helper.sh\"","resolve_config","*)"]},"allowedTools":["Read,","Glob,","Grep,","Write,","Edit,","Agent,","AskUserQuestion,","TaskCreate,","TaskGet,","TaskList,","TaskUpdate,","Bash(bash","\"*/.claude/skills/team-release/../../hooks/yaml-helper.sh\"","resolve_config","*)"],"isInternal":false,"tokens":5177,"sizeBytes":22567},{"name":"SKILL.md","path":".claude/skills/team-ui/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/team-ui/SKILL.md","title":"team-ui","category":"anthropic-skill","format":"markdown","content":"","frontmatter":{"name":"team-ui","description":"Orchestrate the UI team through the UX pipeline — authoring, visual design, implementation, review, polish. Uses /ux-design, /ux-review, studio templates.","argument-hint":"[UI feature description] [--review full|lean|solo]","user-invocable":true,"allowed-tools":"Read, Glob, Grep, Write, Edit, Agent, AskUserQuestion, TaskCreate, TaskGet, TaskList, TaskUpdate, Bash(bash \"*/.claude/skills/team-ui/../../hooks/yaml-helper.sh\" resolve_config *)","model":"sonnet","allowedTools":["Read,","Glob,","Grep,","Write,","Edit,","Agent,","AskUserQuestion,","TaskCreate,","TaskGet,","TaskList,","TaskUpdate,","Bash(bash","\"*/.claude/skills/team-ui/../../hooks/yaml-helper.sh\"","resolve_config","*)"]},"allowedTools":["Read,","Glob,","Grep,","Write,","Edit,","Agent,","AskUserQuestion,","TaskCreate,","TaskGet,","TaskList,","TaskUpdate,","Bash(bash","\"*/.claude/skills/team-ui/../../hooks/yaml-helper.sh\"","resolve_config","*)"],"isInternal":false,"tokens":5089,"sizeBytes":22744},{"name":"SKILL.md","path":".claude/skills/tech-debt/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/tech-debt/SKILL.md","title":"tech-debt","category":"anthropic-skill","format":"markdown","content":"","frontmatter":{"name":"tech-debt","description":"Track, categorize and prioritize technical debt across the codebase — scans for debt indicators, maintains a register.","argument-hint":"[scan|add|prioritize|report]","user-invocable":true,"allowed-tools":"Read, Glob, Grep, Write, Edit, AskUserQuestion, Bash(bash \"*/.claude/skills/tech-debt/../../hooks/yaml-helper.sh\" resolve_config *)","model":"sonnet","allowedTools":["Read,","Glob,","Grep,","Write,","Edit,","AskUserQuestion,","Bash(bash","\"*/.claude/skills/tech-debt/../../hooks/yaml-helper.sh\"","resolve_config","*)"]},"allowedTools":["Read,","Glob,","Grep,","Write,","Edit,","AskUserQuestion,","Bash(bash","\"*/.claude/skills/tech-debt/../../hooks/yaml-helper.sh\"","resolve_config","*)"],"isInternal":false,"tokens":2528,"sizeBytes":10139},{"name":"SKILL.md","path":".claude/skills/test-evidence-review/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/test-evidence-review/SKILL.md","title":"test-evidence-review","category":"anthropic-skill","format":"markdown","content":"","frontmatter":{"name":"test-evidence-review","description":"Quality review of test files and evidence — goes beyond existence, evaluates assertion coverage. ADEQUATE/INCOMPLETE/MISSING/NOT ASSESSED per story.","argument-hint":"[story-path | sprint | system-name]","user-invocable":true,"allowed-tools":"Read, Glob, Grep, Write, Bash(bash \"*/.claude/skills/test-evidence-review/../../hooks/yaml-helper.sh\" resolve_config *), Bash(bash .claude/scripts/review-receipts.sh check *)","model":"sonnet","allowedTools":["Read,","Glob,","Grep,","Write,","Bash(bash","\"*/.claude/skills/test-evidence-review/../../hooks/yaml-helper.sh\"","resolve_config","*),","Bash(bash",".claude/scripts/review-receipts.sh","check","*)"]},"allowedTools":["Read,","Glob,","Grep,","Write,","Bash(bash","\"*/.claude/skills/test-evidence-review/../../hooks/yaml-helper.sh\"","resolve_config","*),","Bash(bash",".claude/scripts/review-receipts.sh","check","*)"],"isInternal":false,"tokens":4102,"sizeBytes":16721},{"name":"SKILL.md","path":".claude/skills/test-flakiness/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/test-flakiness/SKILL.md","title":"test-flakiness","category":"anthropic-skill","format":"markdown","content":"","frontmatter":{"name":"test-flakiness","description":"Find flaky tests from CI logs — aggregates pass rates, spots intermittent failures, recommends quarantine. After multiple runs.","argument-hint":"[ci-log-path | scan | registry]","user-invocable":true,"allowed-tools":"Read, Glob, Grep, Write, Edit, Bash(ls -t *), Bash(bash \"*/.claude/skills/test-flakiness/../../hooks/yaml-helper.sh\" resolve_config *)","model":"sonnet","allowedTools":["Read,","Glob,","Grep,","Write,","Edit,","Bash(ls","-t","*),","Bash(bash","\"*/.claude/skills/test-flakiness/../../hooks/yaml-helper.sh\"","resolve_config","*)"]},"allowedTools":["Read,","Glob,","Grep,","Write,","Edit,","Bash(ls","-t","*),","Bash(bash","\"*/.claude/skills/test-flakiness/../../hooks/yaml-helper.sh\"","resolve_config","*)"],"isInternal":false,"tokens":2597,"sizeBytes":10494},{"name":"SKILL.md","path":".claude/skills/test-helpers/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/test-helpers/SKILL.md","title":"test-helpers","category":"anthropic-skill","format":"markdown","content":"","frontmatter":{"name":"test-helpers","description":"Generate engine-specific test helper libraries — assertion utilities, factory functions, mocks in the engine's test folder. Reduces boilerplate.","argument-hint":"[system-name | all | scaffold]","user-invocable":true,"allowed-tools":"Read, Glob, Grep, Write, Bash(bash \"*/.claude/skills/test-helpers/../../hooks/yaml-helper.sh\" resolve_config *)","model":"sonnet","allowedTools":["Read,","Glob,","Grep,","Write,","Bash(bash","\"*/.claude/skills/test-helpers/../../hooks/yaml-helper.sh\"","resolve_config","*)"]},"allowedTools":["Read,","Glob,","Grep,","Write,","Bash(bash","\"*/.claude/skills/test-helpers/../../hooks/yaml-helper.sh\"","resolve_config","*)"],"isInternal":false,"tokens":4252,"sizeBytes":17891},{"name":"1-detect.md","path":".claude/skills/test-setup/references/1-detect.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/test-setup/references/1-detect.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":468,"sizeBytes":1887},{"name":"2-plan.md","path":".claude/skills/test-setup/references/2-plan.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/test-setup/references/2-plan.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":371,"sizeBytes":1557},{"name":"3-directories.md","path":".claude/skills/test-setup/references/3-directories.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/test-setup/references/3-directories.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":3150,"sizeBytes":11862},{"name":"4-ci.md","path":".claude/skills/test-setup/references/4-ci.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/test-setup/references/4-ci.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":1386,"sizeBytes":5370},{"name":"5-smoke-seed.md","path":".claude/skills/test-setup/references/5-smoke-seed.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/test-setup/references/5-smoke-seed.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":298,"sizeBytes":1295},{"name":"6-summary.md","path":".claude/skills/test-setup/references/6-summary.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/test-setup/references/6-summary.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":490,"sizeBytes":1866},{"name":"SKILL.md","path":".claude/skills/test-setup/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/test-setup/SKILL.md","title":"test-setup","category":"anthropic-skill","format":"markdown","content":"","frontmatter":{"name":"test-setup","description":"Scaffold the test framework and CI — tests/ directory, engine test runner, GitHub Actions workflow. Once, before the first sprint.","argument-hint":"[force]","user-invocable":true,"allowed-tools":"Read, Glob, Grep, Write, Bash(grep -q 'com.unity.test-framework' Packages/manifest.json), Bash(bash \"*/.claude/skills/test-setup/../../hooks/yaml-helper.sh\" resolve_config *)","model":"sonnet","allowedTools":["Read,","Glob,","Grep,","Write,","Bash(grep","-q","'com.unity.test-framework'","Packages/manifest.json),","Bash(bash","\"*/.claude/skills/test-setup/../../hooks/yaml-helper.sh\"","resolve_config","*)"]},"allowedTools":["Read,","Glob,","Grep,","Write,","Bash(grep","-q","'com.unity.test-framework'","Packages/manifest.json),","Bash(bash","\"*/.claude/skills/test-setup/../../hooks/yaml-helper.sh\"","resolve_config","*)"],"isInternal":false,"tokens":783,"sizeBytes":3388},{"name":"2-gather-context.md","path":".claude/skills/ux-design/references/2-gather-context.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/ux-design/references/2-gather-context.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":2041,"sizeBytes":8420},{"name":"3-file-skeleton.md","path":".claude/skills/ux-design/references/3-file-skeleton.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/ux-design/references/3-file-skeleton.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":1171,"sizeBytes":5063},{"name":"4-authoring.md","path":".claude/skills/ux-design/references/4-authoring.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/ux-design/references/4-authoring.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":389,"sizeBytes":1650},{"name":"5-crossref-handoff.md","path":".claude/skills/ux-design/references/5-crossref-handoff.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/ux-design/references/5-crossref-handoff.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":693,"sizeBytes":2911},{"name":"sections-hud.md","path":".claude/skills/ux-design/references/sections-hud.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/ux-design/references/sections-hud.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":1564,"sizeBytes":7330},{"name":"sections-patterns.md","path":".claude/skills/ux-design/references/sections-patterns.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/ux-design/references/sections-patterns.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":439,"sizeBytes":2018},{"name":"sections-ux-spec.md","path":".claude/skills/ux-design/references/sections-ux-spec.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/ux-design/references/sections-ux-spec.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":2698,"sizeBytes":12166},{"name":"SKILL.md","path":".claude/skills/ux-design/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/ux-design/SKILL.md","title":"ux-design","category":"anthropic-skill","format":"markdown","content":"","frontmatter":{"name":"ux-design","description":"Section-by-section UX spec authoring for a screen, flow or HUD. Reads the player journey to provide context; also project-wide accessibility.","argument-hint":"[screen/flow name] or 'hud' or 'patterns' or 'accessibility'","user-invocable":true,"allowed-tools":"Read, Glob, Grep, Write, Edit, AskUserQuestion, Agent, Bash(bash \"*/.claude/skills/ux-design/../../hooks/yaml-helper.sh\" resolve_config *)","model":"sonnet","allowedTools":["Read,","Glob,","Grep,","Write,","Edit,","AskUserQuestion,","Agent,","Bash(bash","\"*/.claude/skills/ux-design/../../hooks/yaml-helper.sh\"","resolve_config","*)"]},"allowedTools":["Read,","Glob,","Grep,","Write,","Edit,","AskUserQuestion,","Agent,","Bash(bash","\"*/.claude/skills/ux-design/../../hooks/yaml-helper.sh\"","resolve_config","*)"],"isInternal":false,"tokens":2244,"sizeBytes":9708},{"name":"SKILL.md","path":".claude/skills/ux-review/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/ux-review/SKILL.md","title":"ux-review","category":"anthropic-skill","format":"markdown","content":"","frontmatter":{"name":"ux-review","description":"Validate a UX spec, HUD design or pattern library — accessibility, GDD alignment, readiness. APPROVED / NOT ASSESSED / NEEDS REVISION / MAJOR REVISION NEEDED.","argument-hint":"[file-path or 'all' or 'hud' or 'patterns']","user-invocable":true,"allowed-tools":"Read, Glob, Grep, Bash(bash \"*/.claude/skills/ux-review/../../hooks/yaml-helper.sh\" resolve_config *)","model":"sonnet","allowedTools":["Read,","Glob,","Grep,","Bash(bash","\"*/.claude/skills/ux-review/../../hooks/yaml-helper.sh\"","resolve_config","*)"]},"allowedTools":["Read,","Glob,","Grep,","Bash(bash","\"*/.claude/skills/ux-review/../../hooks/yaml-helper.sh\"","resolve_config","*)"],"isInternal":false,"tokens":3546,"sizeBytes":15126},{"name":"SKILL.md","path":".claude/skills/vertical-slice/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/skills/vertical-slice/SKILL.md","title":"vertical-slice","category":"anthropic-skill","format":"markdown","content":"","frontmatter":{"name":"vertical-slice","description":"Pre-production validation — end-to-end build to confirm the full loop is achievable before committing to Production. After GDDs, architecture, UX specs.","argument-hint":"[--review full|lean|solo]","user-invocable":true,"allowed-tools":"Read, Glob, Grep, Write, Edit, Agent, AskUserQuestion, Bash(bash \"*/.claude/skills/vertical-slice/../../hooks/yaml-helper.sh\" resolve_config *)","model":"sonnet","allowedTools":["Read,","Glob,","Grep,","Write,","Edit,","Agent,","AskUserQuestion,","Bash(bash","\"*/.claude/skills/vertical-slice/../../hooks/yaml-helper.sh\"","resolve_config","*)"]},"allowedTools":["Read,","Glob,","Grep,","Write,","Edit,","Agent,","AskUserQuestion,","Bash(bash","\"*/.claude/skills/vertical-slice/../../hooks/yaml-helper.sh\"","resolve_config","*)"],"isInternal":false,"tokens":4948,"sizeBytes":21254},{"name":"addressables.md","path":"docs/engine-reference/unity/plugins/addressables.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/docs/engine-reference/unity/plugins/addressables.md","title":"Plugins Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":1834,"sizeBytes":8222},{"name":"cinemachine.md","path":"docs/engine-reference/unity/plugins/cinemachine.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/docs/engine-reference/unity/plugins/cinemachine.md","title":"Plugins Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":1803,"sizeBytes":7179},{"name":"dots-entities.md","path":"docs/engine-reference/unity/plugins/dots-entities.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/docs/engine-reference/unity/plugins/dots-entities.md","title":"Plugins Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":2173,"sizeBytes":9193},{"name":"common-ui.md","path":"docs/engine-reference/unreal/plugins/common-ui.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/docs/engine-reference/unreal/plugins/common-ui.md","title":"Plugins Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":2387,"sizeBytes":10261},{"name":"gameplay-ability-system.md","path":"docs/engine-reference/unreal/plugins/gameplay-ability-system.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/docs/engine-reference/unreal/plugins/gameplay-ability-system.md","title":"Plugins Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":3235,"sizeBytes":13493},{"name":"gameplay-camera-system.md","path":"docs/engine-reference/unreal/plugins/gameplay-camera-system.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/docs/engine-reference/unreal/plugins/gameplay-camera-system.md","title":"Plugins Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":1945,"sizeBytes":7695},{"name":"pcg.md","path":"docs/engine-reference/unreal/plugins/pcg.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/docs/engine-reference/unreal/plugins/pcg.md","title":"Plugins Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":2003,"sizeBytes":7939},{"name":"asset-audit.md","path":"studio-tests/skills/analysis/asset-audit.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/studio-tests/skills/analysis/asset-audit.md","title":"Analysis Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":4042,"sizeBytes":15325},{"name":"balance-check.md","path":"studio-tests/skills/analysis/balance-check.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/studio-tests/skills/analysis/balance-check.md","title":"Analysis Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":2978,"sizeBytes":12021},{"name":"code-review.md","path":"studio-tests/skills/analysis/code-review.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/studio-tests/skills/analysis/code-review.md","title":"Analysis Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":3427,"sizeBytes":13565},{"name":"consistency-check.md","path":"studio-tests/skills/analysis/consistency-check.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/studio-tests/skills/analysis/consistency-check.md","title":"Analysis Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":4668,"sizeBytes":17803},{"name":"content-audit.md","path":"studio-tests/skills/analysis/content-audit.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/studio-tests/skills/analysis/content-audit.md","title":"Analysis Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":3851,"sizeBytes":14708},{"name":"estimate.md","path":"studio-tests/skills/analysis/estimate.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/studio-tests/skills/analysis/estimate.md","title":"Analysis Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":2040,"sizeBytes":8935},{"name":"perf-profile.md","path":"studio-tests/skills/analysis/perf-profile.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/studio-tests/skills/analysis/perf-profile.md","title":"Analysis Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":3707,"sizeBytes":14835},{"name":"scope-check.md","path":"studio-tests/skills/analysis/scope-check.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/studio-tests/skills/analysis/scope-check.md","title":"Analysis Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":2399,"sizeBytes":9502},{"name":"security-audit.md","path":"studio-tests/skills/analysis/security-audit.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/studio-tests/skills/analysis/security-audit.md","title":"Analysis Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":3898,"sizeBytes":15914},{"name":"tech-debt.md","path":"studio-tests/skills/analysis/tech-debt.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/studio-tests/skills/analysis/tech-debt.md","title":"Analysis Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":3872,"sizeBytes":14630},{"name":"test-evidence-review.md","path":"studio-tests/skills/analysis/test-evidence-review.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/studio-tests/skills/analysis/test-evidence-review.md","title":"Analysis Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":4291,"sizeBytes":16642},{"name":"test-flakiness.md","path":"studio-tests/skills/analysis/test-flakiness.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/studio-tests/skills/analysis/test-flakiness.md","title":"Analysis Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":2603,"sizeBytes":10407},{"name":"architecture-decision.md","path":"studio-tests/skills/authoring/architecture-decision.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/studio-tests/skills/authoring/architecture-decision.md","title":"Authoring Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":4790,"sizeBytes":18781},{"name":"art-bible.md","path":"studio-tests/skills/authoring/art-bible.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/studio-tests/skills/authoring/art-bible.md","title":"Authoring Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":4111,"sizeBytes":16271},{"name":"create-architecture.md","path":"studio-tests/skills/authoring/create-architecture.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/studio-tests/skills/authoring/create-architecture.md","title":"Authoring Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":5114,"sizeBytes":20114},{"name":"design-system.md","path":"studio-tests/skills/authoring/design-system.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/studio-tests/skills/authoring/design-system.md","title":"Authoring Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":6049,"sizeBytes":24139},{"name":"quick-design.md","path":"studio-tests/skills/authoring/quick-design.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/studio-tests/skills/authoring/quick-design.md","title":"Authoring Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":2955,"sizeBytes":11927},{"name":"ux-design.md","path":"studio-tests/skills/authoring/ux-design.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/studio-tests/skills/authoring/ux-design.md","title":"Authoring Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":3526,"sizeBytes":14896},{"name":"ux-review.md","path":"studio-tests/skills/authoring/ux-review.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/studio-tests/skills/authoring/ux-review.md","title":"Authoring Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":3000,"sizeBytes":12044},{"name":"gate-check.md","path":"studio-tests/skills/gate/gate-check.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/studio-tests/skills/gate/gate-check.md","title":"Gate Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":5872,"sizeBytes":23634},{"name":"create-control-manifest.md","path":"studio-tests/skills/pipeline/create-control-manifest.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/studio-tests/skills/pipeline/create-control-manifest.md","title":"Pipeline Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":2929,"sizeBytes":11370},{"name":"create-epics.md","path":"studio-tests/skills/pipeline/create-epics.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/studio-tests/skills/pipeline/create-epics.md","title":"Pipeline Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":4136,"sizeBytes":15339},{"name":"create-stories.md","path":"studio-tests/skills/pipeline/create-stories.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/studio-tests/skills/pipeline/create-stories.md","title":"Pipeline Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":4473,"sizeBytes":16615},{"name":"dev-story.md","path":"studio-tests/skills/pipeline/dev-story.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/studio-tests/skills/pipeline/dev-story.md","title":"Pipeline Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":6523,"sizeBytes":25064},{"name":"map-systems.md","path":"studio-tests/skills/pipeline/map-systems.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/studio-tests/skills/pipeline/map-systems.md","title":"Pipeline Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":3454,"sizeBytes":13943},{"name":"propagate-design-change.md","path":"studio-tests/skills/pipeline/propagate-design-change.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/studio-tests/skills/pipeline/propagate-design-change.md","title":"Pipeline Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":3342,"sizeBytes":12681},{"name":"vertical-slice.md","path":"studio-tests/skills/pipeline/vertical-slice.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/studio-tests/skills/pipeline/vertical-slice.md","title":"Pipeline Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":4059,"sizeBytes":15661},{"name":"story-done.md","path":"studio-tests/skills/readiness/story-done.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/studio-tests/skills/readiness/story-done.md","title":"Readiness Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":5410,"sizeBytes":21403},{"name":"story-readiness.md","path":"studio-tests/skills/readiness/story-readiness.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/studio-tests/skills/readiness/story-readiness.md","title":"Readiness Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":4933,"sizeBytes":19147},{"name":"architecture-review.md","path":"studio-tests/skills/review/architecture-review.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/studio-tests/skills/review/architecture-review.md","title":"Review Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":3223,"sizeBytes":12362},{"name":"design-review.md","path":"studio-tests/skills/review/design-review.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/studio-tests/skills/review/design-review.md","title":"Review Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":3134,"sizeBytes":12785},{"name":"review-all-gdds.md","path":"studio-tests/skills/review/review-all-gdds.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/studio-tests/skills/review/review-all-gdds.md","title":"Review Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":5002,"sizeBytes":19274},{"name":"changelog.md","path":"studio-tests/skills/sprint/changelog.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/studio-tests/skills/sprint/changelog.md","title":"Sprint Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":2950,"sizeBytes":11632},{"name":"milestone-review.md","path":"studio-tests/skills/sprint/milestone-review.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/studio-tests/skills/sprint/milestone-review.md","title":"Sprint Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":3472,"sizeBytes":13945},{"name":"patch-notes.md","path":"studio-tests/skills/sprint/patch-notes.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/studio-tests/skills/sprint/patch-notes.md","title":"Sprint Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":3042,"sizeBytes":12133},{"name":"retrospective.md","path":"studio-tests/skills/sprint/retrospective.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/studio-tests/skills/sprint/retrospective.md","title":"Sprint Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":3043,"sizeBytes":12354},{"name":"sprint-plan.md","path":"studio-tests/skills/sprint/sprint-plan.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/studio-tests/skills/sprint/sprint-plan.md","title":"Sprint Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":3649,"sizeBytes":14282},{"name":"sprint-status.md","path":"studio-tests/skills/sprint/sprint-status.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/studio-tests/skills/sprint/sprint-status.md","title":"Sprint Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":2975,"sizeBytes":11448},{"name":"team-audio.md","path":"studio-tests/skills/team/team-audio.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/studio-tests/skills/team/team-audio.md","title":"Team Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":4429,"sizeBytes":19190},{"name":"team-combat.md","path":"studio-tests/skills/team/team-combat.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/studio-tests/skills/team/team-combat.md","title":"Team Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":3862,"sizeBytes":16698},{"name":"team-level.md","path":"studio-tests/skills/team/team-level.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/studio-tests/skills/team/team-level.md","title":"Team Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":3810,"sizeBytes":16585},{"name":"team-live-ops.md","path":"studio-tests/skills/team/team-live-ops.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/studio-tests/skills/team/team-live-ops.md","title":"Team Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":3683,"sizeBytes":15606},{"name":"team-narrative.md","path":"studio-tests/skills/team/team-narrative.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/studio-tests/skills/team/team-narrative.md","title":"Team Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":4419,"sizeBytes":18938},{"name":"team-polish.md","path":"studio-tests/skills/team/team-polish.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/studio-tests/skills/team/team-polish.md","title":"Team Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":6075,"sizeBytes":25626},{"name":"team-qa.md","path":"studio-tests/skills/team/team-qa.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/studio-tests/skills/team/team-qa.md","title":"Team Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":6880,"sizeBytes":26922},{"name":"team-release.md","path":"studio-tests/skills/team/team-release.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/studio-tests/skills/team/team-release.md","title":"Team Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":5785,"sizeBytes":24260},{"name":"team-ui.md","path":"studio-tests/skills/team/team-ui.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/studio-tests/skills/team/team-ui.md","title":"Team Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":4466,"sizeBytes":18974},{"name":"adopt.md","path":"studio-tests/skills/utility/adopt.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/studio-tests/skills/utility/adopt.md","title":"Utility Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":3720,"sizeBytes":14462},{"name":"asset-spec.md","path":"studio-tests/skills/utility/asset-spec.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/studio-tests/skills/utility/asset-spec.md","title":"Utility Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":3237,"sizeBytes":12849},{"name":"brainstorm.md","path":"studio-tests/skills/utility/brainstorm.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/studio-tests/skills/utility/brainstorm.md","title":"Utility Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":3059,"sizeBytes":11664},{"name":"bug-report.md","path":"studio-tests/skills/utility/bug-report.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/studio-tests/skills/utility/bug-report.md","title":"Utility Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":3699,"sizeBytes":14491},{"name":"bug-triage.md","path":"studio-tests/skills/utility/bug-triage.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/studio-tests/skills/utility/bug-triage.md","title":"Utility Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":2825,"sizeBytes":10254},{"name":"day-one-patch.md","path":"studio-tests/skills/utility/day-one-patch.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/studio-tests/skills/utility/day-one-patch.md","title":"Utility Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":3133,"sizeBytes":12021},{"name":"help.md","path":"studio-tests/skills/utility/help.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/studio-tests/skills/utility/help.md","title":"Utility Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":4053,"sizeBytes":15303},{"name":"hotfix.md","path":"studio-tests/skills/utility/hotfix.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/studio-tests/skills/utility/hotfix.md","title":"Utility Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":3600,"sizeBytes":13468},{"name":"launch-checklist.md","path":"studio-tests/skills/utility/launch-checklist.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/studio-tests/skills/utility/launch-checklist.md","title":"Utility Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":3594,"sizeBytes":14184},{"name":"localize.md","path":"studio-tests/skills/utility/localize.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/studio-tests/skills/utility/localize.md","title":"Utility Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":2646,"sizeBytes":10654},{"name":"onboard.md","path":"studio-tests/skills/utility/onboard.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/studio-tests/skills/utility/onboard.md","title":"Utility Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":2237,"sizeBytes":8653},{"name":"playtest-report.md","path":"studio-tests/skills/utility/playtest-report.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/studio-tests/skills/utility/playtest-report.md","title":"Utility Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":2359,"sizeBytes":9467},{"name":"project-stage-detect.md","path":"studio-tests/skills/utility/project-stage-detect.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/studio-tests/skills/utility/project-stage-detect.md","title":"Utility Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":3324,"sizeBytes":13373},{"name":"prototype.md","path":"studio-tests/skills/utility/prototype.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/studio-tests/skills/utility/prototype.md","title":"Utility Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":4306,"sizeBytes":16324},{"name":"qa-plan.md","path":"studio-tests/skills/utility/qa-plan.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/studio-tests/skills/utility/qa-plan.md","title":"Utility Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":2112,"sizeBytes":8691},{"name":"regression-suite.md","path":"studio-tests/skills/utility/regression-suite.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/studio-tests/skills/utility/regression-suite.md","title":"Utility Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":2941,"sizeBytes":11735},{"name":"release-checklist.md","path":"studio-tests/skills/utility/release-checklist.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/studio-tests/skills/utility/release-checklist.md","title":"Utility Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":3329,"sizeBytes":12579},{"name":"reverse-document.md","path":"studio-tests/skills/utility/reverse-document.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/studio-tests/skills/utility/reverse-document.md","title":"Utility Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":3235,"sizeBytes":12802},{"name":"settings.md","path":"studio-tests/skills/utility/settings.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/studio-tests/skills/utility/settings.md","title":"Utility Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":2933,"sizeBytes":11577},{"name":"setup-engine.md","path":"studio-tests/skills/utility/setup-engine.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/studio-tests/skills/utility/setup-engine.md","title":"Utility Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":3822,"sizeBytes":14668},{"name":"skill-improve.md","path":"studio-tests/skills/utility/skill-improve.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/studio-tests/skills/utility/skill-improve.md","title":"Utility Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":3941,"sizeBytes":15121},{"name":"skill-test.md","path":"studio-tests/skills/utility/skill-test.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/studio-tests/skills/utility/skill-test.md","title":"Utility Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":4795,"sizeBytes":18269},{"name":"smoke-check.md","path":"studio-tests/skills/utility/smoke-check.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/studio-tests/skills/utility/smoke-check.md","title":"Utility Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":5818,"sizeBytes":22444},{"name":"soak-test.md","path":"studio-tests/skills/utility/soak-test.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/studio-tests/skills/utility/soak-test.md","title":"Utility Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":2592,"sizeBytes":9655},{"name":"start.md","path":"studio-tests/skills/utility/start.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/studio-tests/skills/utility/start.md","title":"Utility Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":3761,"sizeBytes":14426},{"name":"test-helpers.md","path":"studio-tests/skills/utility/test-helpers.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/studio-tests/skills/utility/test-helpers.md","title":"Utility Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":2417,"sizeBytes":9797},{"name":"test-setup.md","path":"studio-tests/skills/utility/test-setup.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/studio-tests/skills/utility/test-setup.md","title":"Utility Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":2162,"sizeBytes":8384},{"name":"accessibility-specialist.md","path":".claude/agents/accessibility-specialist.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/agents/accessibility-specialist.md","title":"accessibility-specialist","category":"subagent-persona","format":"markdown","content":"","frontmatter":{"name":"accessibility-specialist","description":"Accessibility standards and assistive features — remapping, text scaling, colorblind modes, screen reader support.","tools":"Read, Glob, Grep, Write, Edit, Bash","model":"inherit","maxTurns":10},"isInternal":false,"tokens":1966,"sizeBytes":8851},{"name":"ai-programmer.md","path":".claude/agents/ai-programmer.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/agents/ai-programmer.md","title":"ai-programmer","category":"subagent-persona","format":"markdown","content":"","frontmatter":{"name":"ai-programmer","description":"Implements game AI — behavior trees, state machines, pathfinding, perception, decision-making, NPC and enemy behavior, AI debugging.","tools":"Read, Glob, Grep, Write, Edit, Bash","model":"inherit","maxTurns":20},"isInternal":false,"tokens":1157,"sizeBytes":5436},{"name":"analytics-engineer.md","path":".claude/agents/analytics-engineer.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/agents/analytics-engineer.md","title":"analytics-engineer","category":"subagent-persona","format":"markdown","content":"","frontmatter":{"name":"analytics-engineer","description":"Telemetry and analytics — event tracking, player behavior, A/B test frameworks, dashboard specification, data pipelines.","tools":"Read, Glob, Grep, Write, Edit, Bash, WebSearch","model":"inherit","maxTurns":20},"isInternal":false,"tokens":1126,"sizeBytes":5267},{"name":"art-director.md","path":".claude/agents/art-director.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/agents/art-director.md","title":"art-director","category":"subagent-persona","format":"markdown","content":"","frontmatter":{"name":"art-director","description":"Owns visual identity — style guides, art bible, asset standards, color palettes, UI visual direction.","tools":"Read, Glob, Grep, Write, Edit, WebSearch","model":"inherit","maxTurns":20,"disallowedTools":"Bash","memory":"project"},"isInternal":false,"tokens":1722,"sizeBytes":7593},{"name":"audio-director.md","path":".claude/agents/audio-director.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/agents/audio-director.md","title":"audio-director","category":"subagent-persona","format":"markdown","content":"","frontmatter":{"name":"audio-director","description":"Owns sonic identity — music direction, sound palette, audio implementation strategy, mix balance.","tools":"Read, Glob, Grep, Write, Edit, WebSearch","model":"inherit","maxTurns":20,"disallowedTools":"Bash","memory":"project"},"isInternal":false,"tokens":1267,"sizeBytes":5710},{"name":"community-manager.md","path":".claude/agents/community-manager.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/agents/community-manager.md","title":"community-manager","category":"subagent-persona","format":"markdown","content":"","frontmatter":{"name":"community-manager","description":"Player-facing communication — patch notes, social posts, community updates, feedback collection, player bug triage, crisis communication.","tools":"Read, Glob, Grep, Write, Edit","model":"sonnet","maxTurns":10,"disallowedTools":"Bash"},"isInternal":false,"tokens":1876,"sizeBytes":8623},{"name":"creative-director.md","path":".claude/agents/creative-director.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/agents/creative-director.md","title":"creative-director","category":"subagent-persona","format":"markdown","content":"","frontmatter":{"name":"creative-director","description":"Highest creative authority — vision, tone, aesthetic direction. Use when a decision affects game identity or department leads deadlock.","tools":"Read, Glob, Grep, Write, Edit, WebSearch","model":"opus","maxTurns":30,"memory":"project","disallowedTools":"Bash"},"isInternal":false,"tokens":4098,"sizeBytes":18165},{"name":"devops-engineer.md","path":".claude/agents/devops-engineer.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/agents/devops-engineer.md","title":"devops-engineer","category":"subagent-persona","format":"markdown","content":"","frontmatter":{"name":"devops-engineer","description":"Build pipelines, CI/CD configuration, version control workflow, branching strategy, automated test pipelines, deployment infrastructure.","tools":"Read, Glob, Grep, Write, Edit, Bash","model":"sonnet","maxTurns":10},"isInternal":false,"tokens":1348,"sizeBytes":6155},{"name":"economy-designer.md","path":".claude/agents/economy-designer.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/agents/economy-designer.md","title":"economy-designer","category":"subagent-persona","format":"markdown","content":"","frontmatter":{"name":"economy-designer","description":"Resource economies — loot tables, sink/faucet analysis, progression curve calibration, economic balance.","tools":"Read, Glob, Grep, Write, Edit","model":"inherit","maxTurns":20,"disallowedTools":"Bash","memory":"project"},"isInternal":false,"tokens":1729,"sizeBytes":7968},{"name":"engine-programmer.md","path":".claude/agents/engine-programmer.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/agents/engine-programmer.md","title":"engine-programmer","category":"subagent-persona","format":"markdown","content":"","frontmatter":{"name":"engine-programmer","description":"Core engine systems — rendering pipeline, physics, memory, resource loading, scene management, performance-critical framework code.","tools":"Read, Glob, Grep, Write, Edit, Bash","model":"inherit","maxTurns":20},"isInternal":false,"tokens":1403,"sizeBytes":6692},{"name":"game-designer.md","path":".claude/agents/game-designer.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/agents/game-designer.md","title":"game-designer","category":"subagent-persona","format":"markdown","content":"","frontmatter":{"name":"game-designer","description":"Mechanical and systems design — core loops, progression, combat, economy, player-facing rules. Mechanics-level questions.","tools":"Read, Glob, Grep, Write, Edit, WebSearch","model":"inherit","maxTurns":20,"disallowedTools":"Bash","skills":["balance-check"],"memory":"project"},"isInternal":false,"tokens":3006,"sizeBytes":13726},{"name":"gameplay-programmer.md","path":".claude/agents/gameplay-programmer.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/agents/gameplay-programmer.md","title":"gameplay-programmer","category":"subagent-persona","format":"markdown","content":"","frontmatter":{"name":"gameplay-programmer","description":"Implements designed mechanics as code — player systems, combat, interactive features, gameplay system code.","tools":"Read, Glob, Grep, Write, Edit, Bash","model":"inherit","maxTurns":20},"isInternal":false,"tokens":1712,"sizeBytes":8098},{"name":"godot-csharp-specialist.md","path":".claude/agents/godot-csharp-specialist.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/agents/godot-csharp-specialist.md","title":"godot-csharp-specialist","category":"subagent-persona","format":"markdown","content":"","frontmatter":{"name":"godot-csharp-specialist","description":"Godot 4 C# quality — .NET patterns, attribute-based exports, signal delegates, async patterns, type-safe node access.","tools":"Read, Glob, Grep, Write, Edit, Bash","model":"sonnet","maxTurns":20},"isInternal":false,"tokens":4398,"sizeBytes":18829},{"name":"godot-gdextension-specialist.md","path":".claude/agents/godot-gdextension-specialist.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/agents/godot-gdextension-specialist.md","title":"godot-gdextension-specialist","category":"subagent-persona","format":"markdown","content":"","frontmatter":{"name":"godot-gdextension-specialist","description":"Native code integration with Godot — GDExtension API, godot-cpp and godot-rust bindings, custom node types, the native boundary.","tools":"Read, Glob, Grep, Write, Edit, Bash","model":"sonnet","maxTurns":20},"isInternal":false,"tokens":3857,"sizeBytes":16295},{"name":"godot-gdscript-specialist.md","path":".claude/agents/godot-gdscript-specialist.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/agents/godot-gdscript-specialist.md","title":"godot-gdscript-specialist","category":"subagent-persona","format":"markdown","content":"","frontmatter":{"name":"godot-gdscript-specialist","description":"GDScript code quality — static typing enforcement, signal architecture, coroutine patterns, GDScript idioms, typed and performant.","tools":"Read, Glob, Grep, Write, Edit, Bash","model":"sonnet","maxTurns":20},"isInternal":false,"tokens":3590,"sizeBytes":14962},{"name":"godot-shader-specialist.md","path":".claude/agents/godot-shader-specialist.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/agents/godot-shader-specialist.md","title":"godot-shader-specialist","category":"subagent-persona","format":"markdown","content":"","frontmatter":{"name":"godot-shader-specialist","description":"Godot rendering customization — shading language, visual shaders, material setup, particle shaders, post-processing.","tools":"Read, Glob, Grep, Write, Edit, Bash","model":"sonnet","maxTurns":20},"isInternal":false,"tokens":3178,"sizeBytes":13138},{"name":"godot-specialist.md","path":".claude/agents/godot-specialist.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/agents/godot-specialist.md","title":"godot-specialist","category":"subagent-persona","format":"markdown","content":"","frontmatter":{"name":"godot-specialist","description":"Authority on Godot-specific patterns and APIs — node/scene architecture, signals, resources; guides GDScript vs C# vs GDExtension.","tools":"Read, Glob, Grep, Write, Edit, Bash, Agent","model":"inherit","maxTurns":20},"isInternal":false,"tokens":2792,"sizeBytes":12314},{"name":"lead-programmer.md","path":".claude/agents/lead-programmer.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/agents/lead-programmer.md","title":"lead-programmer","category":"subagent-persona","format":"markdown","content":"","frontmatter":{"name":"lead-programmer","description":"Lead programmer — code-level architecture, coding standards, code review, API design, refactoring strategy, assigning work to specialist programmers.","tools":"Read, Glob, Grep, Write, Edit, Bash","model":"sonnet","maxTurns":20,"skills":["tech-debt"],"memory":"project"},"isInternal":false,"tokens":1424,"sizeBytes":6676},{"name":"level-designer.md","path":".claude/agents/level-designer.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/agents/level-designer.md","title":"level-designer","category":"subagent-persona","format":"markdown","content":"","frontmatter":{"name":"level-designer","description":"Spatial design for levels and areas — encounter layouts, pacing, difficulty, layout planning, environmental storytelling.","tools":"Read, Glob, Grep, Write, Edit","model":"inherit","maxTurns":20,"disallowedTools":"Bash","memory":"project"},"isInternal":false,"tokens":1373,"sizeBytes":6310},{"name":"live-ops-designer.md","path":".claude/agents/live-ops-designer.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/agents/live-ops-designer.md","title":"live-ops-designer","category":"subagent-persona","format":"markdown","content":"","frontmatter":{"name":"live-ops-designer","description":"Post-launch content — seasonal events, battle passes, content cadence, retention, engagement analytics. Keeps the game fresh.","tools":"Read, Glob, Grep, Write, Edit","model":"inherit","maxTurns":20,"disallowedTools":"Bash"},"isInternal":false,"tokens":2240,"sizeBytes":10189},{"name":"localization-lead.md","path":".claude/agents/localization-lead.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/agents/localization-lead.md","title":"localization-lead","category":"subagent-persona","format":"markdown","content":"","frontmatter":{"name":"localization-lead","description":"Internationalization architecture — i18n system design, string extraction workflows, locale testing, locale-specific issues, translation pipeline.","tools":"Read, Glob, Grep, Write, Edit, Bash","model":"inherit","maxTurns":20,"memory":"project"},"isInternal":false,"tokens":2019,"sizeBytes":9531},{"name":"narrative-director.md","path":".claude/agents/narrative-director.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/agents/narrative-director.md","title":"narrative-director","category":"subagent-persona","format":"markdown","content":"","frontmatter":{"name":"narrative-director","description":"Story architecture, world-building, character design, dialogue strategy. Narrative structure and direction rather than writing individual lines.","tools":"Read, Glob, Grep, Write, Edit, WebSearch","model":"inherit","maxTurns":20,"disallowedTools":"Bash","memory":"project"},"isInternal":false,"tokens":1546,"sizeBytes":7136},{"name":"network-programmer.md","path":".claude/agents/network-programmer.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/agents/network-programmer.md","title":"network-programmer","category":"subagent-persona","format":"markdown","content":"","frontmatter":{"name":"network-programmer","description":"Multiplayer networking — state replication, lag compensation, matchmaking, network protocol, netcode and bandwidth optimization.","tools":"Read, Glob, Grep, Write, Edit, Bash","model":"inherit","maxTurns":20},"isInternal":false,"tokens":1329,"sizeBytes":6488},{"name":"performance-analyst.md","path":".claude/agents/performance-analyst.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/agents/performance-analyst.md","title":"performance-analyst","category":"subagent-persona","format":"markdown","content":"","frontmatter":{"name":"performance-analyst","description":"Performance analyst — profiling, bottlenecks, memory analysis, frame time investigation, recommends optimizations, tracks metrics over time.","tools":"Read, Glob, Grep, Write, Edit, Bash","model":"inherit","maxTurns":20,"memory":"project"},"isInternal":false,"tokens":1184,"sizeBytes":5335},{"name":"producer.md","path":".claude/agents/producer.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/agents/producer.md","title":"producer","category":"subagent-persona","format":"markdown","content":"","frontmatter":{"name":"producer","description":"Production concerns — sprint planning, milestone tracking, risk, scope, cross-department coordination when multiple departments must synchronize.","tools":"Read, Glob, Grep, Write, Edit, Bash, WebSearch","model":"opus","maxTurns":30,"memory":"project","skills":["scope-check","estimate"]},"isInternal":false,"tokens":1769,"sizeBytes":7890},{"name":"prototyper.md","path":".claude/agents/prototyper.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/agents/prototyper.md","title":"prototyper","category":"subagent-persona","format":"markdown","content":"","frontmatter":{"name":"prototyper","description":"Throwaway builds — concept prototypes after brainstorm to test an idea is fun before GDDs; vertical slices pre-production. Speed over standards.","tools":"Read, Glob, Grep, Write, Edit, Bash","model":"sonnet","maxTurns":25,"isolation":"worktree"},"isInternal":false,"tokens":3410,"sizeBytes":14937},{"name":"qa-lead.md","path":".claude/agents/qa-lead.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/agents/qa-lead.md","title":"qa-lead","category":"subagent-persona","format":"markdown","content":"","frontmatter":{"name":"qa-lead","description":"Test strategy and process — test plan creation, bug severity assessment, regression planning, release quality gates, readiness evaluation.","tools":"Read, Glob, Grep, Write, Edit, Bash","model":"inherit","maxTurns":20,"skills":["bug-report","release-checklist"],"memory":"project"},"isInternal":false,"tokens":1943,"sizeBytes":8541},{"name":"qa-tester.md","path":".claude/agents/qa-tester.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/agents/qa-tester.md","title":"qa-tester","category":"subagent-persona","format":"markdown","content":"","frontmatter":{"name":"qa-tester","description":"Writes test cases, bug reports, and checklists — test case generation, regression checklist creation, execution documentation.","tools":"Read, Glob, Grep, Write, Edit, Bash","model":"inherit","maxTurns":10},"isInternal":false,"tokens":2821,"sizeBytes":11763},{"name":"release-manager.md","path":".claude/agents/release-manager.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/agents/release-manager.md","title":"release-manager","category":"subagent-persona","format":"markdown","content":"","frontmatter":{"name":"release-manager","description":"Release pipeline — certification checklists, store submissions and page prep, platform requirements, version numbering, release-day coordination.","tools":"Read, Glob, Grep, Write, Edit, Bash","model":"inherit","maxTurns":20,"skills":["release-checklist","changelog","patch-notes"]},"isInternal":false,"tokens":1851,"sizeBytes":8474},{"name":"security-engineer.md","path":".claude/agents/security-engineer.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/agents/security-engineer.md","title":"security-engineer","category":"subagent-persona","format":"markdown","content":"","frontmatter":{"name":"security-engineer","description":"Protects against cheating, exploits, breaches — anti-cheat measures, secure save data and network comms, player privacy compliance.","tools":"Read, Glob, Grep, Write, Edit, Bash","model":"inherit","maxTurns":20},"isInternal":false,"tokens":1872,"sizeBytes":8857},{"name":"sound-designer.md","path":".claude/agents/sound-designer.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/agents/sound-designer.md","title":"sound-designer","category":"subagent-persona","format":"markdown","content":"","frontmatter":{"name":"sound-designer","description":"SFX specifications and spec sheets — audio event documentation, mixing parameters, sound category definitions.","tools":"Read, Glob, Grep, Write, Edit","model":"inherit","maxTurns":10,"disallowedTools":"Bash"},"isInternal":false,"tokens":979,"sizeBytes":4527},{"name":"systems-designer.md","path":".claude/agents/systems-designer.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/agents/systems-designer.md","title":"systems-designer","category":"subagent-persona","format":"markdown","content":"","frontmatter":{"name":"systems-designer","description":"Detailed subsystem mechanics — combat formulas, progression curves, crafting recipes, status effect interactions, mathematical modeling of a mechanic.","tools":"Read, Glob, Grep, Write, Edit","model":"inherit","maxTurns":20,"disallowedTools":"Bash","memory":"project"},"isInternal":false,"tokens":1765,"sizeBytes":8163},{"name":"technical-artist.md","path":".claude/agents/technical-artist.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/agents/technical-artist.md","title":"technical-artist","category":"subagent-persona","format":"markdown","content":"","frontmatter":{"name":"technical-artist","description":"Technical artist bridging art and engineering — shaders, VFX, rendering optimization, art pipeline tools, art-to-engine issues.","tools":"Read, Glob, Grep, Write, Edit, Bash","model":"inherit","maxTurns":20},"isInternal":false,"tokens":1378,"sizeBytes":6574},{"name":"technical-director.md","path":".claude/agents/technical-director.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/agents/technical-director.md","title":"technical-director","category":"subagent-persona","format":"markdown","content":"","frontmatter":{"name":"technical-director","description":"High-level technical decisions — engine architecture, technology choices, performance strategy, technical risk, cross-system conflicts.","tools":"Read, Glob, Grep, Write, Edit, Bash, WebSearch","model":"opus","maxTurns":30,"memory":"project"},"isInternal":false,"tokens":1814,"sizeBytes":8292},{"name":"tools-programmer.md","path":".claude/agents/tools-programmer.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/agents/tools-programmer.md","title":"tools-programmer","category":"subagent-persona","format":"markdown","content":"","frontmatter":{"name":"tools-programmer","description":"Internal dev tools — editor extensions, content authoring tools, debug utilities, pipeline automation, editor workflow.","tools":"Read, Glob, Grep, Write, Edit, Bash","model":"inherit","maxTurns":20},"isInternal":false,"tokens":1327,"sizeBytes":6284},{"name":"ue-blueprint-specialist.md","path":".claude/agents/ue-blueprint-specialist.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/agents/ue-blueprint-specialist.md","title":"ue-blueprint-specialist","category":"subagent-persona","format":"markdown","content":"","frontmatter":{"name":"ue-blueprint-specialist","description":"Blueprint architecture and Blueprint/C++ boundary — optimization, maintainable graphs. Prevents Blueprint spaghetti, enforces clean BP patterns.","tools":"Read, Glob, Grep, Write, Edit","model":"sonnet","maxTurns":20,"disallowedTools":"Bash"},"isInternal":false,"tokens":2239,"sizeBytes":10120},{"name":"ue-gas-specialist.md","path":".claude/agents/ue-gas-specialist.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/agents/ue-gas-specialist.md","title":"ue-gas-specialist","category":"subagent-persona","format":"markdown","content":"","frontmatter":{"name":"ue-gas-specialist","description":"Gameplay Ability System — abilities, gameplay effects, attribute sets, tags, ability tasks, prediction. Prevents common GAS anti-patterns.","tools":"Read, Glob, Grep, Write, Edit, Bash","model":"sonnet","maxTurns":20},"isInternal":false,"tokens":2064,"sizeBytes":9646},{"name":"ue-replication-specialist.md","path":".claude/agents/ue-replication-specialist.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/agents/ue-replication-specialist.md","title":"ue-replication-specialist","category":"subagent-persona","format":"markdown","content":"","frontmatter":{"name":"ue-replication-specialist","description":"Unreal networking — property replication, RPCs, client prediction, relevancy, net serialization, bandwidth. Server-authoritative architecture.","tools":"Read, Glob, Grep, Write, Edit, Bash","model":"sonnet","maxTurns":20},"isInternal":false,"tokens":2060,"sizeBytes":9415},{"name":"ue-umg-specialist.md","path":".claude/agents/ue-umg-specialist.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/agents/ue-umg-specialist.md","title":"ue-umg-specialist","category":"subagent-persona","format":"markdown","content":"","frontmatter":{"name":"ue-umg-specialist","description":"Unreal UI implementation — UMG widget hierarchy, data binding, CommonUI input routing, widget styling, UI optimization.","tools":"Read, Glob, Grep, Write, Edit, Bash","model":"sonnet","maxTurns":20},"isInternal":false,"tokens":2183,"sizeBytes":9872},{"name":"ui-programmer.md","path":".claude/agents/ui-programmer.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/agents/ui-programmer.md","title":"ui-programmer","category":"subagent-persona","format":"markdown","content":"","frontmatter":{"name":"ui-programmer","description":"Implements user interface systems — menus, HUDs, inventory screens, dialogue boxes, UI framework code, screen flow.","tools":"Read, Glob, Grep, Write, Edit, Bash","model":"inherit","maxTurns":20},"isInternal":false,"tokens":1418,"sizeBytes":6568},{"name":"unity-addressables-specialist.md","path":".claude/agents/unity-addressables-specialist.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/agents/unity-addressables-specialist.md","title":"unity-addressables-specialist","category":"subagent-persona","format":"markdown","content":"","frontmatter":{"name":"unity-addressables-specialist","description":"Unity asset management — Addressable groups, loading/unloading, content catalogs, remote delivery, asset bundle optimization, fast load times.","tools":"Read, Glob, Grep, Write, Edit, Bash","model":"sonnet","maxTurns":20},"isInternal":false,"tokens":2409,"sizeBytes":11309},{"name":"unity-dots-specialist.md","path":".claude/agents/unity-dots-specialist.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/agents/unity-dots-specialist.md","title":"unity-dots-specialist","category":"subagent-persona","format":"markdown","content":"","frontmatter":{"name":"unity-dots-specialist","description":"Unity Data-Oriented Technology Stack — Entity Component System, Jobs, Burst compiler optimization, hybrid renderer, correct ECS patterns.","tools":"Read, Glob, Grep, Write, Edit, Bash","model":"sonnet","maxTurns":20},"isInternal":false,"tokens":2275,"sizeBytes":10307},{"name":"unity-shader-specialist.md","path":".claude/agents/unity-shader-specialist.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/agents/unity-shader-specialist.md","title":"unity-shader-specialist","category":"subagent-persona","format":"markdown","content":"","frontmatter":{"name":"unity-shader-specialist","description":"Unity rendering — Shader Graph, custom HLSL, VFX Graph, render pipeline customization (URP/HDRP), post-processing within performance budgets.","tools":"Read, Glob, Grep, Write, Edit, Bash","model":"sonnet","maxTurns":20},"isInternal":false,"tokens":2475,"sizeBytes":11103},{"name":"unity-specialist.md","path":".claude/agents/unity-specialist.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/agents/unity-specialist.md","title":"unity-specialist","category":"subagent-persona","format":"markdown","content":"","frontmatter":{"name":"unity-specialist","description":"Authority on Unity-specific patterns and APIs — guides MonoBehaviour vs DOTS/ECS, Unity subsystems including Addressables and Input System.","tools":"Read, Glob, Grep, Write, Edit, Bash, Agent","model":"inherit","maxTurns":20},"isInternal":false,"tokens":2846,"sizeBytes":12823},{"name":"unity-ui-specialist.md","path":".claude/agents/unity-ui-specialist.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/agents/unity-ui-specialist.md","title":"unity-ui-specialist","category":"subagent-persona","format":"markdown","content":"","frontmatter":{"name":"unity-ui-specialist","description":"Unity UI implementation — UI Toolkit (UXML/USS), UGUI Canvas, data binding, runtime UI performance, cross-platform adaptation.","tools":"Read, Glob, Grep, Write, Edit, Bash","model":"sonnet","maxTurns":20},"isInternal":false,"tokens":2680,"sizeBytes":12081},{"name":"unreal-specialist.md","path":".claude/agents/unreal-specialist.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/agents/unreal-specialist.md","title":"unreal-specialist","category":"subagent-persona","format":"markdown","content":"","frontmatter":{"name":"unreal-specialist","description":"Authority on Unreal-specific patterns and APIs — guides Blueprint vs C++, UE subsystems (GAS, Enhanced Input, Niagara, etc.).","tools":"Read, Glob, Grep, Write, Edit, Bash, Agent","model":"inherit","maxTurns":20},"isInternal":false,"tokens":2671,"sizeBytes":11930},{"name":"ux-designer.md","path":".claude/agents/ux-designer.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/agents/ux-designer.md","title":"ux-designer","category":"subagent-persona","format":"markdown","content":"","frontmatter":{"name":"ux-designer","description":"User experience flows, interaction design, information architecture — user flow mapping, interaction pattern design, onboarding, accessibility requirements.","tools":"Read, Glob, Grep, Write, Edit, WebSearch","model":"inherit","maxTurns":20,"disallowedTools":"Bash","memory":"project"},"isInternal":false,"tokens":1213,"sizeBytes":5627},{"name":"world-builder.md","path":".claude/agents/world-builder.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/agents/world-builder.md","title":"world-builder","category":"subagent-persona","format":"markdown","content":"","frontmatter":{"name":"world-builder","description":"World builder for lore — factions, cultures, history, geography, ecology, world rules. Faction design, lore consistency checks.","tools":"Read, Glob, Grep, Write, Edit","model":"inherit","maxTurns":20,"disallowedTools":"Bash","memory":"project"},"isInternal":false,"tokens":1421,"sizeBytes":6595},{"name":"writer.md","path":".claude/agents/writer.md","rawUrl":"https://raw.githubusercontent.com/Donchitos/Claude-Code-Game-Studios/HEAD/.claude/agents/writer.md","title":"writer","category":"subagent-persona","format":"markdown","content":"","frontmatter":{"name":"writer","description":"Writer of player-facing text — dialogue, lore entries, item and ability descriptions, environmental text.","tools":"Read, Glob, Grep, Write, Edit","model":"inherit","maxTurns":20,"disallowedTools":"Bash","memory":"project"},"isInternal":false,"tokens":1431,"sizeBytes":6628}],"systemPromptSnippet":"\n\n# Claude Code Game Studios -- Game Studio Agent Architecture\n\nIndie game development managed through 49 coordinated Claude Code subagents.\nEach agent owns a specific domain, enforcing separation of concerns and quality.\n\n## Technology Stack\n\n- **Engine**: [CHOOSE: Godot 4 / Unity / Unreal Engine 5]\n- **Language**: [CHOOSE: GDScript / C# / C++ / Blueprint]\n- **Version Control**: Git with trunk-based development\n- **Build System**: [SPECIFY after choosing engine]\n- **Asset Pipeline**: [SPECIFY after choosing engine]\n\n> **Note**: Engine-specialist agents exist for Godot, Unity, and Unreal with\n> dedicated sub-specialists. Use the set matching your engine.\n\n## Project Structure\n\n@.claude/docs/directory-structure.md\n\n## Engine Version Reference\n\n\n@docs/engine-reference/godot/VERSION.md\n\n\n## Technical Preferences\n\n`project.yaml` at the repo root is the primary config store — engine, specialists,\nnaming, platform, performance, modes. Skills resolve it via `resolve_config`\n(see `.claude/docs/config-resolution.md`).\n\n`.claude/docs/technical-preferences.md` is the **legacy fallback**, read on demand\nwhen a key is absent from `project.yaml`. It is not imported here: before\n`/setup-engine` runs it is almost entirely `[TO BE CONFIGURED]` placeholders, and\nafter it runs `project.yaml` holds the real values.\n\n## Coordination Rules\n\n@.claude/docs/coordination-rules.md\n\n## Collaboration Protocol\n\n**User-driven collaboration, not autonomous execution.**\nEvery task follows: **Question -> Options -> Decision -> Draft -> Approval**\n\n- Agents MUST ask \"May I write this to [filepath]?\" before using Write/Edit tools\n (exempt: `active.md` appends, agent memory, a subagent's new file at the path\n its orchestrating skill named; see `.claude/rules/agent-memory.md`)\n- Agents MUST show drafts or summaries before requesting approval\n- Multi-file changes require explicit approval for the full changeset\n- No commits without user instruction\n- A skipped or dismissed question is not an answer: act on nothing, re-ask in\n plain text and wait\n- Started outside this file's folder? Warn first: hooks, deny rules and the\n ask-first mode load only when Claude Code starts here\n\nSee `docs/COLLABORATIVE-DESIGN-PRINCIPLE.md` for full protocol and examples.\n\n> **First session?** If the project has no engine configured and no game concept,\n> run `/start` to begin the guided onboarding flow.\n\n## Coding Standards\n\n@.claude/docs/coding-standards.md\n\n## Context Management\n\nRead `.claude/docs/context-management.md` on demand — it is a reference, not\nsession context. Two of its conventions are load-bearing and cited by name\nelsewhere in the repo, so they are restated here rather than lost:\n\n- **`production/session-state/active.md` is the session checkpoint.** The file is\n the memory, not the conversation. Read it first after any compaction, crash, or\n `/clear`.\n- **Helpers in `.claude/scripts/` emit observations, never verdicts.** A script\n that scores or judges will eventually contradict a mode or override it cannot\n see. (Cited by `artifact-check.sh` and `adr-dep-graph.sh`.)\n\n\n# Design Directory\n\nWhen authoring or editing files in this directory, follow these standards.\n\n## GDD Files (`design/gdd/`)\n\nThe 8 GDD sections, in order:\n1. Overview — one-paragraph summary\n2. Player Fantasy — intended feeling and experience\n3. Detailed Rules — unambiguous mechanics\n4. Formulas — all math defined with variables\n5. Edge Cases — unusual situations handled\n6. Dependencies — other systems listed\n7. Tuning Knobs — configurable values identified\n8. Acceptance Criteria — testable success conditions\n\n**How many are REQUIRED depends on `modes.workflow`** — all 8 at `full`; 5 at\n`standard` (Overview, Detailed Rules, Edge Cases, Dependencies, Acceptance\nCriteria, plus Formulas when the system has math); none at `minimal`, where\n`design/game-brief.md` is the design record instead of a GDD. Resolve the tier\nbefore flagging a section as missing — see `.claude/docs/workflow-modes.md`.\n\n> **Three other places already encode the tier rule** —\n> `.claude/docs/coding-standards.md`, `.claude/rules/design-docs.md` and\n> `.claude/hooks/validate-commit.sh`. This file is the copy a session working in\n> `design/` reads first, so it must agree with them: demanding all 8 at\n> `minimal` warns a jam project about six sections its own configuration says it\n> does not need, which trains the user to ignore the warning.\n\n**Section-name alias:** the GDD template and `/design-system` author section 3\nas `## Detailed Design`; the standard calls it **Detailed Rules**. Same required\nsection — accept either heading, never rewrite one into the other.\n\n**File naming:** `[system-slug].md` (e.g. `movement-system.md`, `combat-system.md`)\n\n**Systems index:** `design/gdd/systems-index.md` — update when adding a new GDD.\n\n**Design order:** Foundation → Core → Feature → Presentation → Polish\n\n**Validation:** Run `/design-review [path]` after authoring any GDD.\nRun `/review-all-gdds` after completing a set of related GDDs.\n\n## Quick Specs (`design/quick-specs/`)\n\nLightweight specs for tuning changes, minor mechanics, or balance adjustments.\nUse `/quick-design` to author.\n\n## UX Specs (`design/ux/`)\n\n- Per-screen specs: `design/ux/[screen-name].md`\n- HUD design: `design/ux/hud.md`\n- Interaction pattern library: `design/ux/interaction-patterns.md`\n- Accessibility requirements: `design/accessibility-requirements.md`\n\nUse `/ux-design` to author. Validate with `/ux-review` before passing to `/team-ui`.\n\n> **Accessibility requirements sit OUTSIDE `design/ux/` on purpose.** They are a\n> project-wide standard the per-screen specs consult, not a spec for one screen.\n> `.claude/docs/workflow-catalog.yaml`, the Pre-Production, Production and Polish\n> gates, and `/architecture-review` all check `design/accessibility-requirements.md`\n> at that exact path. Do not \"tidy\" it under `design/ux/` — every one of those\n> checks would stop matching, and the Technical Setup → Pre-Production gate would\n> become unpassable. `/ux-design` states the same rule at its `accessibility` mode.\n\n\n# Docs Directory\n\nWhen authoring or editing files in this directory, follow these standards.\n\n## Architecture Decision Records (`docs/architecture/`)\n\nUse the ADR template: `.claude/docs/templates/architecture-decision-record.md`\n\n**Required sections:** Title, Status, Context, Decision, Consequences,\nADR Dependencies, Engine Compatibility, GDD Requirements Addressed\n\n**Status lifecycle:** `Proposed` → `Accepted` → `Superseded`\n- Never skip `Accepted` — stories referencing a `Proposed` ADR are auto-blocked\n- Use `/architecture-decision` to create ADRs through the guided flow\n\n**TR Registry:** `docs/architecture/tr-registry.yaml`\n- Stable requirement IDs (e.g. `TR-movement-001`) that link GDD requirements to stories\n- Never renumber existing IDs — only append new ones\n- Updated by `/architecture-review` Phase 8\n\n**Control Manifest:** `docs/architecture/control-manifest.md`\n- Flat programmer rules sheet: Required / Forbidden / Guardrails per layer\n- Date-stamped `Manifest Version:` in header\n- Stories embed this version; `/story-done` checks for staleness\n\n**Validation:** Run `/architecture-review` after completing a set of ADRs.\n\n## Engine Reference (`docs/engine-reference/`)\n\nVersion-pinned engine API snapshots. **Always check here before using any\nengine API** — the LLM's training data predates the pinned engine version.\n\nCurrent engine: see `docs/engine-reference//VERSION.md` (`` is `godot`, `unity` or `unreal`, matching `engine.name` in `project.yaml`)\n\n\n# Source Directory\n\nWhen writing or editing game code in this directory, follow these standards.\n\n## Engine Version Warning\n\nThe LLM's training data predates the pinned engine version.\n**Always check `docs/engine-reference/` before using any engine API.**\nDo not guess at post-cutoff API signatures — look them up first.\n\n## Coding Standards\n\n- All public APIs require doc comments\n- Gameplay values must be **data-driven** (external config files), never hardcoded\n- Prefer dependency injection over singletons for testability\n- Architecture decisions go in `docs/architecture/` as ADRs — **how many depends on\n `modes.workflow`**: all at `full`, critical only at `standard`, none required at\n `minimal` (the decision log carries them)\n- Commits must reference the relevant story ID or design document\n\n## File Routing\n\nMatch the engine-specialist agent to the file type being written.\n`/setup-engine` records which specialist handles code, shaders and UI in the\n`specialists` block of `project.yaml`.\n\nWhen in doubt, use `specialists.code` from `project.yaml`.\n\n## Tests\n\nTests live in `tests/` — not in `src/`.\nRun `/test-setup` to scaffold the test framework if it doesn't exist yet.\nEvery gameplay system should have unit tests covering its formulas and edge cases.\n\n## Verification-Driven Development\n\nWrite tests first when adding gameplay systems.\nFor UI changes, verify with screenshots.\nCompare expected output to actual output before marking work complete.\n\n\n# Studio Tests — Claude Instructions\n\nThis folder is the quality assurance layer for the Claude Code Game Studios skill/agent\nframework. It is self-contained and separate from any game project.\n\n## Key files\n\n| File | Purpose |\n|------|---------|\n| `catalog.yaml` | Master registry for all 74 skills and 49 agents. Contains category, spec path, and last-test tracking fields. Always read this first when running any test command. |\n| `quality-rubric.md` | Category-specific pass/fail metrics. Read the matching `###` section for the skill's category when running `/skill-test category`. |\n| `skills/[category]/[name].md` | Behavioral spec for a skill — 5 or more test cases + protocol compliance assertions. |\n| `agents/[tier]/[name].md` | Behavioral spec for an agent — 5 or more test cases + protocol compliance assertions. |\n| `templates/skill-test-spec.md` | Template for writing new skill spec files. |\n| `templates/agent-test-spec.md` | Template for writing new agent spec files. |\n| `results/` | Written by `/skill-test spec` when results are saved. Not gitignored — add it to `.gitignore` to keep results out of commits. |\n\n## Path conventions\n\n- Skill specs: `studio-tests/skills/[category]/[name].md`\n- Agent specs: `studio-tests/agents/[tier]/[name].md`\n- Catalog: `studio-tests/catalog.yaml`\n- Rubric: `studio-tests/quality-rubric.md`\n\nThe `spec:` field in `catalog.yaml` is the authoritative path for each skill/agent spec.\nAlways read it rather than guessing the path.\n\n## Skill categories\n\n```\ngate → gate-check\nreview → design-review, architecture-review, review-all-gdds\nauthoring → design-system, quick-design, architecture-decision, art-bible,\n create-architecture, ux-design, ux-review\nreadiness → story-readiness, story-done\npipeline → create-epics, create-stories, dev-story, create-control-manifest,\n propagate-design-change, map-systems, vertical-slice\nanalysis → consistency-check, balance-check, content-audit, code-review,\n tech-debt, scope-check, estimate, perf-profile, asset-audit,\n security-audit, test-evidence-review, test-flakiness\nteam → team-combat, team-narrative, team-audio, team-level, team-ui,\n team-qa, team-release, team-polish, team-live-ops\nsprint → sprint-plan, sprint-status, milestone-review, retrospective,\n changelog, patch-notes\nutility → all remaining skills\n```\n\n## Agent tiers\n\n```\ndirectors → creative-director, technical-director, producer, art-director\nleads → lead-programmer, narrative-director, audio-director, game-designer,\n systems-designer, level-designer, qa-lead\nspecialists → gameplay-programmer, engine-programmer, network-programmer,\n ai-programmer, tools-programmer, ui-programmer, ux-designer,\n technical-artist, sound-designer, performance-analyst, prototyper,\n writer, world-builder\nengine/godot → godot-specialist, godot-gdscript-specialist, godot-csharp-specialist,\n godot-shader-specialist, godot-gdextension-specialist\nengine/unity → unity-specialist, unity-ui-specialist, unity-shader-specialist,\n unity-dots-specialist, unity-addressables-specialist\nengine/unreal → unreal-specialist, ue-gas-specialist, ue-replication-specialist,\n ue-umg-specialist, ue-blueprint-specialist\noperations → devops-engineer, release-manager, live-ops-designer,\n community-manager, analytics-engineer, economy-designer,\n localization-lead\nqa → qa-tester, security-engineer, accessibility-specialist\n```\n\nA tier is the directory a spec lives in. The rubric category is the agent's\n`category:` in `catalog.yaml` and can differ: `security-engineer` and\n`accessibility-specialist` sit in `qa/` but are rated as `specialist`.\n\n## Workflow for testing a skill or agent\n\n1. Read `catalog.yaml` to get the `spec:` path and `category:` — from the\n `skills:` entry for a skill, the `agents:` entry for an agent\n2. Read the skill at `.claude/skills/[name]/SKILL.md` and every file in its\n `references/` folder, or the agent at `.claude/agents/[name].md`\n3. Read the project `CLAUDE.md` and the files it imports with `@`: every\n subagent receives them, so a rule stated there (for example a redirect in\n `coordination-rules.md`) counts as the skill's or agent's own\n4. Read the spec at the `spec:` path\n5. Evaluate the spec's Static Assertions, each case's assertions, and its\n Protocol Compliance list\n6. Offer to write results to `results/` and update `catalog.yaml`\n\n## Fixture defaults\n\nEvery skill spec has a `## Fixture Defaults` section above its cases. A case's\nsandbox project starts from this `project.yaml` block:\n\n```yaml\nmodes:\n rigor: minimal # → workflow minimal, docs.density terse, qa.level minimal,\n # story_granularity coarse, review_mode solo, team.size individual\n automation: collaborative\n```\n\n- A setting the case's Fixture names wins over the block, and an explicit\n sub-knob (`modes.workflow`, `modes.review_mode`, `qa.level`, …) wins over the\n `rigor` preset (`.claude/docs/config-resolution.md` § Defaults).\n- A case that says `project.yaml` sets no `modes` keys, or that there is no\n `project.yaml`, runs without the block: it tests the unset defaults.\n- There is no `project.local.yaml` unless the case names one.\n- A case whose expected behaviour changes with a setting pins that setting in\n its own Fixture, with the reason — e.g. `modes.workflow: standard` (pinned:\n unset resolves to minimal, which recommends the next build instead of a\n sprint).\n\nThe block is pinned so that a change to the framework's defaults cannot\nsilently change what a case tests. A spec may set a different default in its\nown section when most of its cases need one.\n\n## Workflow for improving a skill\n\nUse `/skill-improve [name]`. It handles the full loop:\ntest → diagnose → propose fix → rewrite → retest → keep or revert.\n\n## Spec validity note\n\nSpecs in this folder assert the **correct** behavior, not whatever a skill or agent\ndoes today. A failing assertion means the skill or agent is wrong until shown\notherwise: fix it and re-run, and never weaken an assertion just so it passes.\nSpecs can be wrong too — when one asserts behavior that is itself incorrect,\ncorrect the spec toward the right behavior, not toward what the skill currently does.\n\n## This folder is deletable\n\nNothing in `.claude/` imports from here, and every other CCGS skill and agent works\nwithout it — but `/skill-test` and `/skill-improve` read it by path. Without it,\n`/skill-test static` still works, `/skill-test spec` and `/skill-test category`\nstop working, `/skill-test audit` reports that no catalog exists, and\n`/skill-improve` skips its category checks (the table in `README.md` has the detail).\n\n\n---\npaths:\n - \".claude/agent-memory/**\"\n---\n\n# Agent Memory Rules\n\n**Agent memory is one of three writes that need no \"May I write?\"** The other two\nare named in `CLAUDE.md`:\n\n- **Appends to `production/session-state/active.md`** — the session checkpoint\n the hooks and the next session rely on. An append, never a rewrite of what is\n already there.\n- **A subagent's new file at the path its orchestrating skill named.** Only a\n new file under `production/`, `docs/` or `tests/`, only at a path the skill's\n prompt names (never one you chose), and only inside a phase the user approved.\n\n`.claude/agent-memory/` is gitignored, per-agent, and never ships. Its exemption\nexists because the memory is the agent's own working notes about how to do its\njob, not a project artifact.\n\nNone of the three extends anywhere else. The Collaboration Protocol still governs\nevery other write under the code root (`src/`, `Assets/` or `Source/`),\n`design/`, `docs/`, `production/` and `assets/`: ask first, naming the path.\nWriting a memory is never a substitute for asking, and a memory must never be\nused to record something the user declined to have written.\n\n## Never record a temporary absence as a durable fact\n\nThis is the failure this file exists to prevent, and this repo is unusually\nexposed to it.\n\n**CCGS ships as a template the user clones *as their game*.** So on day one every\nagent observes the same things — no game code, no GDDs, no engine configured, no\n`tests/performance/` — and every one of those observations is **guaranteed to\nstop being true**. A memory reading *\"this repo is the framework, not a game;\nperf requests have no target\"* is accurate when written and actively harmful two\nweeks later, when it tells a future run to return BLOCKED on a project that now\nhas a build. The agent will not re-derive it; that is what memory is for.\n\nSo:\n\n- **Prefer recording a method over a state.** \"Confirm an engine project and a\n captured profile exist before profiling; return BLOCKED naming what is missing\n rather than estimating\" is durable. \"There is no game here\" is a timestamp.\n- **If you must record a state, state what invalidates it**, on the same line:\n `INVALIDATED WHEN: project.yaml declares an engine, or the code root (src/, Assets/ or Source/) contains game code.`\n A reader with no other context must be able to tell whether the note still\n holds.\n- **Never record absence of a game, of assets, of tests or of config as a\n settled property of the project.** Those are the states CCGS exists to move a\n user out of.\n\n## Disclose the write\n\nSay in your response that you recorded a memory and where. An unmentioned write\nis indistinguishable from no write, and the user cannot correct a note they do\nnot know exists — the same reason a skipped check has to announce itself\n(`.claude/rules/skill-authoring.md`, obligation 3).\n\n## Verify before you trust\n\nA recalled memory reflects what was true when it was written. If it names a file,\na path, a setting or a count, **check that it still holds before acting on it**.\nMemory is a starting point for investigation, never evidence.\n\n\n---\npaths:\n - \"src/ai/**\"\n - \"Assets/**/{AI,Ai,ai}/**/*.cs\"\n - \"Source/**/{AI,Ai,ai}/**/*.{h,cpp}\"\n---\n\n# AI Code Rules\n\n- AI update budget: 2ms per frame maximum — profile to verify\n- All AI parameters must be tunable from data files (behavior tree weights, perception ranges, timers)\n- AI must be debuggable: implement visualization hooks for all AI state (paths, perception cones, decision trees)\n- AI should telegraph intentions — players need time to read and react\n- Prefer utility-based or behavior tree approaches over hard-coded if/else chains\n- Group AI must support formation, flanking, and role assignment from data\n- All AI state machines must log transitions for debugging\n- Never trust AI input from the network without validation\n\n\n---\npaths:\n - \"assets/data/**/*.json\"\n - \"Assets/**/{Data,data}/**/*.json\"\n - \"Content/**/{Data,data}/**/*.json\"\n---\n\n# Data File Rules\n\n- All JSON files must be valid JSON — broken JSON blocks the entire build pipeline\n- File naming: lowercase with underscores only, following `[system]_[name].json` pattern\n- Every data file must have a documented schema (either JSON Schema or documented in the corresponding design doc)\n- Numeric values must include comments or companion docs explaining what the numbers mean\n- Use consistent key naming: **`snake_case` for keys within JSON files**, matching\n the `[system]_[name].json` file convention one line above and the engine idiom\n every other standard in this repo uses.\n\n > **On Unity and Unreal this costs you a mapping layer — budget for it rather\n > than changing the keys.** `JsonUtility` binds by *exact field name*, and C#\n > fields are `camelCase` per `naming.variables`, so a snake_case file cannot bind\n > directly to the type that consumes it. Use a private nested DTO whose fields\n > are the wire format and which maps once into your real type, or take a\n > dependency that supports a naming policy (Newtonsoft `SnakeCaseNamingStrategy`,\n > `System.Text.Json` `JsonNamingPolicy`). Do **not** switch the file to camelCase\n > to avoid the DTO: keys are the cross-engine contract. Write the DTO and\n > document it as a wire-format boundary — that is the intended shape.\n- No orphaned data entries — every entry must be referenced by code or another data file\n- Version data files when making breaking schema changes\n- Include sensible defaults for all optional fields\n\n## Examples\n\n**Correct** naming and structure (`combat_enemies.json`):\n\n```json\n{\n \"goblin\": {\n \"base_health\": 50,\n \"base_damage\": 8,\n \"move_speed\": 3.5,\n \"loot_table\": \"loot_goblin_common\"\n },\n \"goblin_chief\": {\n \"base_health\": 150,\n \"base_damage\": 20,\n \"move_speed\": 2.8,\n \"loot_table\": \"loot_goblin_rare\"\n }\n}\n```\n\n**Incorrect** (`EnemyData.json`):\n\n```json\n{\n \"Goblin\": { \"hp\": 50 }\n}\n```\n\nViolations: uppercase filename, uppercase key, no `[system]_[name]` pattern, missing required fields.\n\n\n---\npaths:\n - \"design/gdd/**\"\n---\n\n# Design Document Rules\n\n- The 8 GDD sections are: Overview, Player Fantasy, Detailed Rules, Formulas, Edge Cases, Dependencies, Tuning Knobs, Acceptance Criteria\n- **How many are required depends on `modes.workflow`** — all 8 at `full`, 5 (+ Formulas when the system **defines numeric rules**: rates, curves, thresholds, costs, damage, drop weights — anything a balance pass would tune) at `standard`, none at `minimal` (the design record there is `design/game-brief.md`). Resolve the tier before flagging a section as missing; see `.claude/docs/workflow-modes.md`\n- **The Formulas test is what the system defines, not what it is called.** A system's `Category` in `systems-index.md` is a hint — `Gameplay`, `Economy` and `Progression` almost always qualify — never the test. Do not gate Formulas on a category token: the categories `/map-systems` writes (`Core · Gameplay · Progression · Economy · Persistence · UI · Audio · Narrative · Meta`) do not include `combat` or `AI`, which are example systems *within* `Gameplay`. Every site stating this rule must state the same test.\n- **Section-name alias**: The GDD template and `/design-system` author this section as `## Detailed Design`; the design standard calls it **Detailed Rules**. These are the SAME required section — accept either heading and never rewrite one into the other.\n- Formulas must include variable definitions, expected value ranges, and example calculations\n- Edge cases must explicitly state what happens, not just \"handle gracefully\"\n- Dependencies must be bidirectional — if system A depends on B, B's doc must mention A\n- Tuning knobs must specify safe ranges and what gameplay aspect they affect\n- Acceptance criteria must be testable — a QA tester must be able to verify pass/fail\n- No hand-waving: \"the system should feel good\" is not a valid specification\n- Balance values must link to their source formula or rationale\n- Design documents MUST be written incrementally: create skeleton first, then fill\n each section one at a time with user approval between sections. Write each\n approved section to the file immediately to persist decisions and manage context\n\n\n---\npaths:\n - \"src/core/**\"\n - \"Assets/**/{Core,core}/**/*.cs\"\n - \"Source/**/{Core,core}/**/*.{h,cpp}\"\n---\n\n# Engine Code Rules\n\n- ZERO allocations in hot paths (update loops, rendering, physics) — pre-allocate, pool, reuse\n- All engine APIs must be thread-safe OR explicitly documented as single-thread-only\n- Profile before AND after every optimization — document the measured numbers\n- Engine code must NEVER depend on gameplay code (strict dependency direction: engine <- gameplay)\n- Every public API must have usage examples in its doc comment\n- Changes to public interfaces require a deprecation period and migration guide\n- Use RAII / deterministic cleanup for all resources\n- All engine systems must support graceful degradation\n- Before writing engine API code, consult `docs/engine-reference/` for the current engine version and verify APIs against the reference docs\n\n## Examples\n\n**Correct** (zero-alloc hot path) — Godot:\n\n```gdscript\n# Pre-allocated array reused each frame\nvar _nearby_cache: Array[Node3D] = []\n\nfunc _physics_process(delta: float) -> void:\n _nearby_cache.clear() # Reuse, don't reallocate\n _spatial_grid.query_radius(position, radius, _nearby_cache)\n```\n\nUnity:\n\n```csharp\nprivate readonly Collider[] _nearbyCache = new Collider[64]; // allocated once\n\nvoid FixedUpdate()\n{\n int count = Physics.OverlapSphereNonAlloc(transform.position, radius, _nearbyCache);\n}\n```\n\nUnreal:\n\n```cpp\n// TArray member, reserved once; Reset() keeps the allocation\nvoid UProximityComponent::TickComponent(float DeltaTime, ELevelTick TickType,\n FActorComponentTickFunction* ThisTickFunction)\n{\n NearbyCache.Reset();\n SpatialGrid->QueryRadius(GetComponentLocation(), Radius, NearbyCache);\n}\n```\n\n**Incorrect** (allocating in hot path):\n\n```gdscript\nfunc _physics_process(delta: float) -> void:\n var nearby: Array[Node3D] = [] # VIOLATION: allocates every frame\n nearby = get_tree().get_nodes_in_group(\"enemies\") # VIOLATION: tree query every frame\n```\n\n\n---\npaths:\n - \"src/gameplay/**\"\n - \"Assets/**/{Gameplay,gameplay}/**/*.cs\"\n - \"Source/**/{Gameplay,gameplay}/**/*.{h,cpp}\"\n---\n\n# Gameplay Code Rules\n\n- ALL gameplay values MUST come from external config/data files, NEVER hardcoded\n- Use delta time for ALL time-dependent calculations (frame-rate independence)\n- NO direct references to UI code — use events for cross-system communication\n (Godot signals, C# events, Unreal delegates)\n- Every gameplay system must implement a clear interface\n- State machines must have explicit transition tables with documented states\n- Write unit tests for all gameplay logic — separate logic from presentation\n- Document which design doc each feature implements in code comments\n- No static singletons for game state — use dependency injection\n\n## Examples\n\n**Correct** (data-driven) — Godot:\n\n```gdscript\nvar damage: float = config.get_value(\"combat\", \"base_damage\", 10.0)\nvar speed: float = stats_resource.movement_speed * delta\n```\n\nUnity (values from a ScriptableObject):\n\n```csharp\nfloat damage = combatConfig.BaseDamage;\nfloat speed = stats.MovementSpeed * Time.deltaTime;\n```\n\nUnreal (values from a data asset):\n\n```cpp\nconst float Damage = CombatConfig->BaseDamage;\nconst float Speed = Stats->MovementSpeed * DeltaTime;\n```\n\n**Incorrect** (hardcoded):\n\n```gdscript\nvar damage: float = 25.0 # VIOLATION: hardcoded gameplay value\nvar speed: float = 5.0 # VIOLATION: not from config, not using delta\n```\n\n\n---\npaths:\n - \"design/narrative/**\"\n---\n\n# Narrative Rules\n\n- All new lore must be cross-referenced against existing lore for contradictions\n- Every lore entry must specify canon level: Established / Provisional / Under Review\n- Character dialogue must match the voice profile defined for that character\n- World rules (what is possible/impossible) must be explicitly documented and consistent\n- Mysteries must have documented \"true answers\" even if players never learn them\n- Faction motivations, relationships, and power structures must be internally logical\n- All narrative text must be localization-ready: no idioms that don't translate, named placeholders for variables\n- No line of dialogue should exceed 120 characters for dialogue box constraints\n\n\n---\npaths:\n - \"src/networking/**\"\n - \"Assets/**/{Networking,networking,Network,network}/**/*.cs\"\n - \"Source/**/{Networking,networking,Network,network}/**/*.{h,cpp}\"\n---\n\n# Network Code Rules\n\n- Server is AUTHORITATIVE for all gameplay-critical state — never trust the client\n- All network messages must be versioned for forward/backward compatibility\n- Client predicts locally, reconciles with server — implement rollback for mispredictions\n- Handle disconnection, reconnection, and host migration gracefully\n- Rate-limit all network logging to prevent log flooding\n- All networked values must specify replication strategy: reliable/unreliable, frequency, interpolation\n- Bandwidth budget: define and track per-message-type bandwidth usage\n- Security: validate all incoming packet sizes and field ranges\n\n\n---\npaths:\n - \"prototypes/**\"\n---\n\n# Prototype Code Standards (Relaxed)\n\nPrototypes are throwaway code for validating ideas. Standards are intentionally\nrelaxed to maximize iteration speed. The goal is learning, not production quality.\n\n## What's Allowed in Prototypes\n- Hardcoded values (no need for data-driven config)\n- Minimal or no doc comments\n- Simple architecture (no dependency injection required)\n- Singletons and global state\n- Copy-pasted code (no need for abstraction)\n- Debug output left in place\n- Placeholder art and audio\n- Quick-and-dirty solutions\n\n## What's Still Required\n- Each prototype lives in its own subdirectory: `prototypes/[name]/`\n- Every prototype MUST have a `README.md` with:\n - What hypothesis is being tested\n - How to run the prototype\n - Current status (in-progress / concluded)\n - Findings (updated when prototype concludes)\n- No production code may reference or import from `prototypes/`\n- Prototypes must not modify files outside `prototypes/`\n- Prototypes must not be deployed or shipped\n\n## When a Prototype Succeeds\nIf a prototype validates a concept and the feature moves to production:\n1. The prototype code is NOT migrated directly — it is rewritten to production standards\n2. The prototype `README.md` findings inform the production design document\n3. The prototype directory is preserved for reference but never extended\n\n## Cleanup\nConcluded prototypes should be archived or deleted after findings are captured.\nNever let prototype code grow into production code through incremental \"cleanup.\"\n\n\n---\npaths:\n - \"**/*.tscn\"\n - \"**/*.tres\"\n - \"**/*.unity\"\n - \"**/*.prefab\"\n - \"Assets/**/*.asset\"\n---\n\n# Scene and Asset File Rules\n\nThe engine's editor writes these files. A hand edit that breaks one can stop a\nscene loading, or drop references without an error. Change them in the editor\nwhen you can.\n\n## Godot (`.tscn`, `.tres`, `.uid`)\n\nWhen you edit the text by hand:\n\n- Never change the `format=` value in the `[gd_scene]` or `[gd_resource]` header.\n- Never reuse an `id`: every `[ext_resource]` and `[sub_resource]` id is unique in its file.\n- Never copy a node block with its `unique_id=` (Godot 4.6+). Drop it from the copy.\n- Never invent a `uid://` value. Leave `uid=` off a new reference and let the\n editor or `godot --headless --path . --import` assign it.\n- Never hand-edit TileMapLayer or GridMap cell data. It is encoded, so change it in the editor.\n- Never edit or delete a `.uid` file, and commit it with its script or shader.\n Godot 4.4+ writes one beside each; when you move or rename the script or\n shader outside the editor, move its `.uid` with it.\n- After a hand edit, run `godot --headless --path . --import` and open or run\n the scene once to confirm it loads without errors.\n\n## Unity (`.unity`, `.prefab`, `.asset`)\n\n- Never hand-edit `.unity`, `.prefab` or `.asset` YAML while a Unity Editor is\n reachable: open on this project, or reachable through its command-line or MCP\n tools. The Editor holds its own copy, and its next save can overwrite or\n conflict with the edit. Make the change through the Editor, or hand the user\n the steps. If you cannot tell whether an Editor is reachable, treat it as reachable.\n- With no Editor reachable, keep every `fileID` and `guid` reference intact,\n never invent a GUID, never edit or delete a `.meta` file, and open the scene\n in the Editor afterwards to confirm it loads.\n\n\n---\npaths:\n - \"assets/shaders/**\"\n - \"**/*.gdshader\"\n - \"Assets/**/*.{shader,hlsl,cginc,compute,shadergraph}\"\n - \"Shaders/**\"\n - \"**/*.{usf,ush}\"\n---\n\n# Shader Code Standards\n\nAll shader files, in every engine, must follow these standards to maintain\nvisual quality, performance, and cross-platform compatibility.\n\n## Naming Conventions\n- File naming: `[type]_[category]_[name].[ext]`\n - `spatial_env_water.gdshader` (Godot)\n - `SG_Env_Water` (Unity Shader Graph)\n - `M_Env_Water` (Unreal Material)\n- Use descriptive names that indicate the material purpose\n- Prefix with the engine's shader type — Godot `spatial_`, `canvas_`, `particles_`,\n `post_`; Unity `SG_` (Shader Graph); Unreal `M_`, `MI_` (instance), `MF_` (function)\n\n## Code Quality\n- All uniforms/parameters must have descriptive names and appropriate hints\n- Group related parameters (Godot: `group_uniforms`, Unity: `[Header]`, Unreal: Category)\n- Comment non-obvious calculations (especially math-heavy sections)\n- No magic numbers — use named constants or documented uniform values\n- Include authorship and purpose comment at the top of each shader file\n\n## Performance Requirements\n- Document the target platform and complexity budget for each shader\n- Use appropriate precision: `half`/`mediump` on mobile where full precision isn't needed\n- Minimize texture samples in fragment shaders\n- Avoid dynamic branching in fragment shaders — use `step()`, `smoothstep()` and\n `mix()` (Godot, GLSL) or `lerp()` (HLSL: Unity, Unreal)\n- No texture reads inside loops\n- Two-pass approach for blur effects (horizontal then vertical)\n\n## Cross-Platform\n- Test shaders on minimum spec target hardware\n- Provide fallback/simplified versions for lower quality tiers\n- Document which render pipeline the shader targets (Forward/Deferred, URP/HDRP, Forward+/Mobile/Compatibility)\n- Do not mix shaders from different render pipelines in the same directory\n\n## Variant Management\n- Minimize shader variants — each variant is a separate compiled shader\n- Document all keywords/variants and their purpose\n- Use feature stripping where possible to reduce build size\n- Log and monitor total variant count per shader\n\n\n---\npaths:\n - \".claude/skills/**\"\n - \".claude/agents/**\"\n---\n\n# Skill and Gate Authoring\n\n**A check that cannot report that it did not run is not a check.**\n\nThe same shape recurs across unrelated subsystems, so treat it as the default\nrisk in any check you write, not as an unusual mistake.\n\nThe failure is always the same trade: a step that could not run produces output\nindistinguishable from a step that ran and found nothing. Nobody reading the\noutput can tell which happened, and the permissive reading is the one that gets\nbelieved, because it is the one that lets work proceed.\n\n## The five obligations\n\n### 1. Every gating verdict needs a \"could not assess\" value\n\nIf a skill emits a verdict something else depends on, its vocabulary must include\none — `NOT ASSESSED`, or the local equivalent — and the report must say *which*\nof the reasons applied. A vocabulary of three confident verdicts forces every\nunknown into a claim.\n\n**Rank it deliberately.** It must outrank the pass value: a run that could not\nassess part of its scope has not established that the scope is good. It must\n**not** outrank the failure values: a known problem is more actionable than an\nunknown, and demoting a real failure behind an access problem buries it.\n\n**`NOT ASSESSED` is not a gentler failure verdict.** \"I looked and found nothing\"\nand \"I could not look\" have different fixes — one needs work done, the other\nneeds access granted or an input classified. Collapsing them sends the reader to\nthe wrong fix.\n\n### 2. An absent value may not default to the permissive one\n\nEspecially when **nothing in the framework writes that key**. Before defaulting,\ncheck who sets it: a key with a reader and no writer takes its default branch on\nevery project that ever runs, so that branch is not an edge case — it is the\nbehaviour.\n\nOver-running a check costs minutes. Under-running one ships the category unrun.\n\n### 3. A skipped step announces itself\n\nIn the output, not only in the source. If a phase, category, or agent did not run\n— wrong engine, missing config, unavailable input, a `team.size` that collapses\nthe pipeline — the artifact must say so by name. A silent skip and a successful\none are the same artifact.\n\nA rule enforced in the body and never surfaced in the output is, to the reader,\nidentical to no rule at all.\n\n### 4. Never assert what you cannot source — and wire the gap to the verdict\n\nWhere this repo pins external facts (`docs/engine-reference/**`), do not fill a\ngap from training data. Write the gap down instead: `NOT SOURCEABLE — is\nnot covered by `.\n\n**Flagging alone is not enough.** A named gap that does not reach the verdict is\njust a comment. Wire it: a category with no sourced inputs must force obligation\n1's value, so the gap makes the pass unreachable rather than sitting beside it.\n\nA confidently wrong pattern list is worse than an absent one — it produces a scan\nthat looks thorough, finds nothing, and reads as a pass.\n\n### 5. Gates derive their covered set; they do not enumerate it\n\nAn allowlist pins what was known when it was written and is silent about\neverything added since. Derive the set from what the repo actually contains, so a\nnew skill or agent cannot ship outside coverage by simply not being on a list.\n\n**If the category is not mechanically crisp, say so in the gate and keep the\nlist.** A gate that fires on forty files does not get fixed, it gets muted — and\na muted gate is worse than a narrow one, because it reads as coverage. When you\nkeep a list, record *why* derivation failed and state the obligation to extend it.\n\nTwo further gate rules:\n\n- **Assert something that cannot be true by accident.** A check for the word\n \"unity\" is satisfied by a file path, and case-insensitively by \"community\".\n Assert a distinctive token instead.\n- **A gate you have not watched fail is not a gate.** Break the thing it guards,\n confirm it fails, restore. One mutation per tool invocation — a batch that\n times out leaves the repo holding a broken file, and `trap … EXIT` does not\n survive `SIGTERM`.\n\n## The test to apply\n\nBefore shipping a skill or gate, ask: **if this step silently did not run, what\nwould the output look like?**\n\nIf the answer is \"the same\", it is not finished.\n\n\n---\npaths:\n - \"tests/**\"\n - \"Assets/Tests/**/*.cs\"\n - \"Source/**/Tests/**/*.{h,cpp}\"\n---\n\n# Test Standards\n\n- Test naming follows the engine's language — every name says the scenario and\n the expected result:\n - **Godot (gdUnit4):** file `[system]_[feature]_test.gd`, function\n `test_[scenario]_[expected]`\n - **Unity (NUnit):** class `[System]Tests` in a file of the same name, method\n `[Scenario]_[Expected]` in PascalCase\n - **Unreal (Automation):** class `F[System][Scenario]Test` — one per test:\n each `IMPLEMENT_SIMPLE_AUTOMATION_TEST` defines its class, so a second test\n reusing a name fails to link — test name\n `.[System].[Scenario]` — the project's test command,\n `Automation RunTests .`, runs every test whose name contains\n `.` (a substring match, not a prefix). `.` is the root\n that filter in `commands.test` uses: the project name, or the distinct root\n `/setup-engine` chose when the project's name is also an engine area\n (`Audio`, `Core`, `Input`, …) — name tests under whichever it is\n- Every test must have a clear arrange/act/assert structure\n- Unit tests must not depend on external state (filesystem, network, database)\n- Integration tests must clean up after themselves\n- Performance tests must specify acceptable thresholds and fail if exceeded\n- Test data must be defined in the test or in dedicated fixtures, never shared mutable state\n- Mock external dependencies — tests should be fast and deterministic\n- Every bug fix must have a regression test that would have caught the original bug —\n and **you must watch it fail before you trust it.** Run the new test against the\n unfixed code, confirm it fails, then apply the fix and confirm it passes. A\n regression test that has only ever been seen passing is not known to test anything.\n\n > This is `.claude/rules/skill-authoring.md`'s \"a gate you have not watched fail\n > is not a gate\", applied to tests. It is written out here because stating the\n > *goal* is not enough. A regression test for an iteration-order defect can use\n > a fixture where no cell takes part in two transfers per tick — it then passes\n > against the very bug it was written for, and looks authoritative doing it. The\n > fixture, not the assertion, is what makes it useless, and only running it\n > against the unfixed code exposes that.\n\n## Examples\n\n**Correct** (proper naming + Arrange/Act/Assert) — Godot, gdUnit4:\n\n```gdscript\nextends GdUnitTestSuite\n\nfunc test_take_damage_reduces_health() -> void:\n # Arrange — auto_free: a Node left alive is an orphan (gdUnit4 exit 101)\n var health: HealthComponent = auto_free(HealthComponent.new())\n health.max_health = 100\n health.current_health = 100\n\n # Act\n health.take_damage(25)\n\n # Assert\n assert_int(health.current_health).is_equal(75)\n```\n\nUnity, NUnit (`Assets/Tests/EditMode/HealthTests.cs`):\n\n```csharp\nusing NUnit.Framework;\n\npublic class HealthTests\n{\n [Test]\n public void TakeDamage_ReducesHealth()\n {\n // Arrange\n var health = new Health(maxHealth: 100);\n\n // Act\n health.TakeDamage(25);\n\n // Assert\n Assert.AreEqual(75, health.Current);\n }\n}\n```\n\nUnreal, Automation (`Source//Private/Tests/HealthTest.cpp`):\n\n```cpp\n#include \"Misc/AutomationTest.h\"\n\n#if WITH_DEV_AUTOMATION_TESTS\n\nIMPLEMENT_SIMPLE_AUTOMATION_TEST(FHealthTakeDamageTest, \".Health.TakeDamageReducesHealth\",\n EAutomationTestFlags::EditorContext | EAutomationTestFlags::ProductFilter)\n\nbool FHealthTakeDamageTest::RunTest(const FString& Parameters)\n{\n // Arrange\n FHealthPool Health(100);\n\n // Act\n Health.TakeDamage(25);\n\n // Assert\n TestEqual(TEXT(\"health after 25 damage\"), Health.GetCurrent(), 75);\n return true;\n}\n\n#endif\n```\n\n**Incorrect**:\n\n```gdscript\nfunc test1() -> void: # VIOLATION: no descriptive name\n var h := HealthComponent.new()\n h.take_damage(25) # VIOLATION: no arrange step, no clear assert\n assert_bool(h.current_health < 100).is_true() # VIOLATION: imprecise assertion\n```\n\n\n---\npaths:\n - \"src/ui/**\"\n - \"Assets/**/{UI,Ui,ui}/**/*.cs\"\n - \"Source/**/{UI,Ui,ui}/**/*.{h,cpp}\"\n---\n\n# UI Code Rules\n\n- UI must NEVER own or directly modify game state — display only, use commands/events to request changes\n- All UI text must go through the localization system — no hardcoded user-facing strings\n- Support both keyboard/mouse AND gamepad input for all interactive elements\n- All animations must be skippable and respect user motion/accessibility preferences\n- UI sounds trigger through the audio event system, not directly\n- UI must never block the game thread\n- Scalable text and colorblind modes are mandatory, not optional\n- Test all screens at minimum and maximum supported resolutions\n\n\n# /adopt — Phase 1: Detect Project State\n\n> Part of `/adopt`. `SKILL.md` names when to read this file; the settings it\n> resolved and the rules under its later headings still apply here.\n\n## Phase 1: Detect Project State\n\nEmit one line before reading: `\"Scanning project artifacts...\"` — this confirms the\nskill is running during the silent read phase.\n\nThen read silently before presenting anything else.\n\n### Existence check\n- `project.stage` in `project.yaml` (fallback `production/stage.txt`) — if either is present, use that value (authoritative phase)\n- `design/gdd/game-concept.md` (or, at the minimal tier, `design/game-brief.md`) — concept exists?\n- `design/gdd/systems-index.md` — systems index exists?\n- Count GDD files: `design/gdd/*.md` (excluding game-concept.md and systems-index.md)\n- Count ADR files: `docs/architecture/adr-*.md`\n- Count story files: `production/epics/**/*.md` (excluding EPIC.md)\n- `project.yaml` (`engine.name`) / `.claude/docs/technical-preferences.md` — engine configured?\n- `docs/engine-reference/` — engine reference docs present?\n- Glob `docs/adoption-plan-*.md` — note the filename of the most recent prior plan if any exist\n\n### Infer phase (if no project.stage / stage.txt)\nUse the same heuristic as `/project-stage-detect`:\n- 10+ source files in the code root → Production\n- Stories in `production/epics/` → Pre-Production\n- ADRs exist → Technical Setup\n- systems-index.md exists → Systems Design\n- game-concept.md (or `design/game-brief.md`) exists → Concept\n- Nothing → Fresh (not a brownfield project — suggest `/start`)\n\nIf the project appears fresh (no artifacts at all), use `AskUserQuestion`:\n- \"This looks like a fresh project — no existing artifacts found. `/adopt` is for\n projects with work to migrate. What would you like to do?\"\n - \"Run `/start` — begin guided first-time onboarding\"\n - \"My artifacts are in a non-standard location — help me find them\"\n - \"Cancel\"\n\n`/start` and Cancel end this skill: say which, and stop.\n\n**If they pick \"help me find them\"**, search before asking anything else:\n\n1. Search the folder they named, if they named one; otherwise the whole\n project, skipping `.claude/`, `.git/`, `docs/engine-reference/`,\n `studio-tests/`, `node_modules/` and the engine's build and\n cache folders.\n2. Glob `**/*.md` there, then Grep the matches for the headings each artifact\n carries: a GDD has `## Overview` with `## Detailed Rules` or\n `## Detailed Design`; an ADR `## Status` with `## Decision`; a story\n `## Acceptance Criteria` with a `Status` line; a concept doc\n `## Elevator Pitch` or `## Game Pillars`; a brief `## Core loop` with\n `## MVP`.\n3. Show what was found, grouped by type, each with the place every skill reads\n it from: GDD → `design/gdd/[name].md`; ADR →\n `docs/architecture/adr-NNNN-[name].md`; story →\n `production/epics/[epic]/story-NNN-[name].md`; concept →\n `design/gdd/game-concept.md`; brief → `design/game-brief.md`. If nothing\n matched, say so, name the folders and headings searched, and offer `/start`.\n4. Ask before moving anything — a move takes the file away from its old path,\n so it is a `file_deletions` decision: \"May I move these [N] files to the\n standard folders?\" — `[A] Move them all` / `[B] Let me pick which` /\n `[C] Don't move them — I'll do it myself`. Move with `git mv` in a git\n repository (the file's history follows it), plain `mv` otherwise. Never\n overwrite a file already at the target: name the clash and skip that file.\n Files are moved, never edited.\n5. After the moves, run Phase 1 again from the top, so the audit reads the files\n where every other skill will. With [C], print the moves as a list and stop.\n\nReport: \"Detected phase: [phase]. Found: [N] GDDs, [M] ADRs, [P] stories.\"\n\n---\n\n\n# /adopt — Phase 2: Format Audit\n\n> Part of `/adopt`. `SKILL.md` names when to read this file; the settings it\n> resolved and the rules under its later headings still apply here.\n\n## Phase 2: Format Audit\n\n**In this file:**\n\n- 2a: GDD Format Audit\n- 2b: ADR Format Audit\n- 2c: systems-index.md Format Audit\n- 2d: Story Format Audit\n- 2e: Infrastructure Audit\n- 2f: Project Config Audit\n- 2g: v1.0 Migration Check\n\nFor each artifact type in scope (based on argument mode **and the resolved\nworkflow tier**), check not just that the file exists but that it contains the\ninternal structure the template requires. At `minimal`, scope the audit to\n`design/game-brief.md` — do not audit for GDDs, ADRs, or UX specs (they are not expected).\nSteps 2e (the Engine reference row only), 2f (project config) and 2g (v1.0\nmigration check) run at every tier.\n\n### 2a: GDD Format Audit\n\n**Gather section presence deterministically — do not read the GDDs to count\nheadings.** For each GDD discovered in Phase 1, pass its path explicitly to the\nstructure-check script:\n\n```\nBash: bash .claude/scripts/gdd-structure-check.sh [path-to-gdd]\n```\n\n**Pass paths one at a time; do not invoke it bare.** The no-argument form sweeps\n`design/gdd/` only, and a brownfield project's GDDs are not guaranteed to live\nthere — pass whatever paths Phase 1 found. The script prints a `PRESENT:` list\nand, when applicable, an `ABSENT:` list per file. It reports **presence only**\nand makes no REQUIRED/ADVISORY judgment (that is the tier logic below), and it\nalready accepts `## Detailed Design` as satisfying the `Detailed Rules`\nrequirement, so do not flag that alias as missing.\n\nIf the script prints `Not found:` for a path or errors, that is a **discovery\nfailure, not a format gap** — report it as \"could not audit [path]\" and do not\ncount it as a missing-sections finding.\n\n**Then apply the workflow tier** resolved above to each file's PRESENT/ABSENT\nlists. Which sections are **required** (a miss = gap) vs **advisory** (a miss =\ninformational):\n- **`full`** — all 8 sections are required.\n- **`standard`** — the 5 required (Overview, Detailed Rules, Edge Cases,\n Dependencies, Acceptance Criteria) + Formulas for any system that defines\n numeric rules (rates, curves, thresholds, costs — the system's `Category` is a\n hint, not the test); Player Fantasy and Tuning Knobs are advisory.\n- **`minimal`** — GDDs are not expected; audit `design/game-brief.md` instead,\n against `.claude/docs/templates/game-brief.md`: each of the six required fields\n present and not a placeholder; the three one-liners advisory. Any GDD that\n does exist is checked at the `standard` bar, advisorily.\n\nThe script's 8 canonical labels are: Overview, Player Fantasy, Detailed Rules,\nFormulas, Edge Cases, Dependencies, Tuning Knobs, Acceptance Criteria.\n\nA section reported PRESENT can still be an empty heading. For each GDD, also\nrecord with a targeted grep (not a full read):\n- Placeholder-only sections — the script's `PLACEHOLDER:` line names the\n present sections that hold only `[To be designed]` or nothing; a\n single-line stub body is the same in effect, so spot-check short sections.\n- The `**Status**:` header field — `Grep pattern=\"^>?[[:space:]]*\\*\\*Status\\*\\*:\"`.\n Valid values: `Draft`, `In Design`, `Designed`, `In Review`, `Approved`,\n `Implemented`, `Needs Revision`.\n\n> **The `>?` is load-bearing, and so are `Draft`/`Implemented`.** Both emitters\n> write this field inside a blockquote — `.claude/docs/templates/game-design-document.md`\n> and `/design-system` produce `> **Status**: …` — so an anchor of\n> `^\\*\\*Status\\*\\*:` matches nothing and reports *every* template-compliant GDD\n> as missing its Status. The template's own value list offers `Draft` and\n> `Implemented`, so both must count as valid.\n\n### 2b: ADR Format Audit\n\nFor each ADR file found, check for these critical sections:\n\n| Section | Impact if missing |\n|---|---|\n| `## Status` | **BLOCKING** — `/story-readiness` ADR status check silently passes everything |\n| `## ADR Dependencies` | HIGH — dependency ordering in `/architecture-review` breaks |\n| `## Engine Compatibility` | HIGH — post-cutoff API risk is unknown |\n| `## GDD Requirements Addressed` | MEDIUM — traceability matrix loses coverage |\n| `## Performance Implications` | LOW — not pipeline-critical |\n\nFor each ADR, record: which sections present, which missing, current Status value\nif the Status section exists.\n\n### 2c: systems-index.md Format Audit\n\nIf `design/gdd/systems-index.md` exists:\n\n1. **Parenthetical status values** — Grep for any Status cell containing\n parentheses: `\"Needs Revision (\"`, `\"In Progress (\"`, etc.\n These break exact-string matching in `/gate-check`, `/create-stories`,\n and `/architecture-review`. **BLOCKING.**\n\n2. **Valid status values** — check that Status column values are only from:\n `Not Started`, `In Progress`, `In Review`, `Designed`, `Approved`, `Needs Revision`\n Flag any unrecognised values.\n\n3. **Column structure** — check that the table has at minimum: System name,\n Layer, Priority, Status columns. Missing columns degrade skill functionality.\n\n### 2d: Story Format Audit\n\nFor each story file found:\n\n- **`Manifest Version:` field** — present in story header? (LOW — auto-passes if absent)\n- **TR-ID reference** — does story contain `TR-[a-z]+-[0-9]+` pattern? (MEDIUM — no staleness tracking)\n- **ADR reference** — does story reference at least one ADR? (check for `ADR-` pattern)\n- **Status field** — present and readable?\n- **Acceptance criteria** — does the story have a checkbox list (`- [ ]`)?\n\n### 2e: Infrastructure Audit\n\n| Artifact | Path | Impact if missing |\n|---|---|---|\n| TR registry | `docs/architecture/tr-registry.yaml` | HIGH — no stable requirement IDs |\n| Control manifest | `docs/architecture/control-manifest.md` | HIGH — no layer rules for stories |\n| Manifest version stamp | In manifest header: `Manifest Version:` | MEDIUM — staleness checks blind |\n| Sprint status | `production/sprint-status.yaml` | MEDIUM — `/sprint-status` falls back to markdown |\n| Stage file | `project.stage` in `project.yaml` (fallback `production/stage.txt`) | MEDIUM — phase auto-detect unreliable |\n| Engine reference | `docs/engine-reference/[engine]/VERSION.md` | HIGH — ADR engine checks blind |\n| Architecture traceability | `docs/architecture/requirements-traceability.md` | MEDIUM — no persistent matrix |\n\nAt `workflow: minimal` only the Engine reference row applies. The TR registry,\ncontrol manifest and its version stamp, sprint status, stage file and\ntraceability matrix are not on the minimal path, so their absence is not a gap.\n\n### 2f: Project Config Audit\n\nRead `project.yaml` (the primary config store) and `.claude/docs/technical-preferences.md` (legacy mirror). A setting counts as configured if EITHER source has a real value (in technical-preferences.md, `[TO BE CONFIGURED]` means unconfigured):\n- `engine.name`/`version`/`language`/`rendering`/`physics` (else the Engine/Language/Rendering/Physics fields) → HIGH if unconfigured in both (ADR skills fail)\n- `naming.*` (else Naming conventions) → MEDIUM\n- `performance.*` (else Performance budgets) → MEDIUM\n- Forbidden Patterns, Allowed Libraries (technical-preferences.md only — not migrated to project.yaml) → LOW (starts empty by design)\n\n### 2g: v1.0 Migration Check\n\nA project is a **v1.0 project needing migration** when `project.yaml` does NOT\nexist at the repo root AND at least one legacy file does: `production/stage.txt`,\n`production/review-mode.txt`, or a `.claude/docs/technical-preferences.md` with\nreal values.\n\n\"Real values\" means one of the keys the converter actually migrates — Engine,\nLanguage, Rendering, Physics, the naming, platform and performance fields,\nFramework, or the specialists. Not merely \"some bullet is filled in\": the\nshipped template ships one prose default (`- **Required Tests**: …`) that is\nnever migrated, and counting it would make every fresh clone read as a v1.0\nproject.\n\nDo not hand-migrate. Run the converter, which is deterministic and covered by\nthe framework's own test suite:\n\n```bash\nbash .claude/scripts/migrate-v1-config.sh --dry-run\n```\n\nThe dry run writes nothing; record what it lists for the report. Do not run the\nconverter during the audit — Phase 2 reads silently. The migration is\nclassified BLOCKING in Phase 3, heads the plan, and **Phase 7 offers it as the\nfirst action**: report what the dry run listed, then ask \"May I run the\nconverter? It writes `project.yaml` and `production/migration-report.md`.\" If\nthe user approves, run it without `--dry-run`. It\nwrites `project.yaml` plus `production/migration-report.md` and **deletes\nnothing** — the whole operation stays reversible with `git checkout`.\n\nThen tell the user to read `production/migration-report.md` before running:\n\n```bash\nbash .claude/scripts/migrate-v1-config.sh --finalize\n```\n\n`--finalize` deletes a legacy file only after proving its value is present in\n`project.yaml`; on mismatch it deletes nothing and exits 4. It never deletes\n`technical-preferences.md`, which still holds Forbidden Patterns and Allowed\nLibraries.\n\n**If the script refuses with exit 3**, do not work around it. Exit 3 means one\nof two things, and the message says which:\n\n- **the values DISAGREE** — two sources of truth and no way to know which the\n user edited last. Surface it and let them decide.\n- **a `production/migration-report.md` is already present** — a migration ran\n here, so these are post-migration leftovers and `--finalize` is the next step,\n not a second `migrate`.\n\nBoth files merely *existing* is not exit 3 and must not be reported as a\nconflict: `/start` writes `production/stage.txt` on every new v1.1 project as a\nmirror, so agreement is the normal state. The script says\n`the legacy files mirror it (values agree)` and exits 0 for that.\n\nClassify as **BLOCKING** in Phase 3: until migration runs, every skill reads\nconfig through the legacy fallback chain, and v1.1 settings are unavailable.\n\n---\n\n\n# /adopt — Phase 3: Classify and Prioritise Gaps\n\n> Part of `/adopt`. `SKILL.md` names when to read this file; the settings it\n> resolved and the rules under its later headings still apply here.\n\n## Phase 3: Classify and Prioritise Gaps\n\nOrganise every gap found across all audits into four severity tiers:\n\n**BLOCKING** — Will cause template skills to silently produce wrong results *right now*.\nExamples: ADR missing Status field, systems-index parenthetical status values,\nengine not configured when ADRs exist.\n\n**HIGH** — Will cause stories to be generated with missing safety checks, or\ninfrastructure bootstrapping will fail.\nExamples: ADRs missing Engine Compatibility, GDDs missing Acceptance Criteria\n(stories can't be generated from them), tr-registry.yaml missing.\n\n**MEDIUM** — Degrades quality and pipeline tracking but does not break functionality.\nExamples: GDDs missing Tuning Knobs or Formulas sections, stories missing TR-IDs,\nsprint-status.yaml missing.\n\n**LOW** — Retroactive improvements that are nice-to-have but not urgent.\nExamples: Stories missing Manifest Version stamps, GDDs missing Open Questions section.\n\nCount totals per tier. If zero BLOCKING and zero HIGH gaps: report that the project\nis template-compatible and only advisory improvements remain.\n\n---\n\n\n# /adopt — Phase 4: Build the Migration Plan\n\n> Part of `/adopt`. `SKILL.md` names when to read this file; the settings it\n> resolved and the rules under its later headings still apply here.\n\n## Phase 4: Build the Migration Plan\n\nCompose a numbered, ordered action plan. Ordering rules:\n1. BLOCKING gaps first (must fix before any pipeline skill runs reliably)\n2. HIGH gaps next, infrastructure before GDD/ADR content (bootstrapping needs correct formats)\n3. MEDIUM gaps ordered: GDD gaps before ADR gaps before story gaps (stories depend on GDDs and ADRs)\n4. LOW gaps last\n\nFor each gap, produce a plan entry with:\n- A clear problem statement (one sentence, no jargon)\n- The exact command to fix it, if a skill handles it\n- Manual steps if it requires direct editing\n- A time estimate (rough: 5 min / 30 min / 1 session)\n- A checkbox `- [ ]` for tracking\n\n**Special case — systems-index parenthetical status values:**\nThis is always the first item if present. Show the exact values that need changing\nand the exact replacement text. Offer to fix this immediately before writing the plan.\n\n**Special case — ADRs missing Status field:**\nFor each affected ADR, the fix is:\n`/architecture-decision retrofit docs/architecture/adr-[NNNN]-[slug].md`\nList each ADR as a separate checkable item.\n\n**Special case — GDDs missing sections:**\nFor each affected GDD, list which sections are missing and the fix:\n`/design-system retrofit design/gdd/[filename].md`\n\n**Infrastructure bootstrap ordering** — always present in this sequence:\n1. Fix ADR formats first (registry depends on reading ADR Status fields)\n2. Run `/architecture-review` → bootstraps `tr-registry.yaml`\n3. Run `/create-control-manifest` → creates manifest with version stamp\n4. Run `/sprint-plan update` → creates `sprint-status.yaml`\n5. Run `/gate-check [phase]` (the gate into the phase the project is in; at Concept there is none — Concept is the default stage, nothing to run) → writes `project.stage` in `project.yaml` (and legacy `stage.txt`) authoritatively\n\n**At `workflow: minimal` the plan prescribes none of this sequence.** None of it\nis on the minimal path: ADRs are not expected, the brief's build order is the\nplan (no `/sprint-plan`), and nothing there runs `/gate-check`. The plan's\nStep 3 says so in one line and names the path's next step instead —\n`/create-stories` when no stories exist, else `/dev-story`.\n\n**Existing stories** — note explicitly:\n> \"Existing stories continue to work with all template skills — all new format\n> checks auto-pass when the fields are absent. They won't benefit from TR-ID\n> staleness tracking or manifest version checks until they're regenerated. This\n> is intentional: do not regenerate stories that are already in progress.\"\n\n---\n\n\n# /adopt — Phase 5: Present Summary and Ask to Write\n\n> Part of `/adopt`. `SKILL.md` names when to read this file; the settings it\n> resolved and the rules under its later headings still apply here.\n\n## Phase 5: Present Summary and Ask to Write\n\nPresent a compact summary before writing:\n\n```\n## Adoption Audit Summary\nPhase detected: [phase]\nEngine: [configured / NOT CONFIGURED]\nGDDs audited: [N] ([X] fully compliant, [Y] with gaps)\nADRs audited: [N] ([X] fully compliant, [Y] with gaps)\nStories audited: [N]\n\nGap counts:\n BLOCKING: [N] — template skills will malfunction without these fixes\n HIGH: [N] — unsafe to run /create-stories or /story-readiness\n MEDIUM: [N] — quality degradation\n LOW: [N] — optional improvements\n\nEstimated remediation: [X blocking items × ~Y min each = roughly Z hours]\n```\n\nBefore asking to write, show a **Gap Preview**:\n- List every BLOCKING gap as a one-line bullet describing the actual problem\n (e.g. `systems-index.md: 3 rows have parenthetical status values`,\n `adr-0002.md: missing ## Status section`). No counts — show the actual items.\n- Show HIGH / MEDIUM / LOW as counts only (e.g. `HIGH: 4, MEDIUM: 2, LOW: 1`).\n\nThis gives the user enough context to judge scope before committing to writing the file.\n\nIf a prior adoption plan was detected in Phase 1, add a note:\n> \"A previous plan exists at `docs/adoption-plan-[prior-date].md`. The new plan will\n> reflect current project state — it does not diff against the prior run.\"\n\nUse `AskUserQuestion`:\n- \"Ready to write the migration plan?\"\n - \"Yes — write `docs/adoption-plan-[date].md`\"\n - \"Show me the full plan preview first (don't write yet)\"\n - \"Cancel — I'll handle migration manually\"\n\nIf the user picks \"Show me the full plan preview\", output the complete plan as a\nfenced markdown block. Then ask again with the same three options.\n\n---\n\n\n# /adopt — Phases 6 and 6b: Write the Adoption Plan and Report Review Mode\n\n> Part of `/adopt`. `SKILL.md` names when to read this file; the settings it\n> resolved and the rules under its later headings still apply here.\n\n## Phase 6: Write the Adoption Plan\n\n**In this file:**\n\n- Phase 6: the adoption plan template, then the write\n- Phase 6b: Report Review Mode\n\nIf approved, write `docs/adoption-plan-[date].md` with this structure:\n\n```markdown\n# Adoption Plan\n\n> **Generated**: [date]\n> **Project phase**: [phase]\n> **Engine**: [name + version, or \"Not configured\"]\n> **Template version**: v1.0+\n\nWork through these steps in order. Check off each item as you complete it.\nRe-run `/adopt` anytime to check remaining gaps.\n\n---\n\n## Step 1: Fix Blocking Gaps\n\n[One sub-section per blocking gap with problem, fix command, time estimate, checkbox]\n\n---\n\n## Step 2: Fix High-Priority Gaps\n\n[One sub-section per high gap]\n\n---\n\n## Step 3: Bootstrap Infrastructure\n\n[At `workflow: minimal`, replace 3a–3d with one line: \"Not on the minimal path —\nthe brief's build order is the plan. Next: `/create-stories` (or `/dev-story`\nonce stories exist).\"]\n\n### 3a. Register existing requirements (creates tr-registry.yaml)\nRun `/architecture-review` — even if ADRs already exist, this run bootstraps\nthe TR registry from your existing GDDs and ADRs.\n**Time**: 1 session (review can be long for large codebases)\n- [ ] tr-registry.yaml created\n\n### 3b. Create control manifest\nRun `/create-control-manifest`\n**Time**: 30 min\n- [ ] docs/architecture/control-manifest.md created\n\n### 3c. Create sprint tracking file\nRun `/sprint-plan update`\n**Time**: 5 min (if sprint plan already exists as markdown)\n- [ ] production/sprint-status.yaml created\n\n### 3d. Set authoritative project stage\nRun `/gate-check [current-phase]` (the gate into the phase the project is in;\nat Concept there is none — Concept is the default stage, nothing to run)\n**Time**: 5 min\n- [ ] `project.stage` in `project.yaml` written (legacy `production/stage.txt` also updated)\n\n---\n\n## Step 4: Medium-Priority Gaps\n\n[One sub-section per medium gap]\n\n---\n\n## Step 5: Optional Improvements\n\n[One sub-section per low gap]\n\n---\n\n## What to Expect from Existing Stories\n\nExisting stories continue to work with all template skills. New format checks\n(TR-ID validation, manifest version staleness) auto-pass when the fields are\nabsent — so nothing breaks. They won't benefit from staleness tracking until\nregenerated. Do not regenerate stories that are in progress or done.\n\n---\n\n## Re-run\n\nRun `/adopt` again after completing Step 3 to verify all blocking and high gaps\nare resolved. The new run will reflect the current state of the project.\n```\n\n---\n\n## Phase 6b: Report Review Mode\n\n**Do not write a review mode.** `modes.review_mode` is one of the six knobs\n`modes.rigor` fronts: pinning it in `project.yaml` shadows the rigor expansion, and\nthe legacy `production/review-mode.txt` sits *above* that expansion in resolution,\nso either write would freeze director-review depth for good — the rule `/start`\nand `project.yaml`'s header comment both state.\n\nReport the value the bootstrap above resolved instead: \"Review mode resolves to\n`[value]` — from `modes.rigor`, unless something pins it.\" If the user wants a\ndifferent depth, point them to changing `modes.rigor`, or to pinning it on purpose\nwith `/settings --local modes.review_mode=` (a personal override in\n`project.local.yaml`).\n\n---\n\n\n# /adopt — Phase 7: Offer First Action\n\n> Part of `/adopt`. `SKILL.md` names when to read this file; the settings it\n> resolved and the rules under its later headings still apply here.\n\n## Phase 7: Offer First Action\n\nAfter writing the plan, don't stop there. Pick the single highest-priority gap\nand offer to handle it immediately using `AskUserQuestion`. Choose the first\nbranch that applies:\n\n**If Phase 2g found a v1.0 project needing migration:** offer the converter run\ndescribed there — report what the dry run listed and ask \"May I run the\nconverter? It writes `project.yaml` and `production/migration-report.md`.\"\nEvery other fix reads config through it, so it comes first.\n\n**If there are parenthetical status values in systems-index.md:**\nUse `AskUserQuestion`:\n- \"The most urgent fix is `systems-index.md` — [N] rows have parenthetical status\n values (e.g. `Needs Revision (see notes)`) that break /gate-check,\n /create-stories, and /architecture-review right now. I can fix these in-place.\"\n - \"Fix it now — edit systems-index.md\"\n - \"I'll fix it myself\"\n - \"Done — leave me with the plan\"\n\n**If ADRs are missing `## Status` (and no parenthetical issue):**\nUse `AskUserQuestion`:\n- \"The most urgent fix is adding `## Status` to [N] ADR(s): [list filenames].\n Without it, /story-readiness silently passes all ADR checks. Start with\n [first affected filename]?\"\n - \"Yes — retrofit [first affected filename] now\"\n - \"Retrofit all [N] ADRs one by one\"\n - \"I'll handle ADRs myself\"\n\n**If GDDs are missing Acceptance Criteria (and no blocking issues above):**\nUse `AskUserQuestion`:\n- \"The most urgent gap is missing Acceptance Criteria in [N] GDD(s):\n [list filenames]. Without them, /create-stories can't generate stories.\n Start with [highest-priority GDD filename]?\"\n - \"Yes — add Acceptance Criteria to [GDD filename] now\"\n - \"Do all [N] GDDs one by one\"\n - \"I'll handle GDDs myself\"\n\n**Otherwise, if any BLOCKING or HIGH gap remains** (one no branch above names —\ne.g. a missing TR registry):\nUse `AskUserQuestion`:\n- \"The most urgent remaining gap is [first BLOCKING or HIGH item in the plan] —\n [one line on what it breaks]. Start on it now?\"\n - \"Yes — start on [item]\"\n - \"Show me that plan item first\"\n - \"Done — leave me with the plan\"\n\n**If no BLOCKING or HIGH gaps exist:**\nUse `AskUserQuestion`:\n- \"No blocking gaps — this project is template-compatible. What next?\"\n - \"Walk me through the medium-priority improvements\"\n - \"Run /project-stage-detect for a broader health check\"\n - \"Done — I'll work through the plan at my own pace\"\n\n> **Adoption plan saved to `docs/adoption-plan-[date].md`.** Re-run `/adopt` at any time to re-check remaining gaps as you complete them.\n\n---\n\n\n---\nname: adopt\ndescription: \"Brownfield audit — do existing artifacts actually work? Numbered migration plan. Unlike /project-stage-detect, checks compliance not existence.\"\nargument-hint: \"[focus: full | gdds | adrs | stories | infra]\"\nuser-invocable: true\nallowed-tools: Read, Glob, Grep, Write, AskUserQuestion, Bash(bash \"*/.claude/skills/adopt/../../hooks/yaml-helper.sh\" resolve_config *), Bash(bash .claude/scripts/gdd-structure-check.sh *), Bash(bash .claude/scripts/migrate-v1-config.sh --dry-run*)\nmodel: sonnet\n---\n\n!`bash \"${CLAUDE_SKILL_DIR}/../../hooks/yaml-helper.sh\" resolve_config --keys review_mode,automation,automation_always_ask,workflow`\n\nResolved above — use as-is. `/adopt` also inspects `project.yaml` and the legacy\nconfig files directly when reporting and writing migration state; that raw\ninspection is deliberate and separate from the resolved values above.\n\n# Adopt — Brownfield Template Adoption\n\nThis skill audits an existing project's artifacts for **format compliance** with\nthe template's skill pipeline, then produces a prioritised migration plan.\n\n**This is not `/project-stage-detect`.**\n`/project-stage-detect` answers: *what exists?*\n`/adopt` answers: *will what exists actually work with the template's skills?*\n\nA project can have GDDs, ADRs, and stories — and every format-sensitive skill\nwill still fail silently or produce wrong results if those artifacts are in the\nwrong internal format.\n\n**Output:** `docs/adoption-plan-[date].md` — a persistent, checkable migration plan.\n\n**Argument modes:**\n\n**Audit mode:** `$ARGUMENTS` (blank = `full`)\n\n- **No argument / `full`**: Complete audit — all artifact types\n- **`gdds`**: GDD format compliance only\n- **`adrs`**: ADR format compliance only\n- **`stories`**: Story format compliance only\n- **`infra`**: Infrastructure artifact gaps only (registry, manifest, sprint-status, stage.txt)\n\n---\n\n**Automation mode**: Resolve `modes.automation` (`project.local.yaml` →\n`project.yaml` → default `collaborative`). Every `AskUserQuestion` call follows `.claude/docs/automation-modes.md`\n(collaborative asks always · guided major-only · autonomous logs and proceeds;\n`automation_always_ask` categories always prompt).\n\n**`workflow`** (per `.claude/docs/workflow-modes.md`). It scopes the Phase 2 audit and\nPhase 3 severity: `full` audits all doc types at full structure; `standard` audits\nonly the required docs/sections (optional sections are informational, not gaps);\n`minimal` is a `design/game-brief.md` format check — GDDs/ADRs/UX are not expected. See Phase 2.\n\n## Phase 1: Detect Project State\n\n**Read `references/1-detect.md` now and follow it** — this phase's steps are in that file, not here. Read it again if the conversation was compacted or resumed during this phase.\n\n## Phase 2: Format Audit\n\n**Read `references/2-format-audit.md` now and follow it** — this phase's steps are in that file, not here. Read it again if the conversation was compacted or resumed during this phase.\n\n## Phase 3: Classify and Prioritise Gaps\n\n**Read `references/3-classify.md` now and follow it** — this phase's steps are in that file, not here. Read it again if the conversation was compacted or resumed during this phase.\n\n## Phase 4: Build the Migration Plan\n\n**Read `references/4-migration-plan.md` now and follow it** — this phase's steps are in that file, not here. Read it again if the conversation was compacted or resumed during this phase.\n\n## Phase 5: Present Summary and Ask to Write\n\n**Read `references/5-summary.md` now and follow it** — this phase's steps are in that file, not here. Read it again if the conversation was compacted or resumed during this phase.\n\n## Phase 6: Write the Adoption Plan\n\n**Read `references/6-write.md` now and follow it** — this phase's steps are in that file, not here. Read it again if the conversation was compacted or resumed during this phase.\n\n## Phase 7: Offer First Action\n\n**Read `references/7-first-action.md` now and follow it** — this phase's steps are in that file, not here. Read it again if the conversation was compacted or resumed during this phase.\n\n## Collaborative Protocol\n\n**Applies in `collaborative` mode (the default).** For `guided` and\n`autonomous` modes, see `.claude/docs/automation-modes.md` — the rules below\ndescribe what collaborative mode requires, not universal behavior.\n\n1. **Read silently** — complete the full audit before presenting anything\n2. **Show the summary first** — let the user see scope before asking to write\n3. **Ask before writing** — always confirm before creating the adoption plan file\n4. **Offer, don't force** — the plan is advisory; the user decides what to fix and when\n5. **One action at a time** — after handing off the plan, offer one specific next step,\n not a list of six things to do simultaneously\n6. **Never regenerate existing artifacts** — only fill gaps in what exists;\n do not rewrite GDDs, ADRs, or stories that already have content\n\n\n# /architecture-decision — Handoff Contract\n\n## Role in Pipeline\nAuthors a new Architecture Decision Record (ADR) by guiding a collaborative design session, cross-referencing the engine reference library and existing architectural stances, and writing a fully-structured ADR file to `docs/architecture/` as `Proposed`. Its `accept` mode is the only route to `Accepted`, and acceptance is what unblocks the stories and epics that depend on the decision.\n\nTwo checks inside the run emit `NOT ASSESSED` rather than passing silently, and\na reader of the resulting ADR should expect them: **engine validation** when no\nengine is configured (`engine.name` unset and no legacy fallback), and **GDD\nsync** when the referenced design docs cannot be read. A skipped check that says\nnothing is indistinguishable from a check that passed.\n\n## Inputs Required\n\n### Files That Must Exist\n| File | Required Fields / Sections | Read-Only? |\n|------|---------------------------|-----------|\n| `docs/engine-reference/[engine]/VERSION.md` | Engine name + version, LLM knowledge cutoff date, post-cutoff risk levels per domain | Yes |\n| `docs/engine-reference/[engine]/modules/[domain].md` | Domain-specific API reference (read if exists for the decision's domain) | Yes |\n| `docs/engine-reference/[engine]/breaking-changes.md` | Post-cutoff breaking changes in the relevant domain | Yes |\n| `docs/engine-reference/[engine]/deprecated-apis.md` | APIs that must not be referenced in the new ADR | Yes |\n| `docs/registry/architecture.yaml` | All existing architectural stances (state ownership, interface contracts, forbidden patterns, performance budgets) — checked for conflicts before the design begins | Yes |\n| `docs/architecture/` (existing ADRs) | Scanned to determine the next sequential ADR number | Yes |\n| `design/gdd/[system].md` (GDDs relevant to the decision) | Specific rules, formulas, performance constraints, or integration points that motivate the decision | Yes |\n| `project.yaml` | `engine.name` — derives the primary specialist (`-specialist`) to spawn for validation (Step 5.5) | Yes |\n| `.claude/docs/technical-preferences.md` | `Engine Specialists` section — legacy fallback, used only when `engine.name` is absent or empty in `project.yaml` | Yes — required only when `engine.name` is absent |\n\n### Preconditions\n- An engine must be configured (`docs/engine-reference/[engine]/VERSION.md` must exist) — if not, the skill prompts to run `/setup-engine` first\n- The title or subject of the decision must be provided by the user before Step 0 proceeds (if no argument is given, the skill asks)\n- If in **retrofit mode** (`retrofit [path]` argument), the target ADR file must already exist on disk\n- Any conflict with a registered architectural stance in `docs/registry/architecture.yaml` must be resolved or explicitly accepted as an exception before the ADR is drafted (Step 3a is a BLOCKING gate)\n\n## Outputs Produced\n\n### Files Written\n| File | Guaranteed Fields / Sections | Notes |\n|------|------------------------------|-------|\n| `docs/architecture/adr-NNNN-[slug].md` | `## Status`, `## Date`, `## Engine Compatibility` (table with engine, domain, knowledge risk, post-cutoff APIs, verification required), `## ADR Dependencies` (table with depends-on, enables, blocks, ordering note), `## Context` (problem statement, constraints, requirements), `## Decision` (+ architecture diagram + key interfaces), `## Alternatives Considered`, `## Consequences` (positive, negative), `## Risks`, `## GDD Requirements Addressed` (table), `## Performance Implications`, `## Migration Plan`, `## Validation Criteria`, `## Related` | created after user approves (\"May I write this ADR to docs/architecture/adr-NNNN-[slug].md?\") |\n| `docs/registry/architecture.yaml` | New stance entries (state ownership, interface contracts, performance budgets, forbidden patterns) derived from the ADR; existing entries marked `status: superseded_by` if overridden | appended after separate user approval (\"May I update docs/registry/architecture.yaml with these N new stances?\") |\n\n### Output Guarantees\n- The ADR number is the next sequential integer after the highest existing `adr-NNNN-*` filename in `docs/architecture/`\n- `## Status` is always present. Authoring writes `Proposed`; retrofit writes the status the user gives, except that an `Accepted` answer is written as `Proposed` and handed to acceptance mode. Only acceptance mode writes `Accepted`, after its dependency check and the user's confirmation\n- `## Engine Compatibility` is always populated using verified data from the engine reference docs — never from training data alone when the domain carries MEDIUM or HIGH risk\n- `## GDD Requirements Addressed` is always present (if no GDD motivated the decision, it documents which GDDs the decision will constrain or enable)\n- `## ADR Dependencies` is always present (fields set to \"None\" if no ordering constraints exist)\n- Engine specialist validation (Step 5.5) runs before the file is written if an engine specialist is configured; blocking issues found by the specialist cause the Decision section to be revised before saving\n\n## Immutability Rules\n- READS but does NOT modify: all existing ADR files in `docs/architecture/` (including in retrofit mode — existing sections are never touched), all GDD files in `design/gdd/`, `docs/engine-reference/**`, `project.yaml`, `.claude/docs/technical-preferences.md` (legacy fallback)\n- MODIFIES: `docs/architecture/adr-NNNN-[slug].md` (new file created; or missing sections appended in retrofit mode), `docs/registry/architecture.yaml` (append only; existing entries get `status: superseded_by` annotation, never deleted or rewritten)\n- In retrofit mode: appends only the missing sections — never modifies any section that is already present in the target ADR file\n\n## Hard Constraints (Never Violate)\n- Never sets `Status: Accepted` without explicit user confirmation — the default on creation is always `Status: Proposed`\n- **Acceptance route: `/architecture-decision accept ADR-NNNN`** — the only path that sets `Accepted`. It refuses when a dependency is still Proposed, and prompts for confirmation regardless of `modes.automation`. Retrofit mode's `Accepted` answer, for a decision already in force, is written as `Proposed` and handed to this route. Without this route acceptance would be enforced by ten skills, owned per the authority below, and reachable by nobody.\n- **Acceptance authority: the user, or `technical-director` on the user's explicit confirmation — no other agent, and not this skill on its own.** Recorded here because every consumer enforces the consequences of acceptance, and without this line nothing would say who can produce it. This narrows *who* may set the field; it does not relax the confirmation rule above.\n- Never assigns an ADR number that is already in use — always scan `docs/architecture/` first and use the next sequential number\n- Never proceeds past the architectural stance conflict check (Step 3a) if a conflict exists — surface the conflict and require resolution or explicit exception acknowledgment before drafting\n- Never references APIs listed in `docs/engine-reference/[engine]/deprecated-apis.md` in the Decision or Key Interfaces sections\n- Never writes the ADR file without asking: \"May I write this ADR to docs/architecture/adr-NNNN-[slug].md?\"\n- Never writes to `docs/registry/architecture.yaml` without a separate ask: \"May I update docs/registry/architecture.yaml with these N new stances?\"\n- In retrofit mode: never modifies any existing section — only appends absent sections\n\n## Downstream Skill Expects\n**Next skills:** `/create-epics`, `/create-stories`, `/dev-story`, `/architecture-review`\n\n### `/create-epics` reads ADRs expecting:\n- `## Status` field — value must be `Accepted` for epics to reference it\n- `## GDD Requirements Addressed` table — used to link epics to GDD traceability\n- `## Engine Compatibility` section — checked during the Technical Setup → Pre-Production gate\n\n### `/create-stories` reads ADRs expecting:\n- `### Implementation Guidelines` (under `## Decision`) — the concrete \"must / must never\" patterns programmer agents follow; the ADR template carries this subsection\n- `## ADR Dependencies` table — stories referencing a `Depends On` ADR that is still `Proposed` are automatically set `Status: Blocked`\n\n### `/dev-story` reads ADRs expecting:\n- `## Decision` (full text, verbatim — not summarized)\n- `### Implementation Guidelines` (under `## Decision`, verbatim)\n- `## Engine Compatibility` (post-cutoff API risks, verification required)\n- `## ADR Dependencies` (to detect if this ADR's dependencies are unresolved)\n\n### `/architecture-review` reads ADRs expecting:\n- All required sections present (it flags gaps)\n- `## Status` is set (required for coverage matrix)\n- `## Engine Compatibility` is stamped with the correct engine version\n\n## Known Fragile Points\n- If the ADR number scan misses a file (e.g., a file in a subdirectory of `docs/architecture/` or with a non-standard naming pattern), a duplicate number can be assigned — all ADR files must follow the `adr-NNNN-[slug].md` naming convention at the top level of `docs/architecture/`\n- Acceptance mode moves a story from `Blocked` to `Ready` only when the story file, under `production/epics/`, contains a Blocked Status line in any of the forms `/create-stories` writes (`> **Status**: Blocked`, `**Status:** Blocked`, `Status: Blocked`) and this ADR's id. A story blocked pending this ADR that never names its id is not found, and stays `Blocked` until it is updated by hand\n- The `## GDD Requirements Addressed` table is populated based on what the user tells the skill during the collaborative session; if the user does not know which GDDs motivated the decision, this table may be incomplete — `/create-epics` and `/gate-check` both rely on this linkage for traceability\n- Engine specialist validation (Step 5.5) is skipped only when **both** sources are unset — `engine.name` absent or empty in `project.yaml` **and** `.claude/docs/technical-preferences.md` still reading `[TO BE CONFIGURED]`. A project configured solely via `project.yaml` **does** get specialist validation. When both are unset, post-cutoff engine API risks are not caught before the ADR is written\n- `docs/registry/architecture.yaml` is append-only by design; if a stance entry becomes permanently invalid (not superseded by another ADR), it must be manually removed — there is no cleanup mechanism\n- In retrofit mode, if the existing ADR has sections present but empty (e.g., a `## Status` heading with no value), the skill treats the section as present and does not fill it — an empty Status is effectively invisible to downstream skills like `/story-readiness`\n\n\n# /architecture-decision — Acceptance Mode\n\n> Part of `/architecture-decision`. `SKILL.md` names when to read this file; the settings it\n> resolved and the rules under its later headings still apply here.\n\n**If the argument starts with `accept` followed by an ADR id**\n\n(e.g., `/architecture-decision accept ADR-0005`):\n\nEnter **acceptance mode**. This is the *only* path in the framework that moves an\nADR from `Proposed` to `Accepted`. Authoring always produces `Proposed`\n(Step 5), while\n`/create-control-manifest`, `/create-epics`, `/create-stories` and `/gate-check`\nall require `Accepted` — so without this mode an ADR would enter a state it\nnever leaves.\n\n1. **Resolve the id to a file, then read it.** Glob\n `docs/architecture/adr-NNNN-*.md` for the given number. If **no** file matches,\n or **more than one** does, stop and say which — do not pick one. If the file\n has no `## Status` section, stop and say so; a missing Status is exactly what\n retrofit mode is for.\n2. **Check the current status.** If it is already `Accepted`, say so and stop.\n If it is `Deprecated` or `Superseded`, refuse: reviving a superseded decision\n is a new ADR, not a status edit.\n3. **Check its dependencies first.** Read `## ADR Dependencies`.\n\n **If that section is absent, empty, or reads `UNKNOWN`, do not read it as\n \"no dependencies\" — refuse and say which:**\n > \"ADR-0005's dependency section is [absent / UNKNOWN], so I cannot tell what\n > this decision rests on. An empty dependency list and an unexamined one look\n > identical here, and only one of them is safe to accept. Run\n > `/architecture-decision retrofit ` to establish it.\"\n\n A dependency check reading a field that defaults to empty is the vacuous-pass\n shape this gate exists to prevent — the check would examine nothing and report\n clean.\n\n If it depends on any ADR that is not itself `Accepted`, **refuse and name them**:\n > \"ADR-0005 depends on ADR-0002, which is still Proposed. Accept ADR-0002\n > first — an accepted decision resting on an unaccepted one is not a decision,\n > it is a deferral with a different label.\"\n This is the same dependency rule `/architecture-review` already flags; here it\n is enforced rather than reported.\n4. **Confirm with the user, always.** Per `CONTRACT.md`, acceptance authority is\n **the user, or `technical-director` on the user's explicit confirmation — no\n other agent, and never this skill on its own.** Use `AskUserQuestion`:\n - Prompt: \"Accept ADR-NNNN — [title]? This is what unblocks stories and epics\n that depend on it.\"\n - Options: `[A] Yes — accept it` / `[B] Not yet — leave it Proposed`\n **This prompt fires regardless of `modes.automation`, including `autonomous`.**\n Acceptance is the decision the whole architecture pipeline gates on; it is not\n a step to be inferred.\n5. **Find the stories this will unblock, BEFORE the prompt in step 4.** Grep\n every story for a Blocked Status line —\n `Grep pattern=\"Status\\**:\\**\\s*Blocked\" path=\"production/epics\" glob=\"**/story-*.md\" output_mode=\"files_with_matches\"`,\n which matches `> **Status**: Blocked` (the form `/create-stories` writes),\n `**Status:** Blocked` and `Status: Blocked` — and keep the files that name\n this ADR's id as the reason they are blocked. That pairing is what \"blocked\n pending this ADR\" means — a story blocked for an unrelated reason will not\n name it. Leave out a story that names this ADR only as the successor to point\n at (`point the story at ADR-NNNN`, the note for a `Deprecated` or\n `Superseded` ADR): it is still governed by the old ADR, and accepting the\n successor does not re-point it.\n > **Stories live only under `production/epics/`.** A flat top-level stories\n > directory does not exist and no skill creates one — never write or match a\n > path outside `production/epics/`. `/dev-story` matches entries *by file\n > path*, so a story recorded under any other path silently fails to match and\n > never gets picked up.\n\n Feed the count into step 4's prompt so it reads *\"3 stories become Ready\"*\n rather than a generic claim: **the user is being asked to authorise an effect, and should be\n shown the effect.** If none match, say \"no stories are waiting on this\" — that\n is useful information, not an empty result to omit.\n6. On confirmation, `Edit` the `## Status` line to `Accepted`. Leave an existing\n `## Date` as it is: it records when the ADR was written, and `/create-stories`\n stamps stories with it (or `## Last Verified`), so rewriting it on acceptance\n would make every story drafted against the Proposed ADR look out of date to\n `/dev-story`. **If that section is absent, add it** with today's date — retrofit\n mode already owns this shape, and acceptance must not fail on a template that\n predates the field.\n7. Then set each story found in step 5 from `Blocked` to `Ready`. Unblocking is a\n consequence of acceptance, never of authoring — see Step 6's note below.\n8. Report what moved: the ADR (and its `## Date`, if one was added), and every\n story that became Ready.\n\n\n# /architecture-decision — Retrofit Mode\n\n> Part of `/architecture-decision`. `SKILL.md` names when to read this file; the settings it\n> resolved and the rules under its later headings still apply here.\n\n**If the argument starts with `retrofit` followed by a file path**\n\n(e.g., `/architecture-decision retrofit docs/architecture/adr-0001-event-system.md`):\n\nEnter **retrofit mode**:\n\n1. Read the existing ADR file completely. This step needs the whole ADR: read it\n in ranges by its headings (found with the Grep tool: pattern `^#`, content\n mode), since a whole-file Read over 40 KB is refused.\n2. Identify which template sections are present by scanning headings:\n - `## Status` — **BLOCKING if missing**: `/story-readiness` cannot check ADR acceptance\n - `## ADR Dependencies` — HIGH if missing: dependency ordering breaks\n - `## Engine Compatibility` — HIGH if missing: post-cutoff risk unknown. A\n present table with no **Layer** row is HIGH too: the ADR counts as critical\n wherever it is read, so at `standard` its advisory items become blockers\n - `## GDD Requirements Addressed` — MEDIUM if missing: traceability lost\n - `## Date` — MEDIUM if missing, and no `## Last Verified` either: `/create-stories`\n stamps stories with it and `/dev-story` compares against it, so without it a\n story can never tell whether the ADR changed\n3. Present to the user:\n ```\n ## Retrofit: [ADR title]\n File: [path]\n\n Sections already present (will not be touched):\n ✓ Status: [current value, or \"MISSING — will add\"]\n ✓ [section]\n\n Missing sections to add:\n ✗ Status — BLOCKING (stories cannot validate ADR acceptance without this)\n ✗ ADR Dependencies — HIGH\n ✗ Engine Compatibility — HIGH\n ```\n4. Ask: \"Shall I add the [N] missing sections? I will not modify any existing content.\"\n If no: write nothing, and report the missing sections by name.\n5. If yes:\n - For **Status**: ask the user — \"What is the current status of this decision?\"\n Options: \"Proposed\", \"Accepted\", \"Deprecated\", \"Superseded by ADR-XXXX\"\n An `Accepted` answer — a decision already in force — is not written as\n given: write `Proposed`, add the other missing sections, then run\n acceptance mode (below) on this ADR. Its dependency check, confirmation and\n story unblocking apply here too; it stays the only path that sets `Accepted`.\n - For **ADR Dependencies**: ask — \"Does this decision depend on any other ADR?\n Does it enable or block any other ADR or epic?\" Accept \"None\" for each field.\n - For **Engine Compatibility**: read the engine reference docs (same as Step 1 below)\n and ask the user to confirm the domain. Then generate the table with verified data,\n its Layer row included.\n - For a present Engine Compatibility table with no **Layer** row: find the\n layer as `references/5-generate.md` says under \"Always write the Layer row\",\n and add the row under **Domain**. It adds a row and changes none.\n - For **GDD Requirements Addressed**: ask — \"Which GDD systems motivated this decision?\n What specific requirement in each GDD does this ADR address?\"\n - Append each missing section to the ADR file using the Edit tool.\n - For **Date** (counted only when there is no `## Last Verified`): append\n `## Date` with today's date — even when it is the only missing section, the\n case `/dev-story` sends you here for — and say that it records the retrofit,\n not when the decision was made.\n - **Never modify any existing section.** Only append or fill absent sections.\n6. Suggest: \"Run `/architecture-review` to re-validate coverage now that this ADR\n has its Status and Dependencies fields.\"\n\n\n"}