Claude-Cowork-Game-Studio

Scan all GDDs against the entity registry to catch cross-document inconsistencies — same entity with different stats, same item with different values, same formula with different variables. Write-time drift safety net; run after each new GDD and before /create-architecture.

Decompose a game concept into individual systems, map dependencies, prioritize design order, and create the systems index. Run after /brainstorm and before /design-system when a concept exists but hasn't been broken into systems yet.

When a GDD is revised, scan all ADRs and the traceability index to find architectural decisions that are now potentially stale, produce a change-impact report, and guide the user through resolution. Run right after editing any GDD.

Generate design or architecture documents from existing implementation — works backwards from code or prototypes to create a missing GDD section, ADR, or concept doc. Use for undocumented features or inherited code.

Validate that a story file is implementation-ready before dev starts — checks embedded GDD requirements, ADR references, engine notes, clear acceptance criteria, and open design questions. Produces a READY / NEEDS WORK / BLOCKED verdict per story with a specific gap list.

Trace a Unity gameplay bug back to its original trigger instead of patching the symptom — use for issues that surface deep in execution, like health/HP desync, a timer or cooldown firing at the wrong moment, state or camera transitions glitching, spawns activating on the wrong wave/frame, or any behavior that diverges from what a design doc or GDD says. Trigger whenever the user describes a bug with "tại sao", "lỗi này do đâu", "sao nó lại", a stack trace, reproduction steps, or "X should happen but Y happens instead." Prefer this skill over jumping straight to a fix when the cause isn't obvious from the error site itself.

Verify that a finished story's implementation actually satisfies its acceptance criteria and GDD/epic spec, run or check its tests, and propose fixes for failures, without silently changing the spec to match the code. Use this as a deeper check alongside or before ccgs-story-done, such as when a story is marked ready for completion review, when tests are failing and need patching, or when the user asks "does this match the spec", "is this story actually done", or "why is this test failing." Distinct from unity-bug-root-cause (which traces unexplained bugs) — this skill specifically checks implementation against a written spec.

Review Unity C# code for Clean Architecture and SOLID compliance, with specific attention to the separation between MonoBehaviour/presentation, plain-C# domain logic, and Unity/infrastructure concerns. Use this whenever the user asks to review, audit, or sanity-check a script or system before merging it, asks "is this code clean?", flags tight coupling or untestable code, or wants a second opinion on how a new gameplay system should be structured. Also trigger proactively when a user pastes a new MonoBehaviour and asks for feedback, even if they don't say "architecture" or "SOLID" explicitly.

Write new Unity gameplay scripts test-first (red-green-refactor), structuring code so the core rule logic (health, timers/cooldowns, scoring, spawn timing) can be exercised in EditMode tests without a running scene. Use this whenever the user asks to implement a new gameplay feature, add a gameplay script, or says things like "viết feature mới", "implement story X", "add a system for Y" — especially when no tests exist yet for that system. Pairs well with unity-clean-architecture-review for structuring the split between logic and MonoBehaviour.