Game development workflow skills for Claude Code. 29 interactive skills for game development — strongest in design review and planning, with dev-phase support. When you notice the user is at these stages, suggest the appropriate skill: - User has a fragile mood/image/mechanic fragment and wants creative sparks, not critique → suggest /spark-lens - User has a PDF/doc/notes they want to turn into a GDD → suggest /game-import - Brainstorming a game idea → suggest /game-ideation - Reviewing a game plan (strategy/direction) → suggest /game-direction - Reviewing a game design document → suggest /game-review - Reviewing technical architecture for a game → suggest /game-eng-review - Reviewing game economy or balance → suggest /balance-review - Simulating player experience → suggest /player-experience - Reviewing game UI/UX → suggest /game-ux-review - Evaluating a game pitch or proposal → suggest /pitch-review - Code review on a game project → suggest /gameplay-implementation-review - QA testing a game → suggest /gam
Asset pipeline QA. Checks naming conventions, file formats, performance budgets, style consistency (deviation counting, not quality judgment), and pipeline health. Use when you have game assets to audit — NOT for in-engine visual review (use /game-visual-qa) or architecture review (use /game-eng-review).
Use when a game has numbers that need checking — difficulty curves, currency flow, gacha rates, progression pacing, grind ratios, or pay-to-win concerns. Not for visual design, narrative, core loop evaluation (use /game-review), or player experience walkthrough (use /player-experience).
Use when a prototype or build exists and you need to know: is this worth playing? Not QA (use /game-qa for bugs), not feel (use /feel-pass for responsiveness), not code (use /gameplay-implementation-review). This evaluates the EXPERIENCE: does the loop close, does the session hold, does the player want to come back.
Safety mode. Warns before destructive commands (rm -rf, DROP TABLE, git push -f, force delete). Does NOT restrict file editing scope — use /guard for that.
Use when a prototype or playable build exists and you need to know if a mechanic feels alive or dead — responsiveness, impact, rhythm, feedback chains, dead time. Not for GDD review (use /game-review), not for code review (use /gameplay-implementation-review), not for bug hunting (use /game-debug). Requires a playable build or detailed video of gameplay.
Adversarial second opinion for game code and design. Independent review from a fresh context, focused on game-specific failure modes. 3-pass exploit methodology (attack surface → systematic scan → creative exploitation), design challenge with fallacy detection, and structured consulting.
Game debugging and root cause analysis. Analyzes crash dumps, performance bottlenecks, physics glitches, network desync, and gameplay bugs through structured hypothesis testing.