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.

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).

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).

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]

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