gstack-game

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.

Game direction review from producer/creative director perspective. Challenges premises, evaluates scope, market positioning, and strategic alignment.

Game release documentation update. Generates player-facing patch notes, internal changelog, and updates all project documentation after a release.

Game technical architecture review. Evaluates engine choice, rendering pipeline, networking, physics, data persistence, and platform adaptation.

Interactive game concept brainstorming. Structures raw ideas into Fantasy/Loop/Twist, challenges assumptions with forcing questions, and validates with Iceberg framework.

Import and standardize game design documents from any format (PDF, Notion export, Google Doc, chat logs, verbal description) into the gstack-game standard markdown structure at docs/gdd.md. Gateway skill — run this first before /game-review or any other review skill.

Systematic game QA. Tests functional correctness, visual quality, performance, audio, input, compatibility, localization, and progression integrity.

Game development sprint/milestone retrospective. Tracks feature completion, bug density trends, velocity, and team health with quantitative metrics.

Trigger: User wants a structured review of a Game Design Document (GDD). Use when: "review my GDD", "game review", "check my game design", "how's my GDD", "/game-review", or user has a docs/gdd.md and asks for design feedback. Do NOT use when: User wants code review (use /review), balance-specific analysis (use /balance-review), or brainstorming from scratch (use /game-ideation).

Game release workflow. Build, test, changelog, PR, platform submission. Supports Steam, App Store, Google Play, Web, and custom pipelines.

Game UI/UX review. Evaluates HUD readability, menu flow, shop interface, tutorial UI, controller/touch adaptation, and accessibility.

Visual QA for games. Reviews art style consistency, UI alignment, animation quality, screen adaptation, and visual polish.

Use when a PR or code change exists for a game project and you need to review it for both code quality AND design intent survival. Evolved from /game-code-review — adds Pass 0 checking whether design intent from handoff survived implementation. Not for reviewing design docs (use /game-review), not for feel evaluation (use /feel-pass), not for playability (use /build-playability-review).

Full safety mode. Combines /careful (destructive command warnings) with file scope restriction. Prevents editing files outside a specified directory.

Use when a prototype slice plan exists and you need to translate design intent into a build package that a coding agent or developer can execute. Not for deciding what to build (use /prototype-slice-plan), not for reviewing built code (use /gameplay-implementation-review), not for evaluating architecture (use /game-eng-review).

Game pitch/proposal review — triggered when user has a game concept, pitch deck, or GDD to evaluate. Scores market positioning, differentiation, feasibility, business case, and pitch quality. Outputs a weighted Pitch Health Score with GREENLIGHT / PROTOTYPE FIRST / PIVOT / PASS recommendation.

Designer's eye plan review for games. Rates 7 design dimensions 0-10, explains what a 10 looks like, then fixes the plan to get there. Use when a game plan exists but UI/UX decisions need to be specified before implementation. Proactively suggest when the user has a plan with UI components that should be reviewed before building.

First-person player experience walkthrough — simulates playing the game as a specific persona, narrating moment-by-moment what the player sees, feels, and does. Use when you want to find friction, confusion, and churn risks through role-play rather than analysis.

Playtest protocol design. Creates test plans, defines observation metrics, structures feedback collection, and designs data analysis frameworks.

Use when design review is done and you need to decide what to build FIRST — which slice, what hypothesis to test, what to fake, what failure looks like. Not for brainstorming (use /game-ideation), not for reviewing a GDD (use /game-review), not for handing off to implementation (use /implementation-handoff after this skill).

Low-pressure creative spark facilitation for early game ideas. Use when the user wants to protect enthusiasm, explore a half-formed concept, turn a feeling, image, character, mechanic, dream, or unfinished fragment into richer game possibilities, or leave an emotional imprint on the project before formal ideation/review. Avoid scoring, critique, feasibility checks, market language, investment language, pitch language, and forced deliverables.

Entry point for new users. Detects project state from existing artifacts, asks 0-2 targeted questions, and routes to the right skill. Run this when you don't know which gstack-game skill to start with.

Deactivate /guard scope restriction. Returns to normal editing mode.

End-to-end issue pipeline: plan → implement → review → merge. Dispatches parallel sub-agents with worktree isolation. Usage: /issue-pipeline 33 34 35 [--skip-plan] [--skip-review] [--no-merge]

Iteratively review PR, post comment, fix issues, and re-review until LGTM

Start working on a gstack-game GitHub issue with a three-phase deep-dive workflow (research → innovate → plan). Reads affected skills, explores solution approaches, produces implementation plan, posts all phases to the issue. Run as: /issue-plan 123

Implement an approved plan for a gstack-game GitHub issue. Reads deep-dive artifacts, creates feature branch, executes plan steps, runs build+test, creates PR. Run after /issue-plan when plan is approved.

Use when a GitHub Issue with domain knowledge (gotcha, benchmark, forcing question, scoring calibration) needs to be integrated into a skill's references/ files. Reads the Issue, converts to proper format, checks for contradictions, creates a PR. Run as: /contribute-review #123 or /contribute-review scan.

Create GitHub issues for gstack-game improvements — skill gaps, wrong benchmarks, new skill proposals, template bugs. Maps conversation context into actionable issues with proper labels and skill references.

Use when you need to assess the quality of a gstack-game skill, decide which skill to improve next, or refactor a skill for progressive disclosure. Run on a single skill or scan all skills. Not for reviewing game designs (use /game-review) or code (use /gameplay-implementation-review).