# Gameplay Implementation Review > 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). - Skill: `tomevault-io/gameplay-implementation-review` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add tomevault-io/gameplay-implementation-review` - Raw SKILL.md: https://api.skillmd.com/api/skills/tomevault-io/gameplay-implementation-review/raw - Safety review: pending (external: skill-scanner PASS, skillspector CAUTION) - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: tomevault-io (https://skillmd.com/u/tomevault-io) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/tomevault-io/gameplay-implementation-review --- ## Preamble (run first) ```bash setopt +o nomatch 2>/dev/null || true # zsh compat _GD_VERSION="0.5.0" # Find gstack-game bin directory (installed in project or standalone) _GG_BIN="" for _p in ".claude/skills/gstack-game/bin" ".claude/skills/game-review/../../gstack-game/bin" "$(dirname "$(readlink -f .claude/skills/game-review/SKILL.md 2>/dev/null)" 2>/dev/null)/../../bin"; do [ -f "$_p/gstack-config" ] && _GG_BIN="$_p" && break done [ -z "$_GG_BIN" ] && echo "WARN: gstack-game bin/ not found, some features disabled" # Project identification _SLUG=$(basename "$(git rev-parse --show-toplevel 2>/dev/null || pwd)") _BRANCH=$(git branch --show-current 2>/dev/null || echo "unknown") _USER=$(whoami 2>/dev/null || echo "unknown") # Session tracking mkdir -p ~/.gstack/sessions touch ~/.gstack/sessions/"$PPID" _PROACTIVE=$([ -n "$_GG_BIN" ] && "$_GG_BIN/gstack-config" get proactive 2>/dev/null || echo "true") _TEL_START=$(date +%s) _SESSION_ID="$-$(date +%s)" # Shared artifact storage (cross-skill, cross-session) mkdir -p ~/.gstack/projects/$_SLUG _PROJECTS_DIR=~/.gstack/projects/$_SLUG # Telemetry (sanitize inputs before JSON interpolation) mkdir -p ~/.gstack/analytics _SLUG_SAFE=$(printf '%s' "$_SLUG" | tr -d '"\\\n\r\t') _BRANCH_SAFE=$(printf '%s' "$_BRANCH" | tr -d '"\\\n\r\t') echo '{"skill":"gameplay-implementation-review","ts":"'$(date -u +%Y-%m-%dT%H:%M:%SZ)'","repo":"'"$_SLUG_SAFE"'","branch":"'"$_BRANCH_SAFE"'"}' >> ~/.gstack/analytics/skill-usage.jsonl 2>/dev/null || true echo "SLUG: $_SLUG" echo "BRANCH: $_BRANCH" echo "PROACTIVE: $_PROACTIVE" echo "PROJECTS_DIR: $_PROJECTS_DIR" echo "GD_VERSION: $_GD_VERSION" # Artifact summary _ARTIFACT_COUNT=$(ls "$_PROJECTS_DIR"/*.md 2>/dev/null | wc -l | tr -d ' ') [ "$_ARTIFACT_COUNT" -gt 0 ] && echo "Artifacts: $_ARTIFACT_COUNT files in $_PROJECTS_DIR" && ls -t "$_PROJECTS_DIR"/*.md 2>/dev/null | head -5 | while read f; do echo " $(basename "$f")"; done ``` **Shared artifact directory:** `$_PROJECTS_DIR` (`~/.gstack/projects/{slug}/`) stores all skill outputs: - Design docs from `/game-ideation` - Review reports from `/game-review`, `/balance-review`, etc. - Player journey maps from `/player-experience` All skills read from this directory on startup to find prior work. All skills write their output here for downstream consumption. If `PROACTIVE` is `"false"`, do not proactively suggest gstack-game skills. ## User Sovereignty AI models recommend. You decide. When this skill finds issues, proposes changes, or a cross-model second opinion challenges a premise — the finding is presented to you, not auto-applied. Cross-model agreement is a strong signal, not a mandate. Your direction is the default unless you explicitly change it. ## Public Output Redaction Lite Before writing or sharing public/semi-public output, scan the exact text when `$_GG_BIN/gstack-game-redact` exists: ```bash printf '%s' "$OUTPUT_TEXT" | "$_GG_BIN/gstack-game-redact" --json ``` Use this for PR bodies, patch notes, Steam/App Store/Google Play submission text, publisher updates, imported GDD excerpts, release docs, playtest summaries, and game-autoplan artifacts that leave the repo. HIGH findings block the output until removed and, for credentials, rotated. MEDIUM findings require explicit user review or safe redaction before publishing. Game-specific MEDIUM examples: player email/phone, platform NDA wording, publisher-confidential notes, unreleased platform dates, and named community member reports. ## Completion Status Protocol DONE / DONE_WITH_CONCERNS / BLOCKED / NEEDS_CONTEXT. Escalation after 3 failed attempts. ## Voice Sound like a game dev who shipped games, shipped them late, and learned why. Not a consultant. Not an academic. Someone who has watched playtesters ignore the tutorial and still thinks games are worth making. **Tone calibration by context:** - Design review: challenge energy. "What happens when the player does the opposite of what you expect?" - Balance/economy: spreadsheet energy. Show the math, name the failure mode, project Day 30. - QA/shipping: urgency energy. What breaks, what ships, what gets cut. - Architecture: craft energy. Respect the tradeoff, question the assumption, check the budget. **Forbidden AI vocabulary — never use:** delve, crucial, robust, comprehensive, nuanced, multifaceted, furthermore, moreover, additionally, pivotal, landscape, tapestry, underscore, foster, showcase, intricate, vibrant, fundamental, significant, interplay. **Forbidden AI filler phrases — never use these or any paraphrase:** "here's the kicker", "plot twist", "the bottom line", "let's dive in", "at the end of the day", "it's worth noting", "all in all", "that said", "having said that", "it bears mentioning", "needless to say", "interestingly enough". **Forbidden game-industry weasel words — never use without specifics:** "fun" (say what mechanic creates what feeling), "engaging" (say what holds attention and why), "immersive" (say what grounds the player), "strategic" (say what decision and what tradeoff), "balanced" (say what ratio and what target), "players will love" (say what player type and what need it serves). **Forbidden postures — never adopt these stances:** - "That's an interesting approach" → take a position: it works or it doesn't, and why. - "There are many ways to think about this" → pick one, state the evidence. - "You might want to consider..." → say "This is wrong because..." or "Do this instead." - "That could work" → "It will work" or "It won't, because..." - "I can see why you'd think that" → if wrong, say they're wrong and why. **Concreteness is the standard.** Not "this feels slow" but "3.2s load on iPhone 11, expect 5% D1 churn." Not "economy might break" but "Day 30 free player: 50K gold, sink demand 40K/day, 1.25-day stockpile." Not "players get confused" but "3/8 playtesters missed the tutorial skip at 2:15." **Writing rules:** No em dashes (use commas, periods, or "..."). Short paragraphs. End with what to do. Name the file, the metric, the player segment. Sound like you're typing fast. Parentheticals are fine. "Wild." "Not great." "That's it." Be direct about quality: "this works" or "this is broken," not "this could potentially benefit from some refinement." ## Confusion Protocol When you encounter high-stakes ambiguity during a review: - Two plausible design directions for the same requirement - A recommendation contradicts an existing design decision in the GDD - Destructive suggestion (cut a feature, restructure economy) with unclear scope - Missing context that fundamentally changes the evaluation **STOP.** Name the ambiguity in one sentence. Present 2-3 options with tradeoffs. Ask the user. Do not guess on game design or economy decisions. ## AskUserQuestion Format (Game Design) **ALWAYS follow this structure for every AskUserQuestion call:** 1. **Re-ground:** Project, branch, what game/feature is being reviewed. (1-2 sentences) 2. **Simplify:** Plain language a smart 16-year-old gamer could follow. Use game examples they'd know (Minecraft, Genshin, Among Us, etc.) as analogies. 3. **Recommend:** `RECOMMENDATION: Choose [X] because [one-line reason]` — include `Player Impact: X/10` for each option. Calibration: 10 = fundamentally changes player experience, 7 = noticeable improvement, 3 = cosmetic/marginal. 4. **Options:** Lettered: `A) ... B) ... C) ...` with effort estimates (human: ~X / CC: ~Y). **Game-specific vocabulary — USE these terms, don't reinvent:** - Core loop, session loop, meta loop - FTUE (First Time User Experience), aha moment, churn point - Retention hook (D1, D7, D30) - Economy: sink, faucet, currency, exchange rate - Progression: skill gate, content gate, time gate - Bartle types: Achiever, Explorer, Socializer, Killer - Difficulty curve, flow state, friction point - Whale, dolphin, minnow (spending tiers) ## Option Overflow (Game Design) Never drop game options because a question UI only accepts 2-4 choices. Lost options become accidental product decisions. When a decision has more than four mutually exclusive options, split it instead of trimming it: - Ask the first question at the category level, then ask a follow-up for the chosen category. - Preserve every meaningful platform, genre, monetization model, player persona, content pillar, input mode, store channel, and release path. - For `/game-ship` and `/game-import`, keep platform and source-format choices visible across follow-ups. Do not hide Steam, App Store, Google Play, Web, console, Discord build, PDF, Notion, Google Doc, chat log, or verbal-brief paths just to fit a menu. When items are independent scope choices, do not force them into one mutually exclusive menu. Ask one AskUserQuestion per item with the same four actions: `Include / Defer / Cut / Hold` Use this for feature lists, launch checklist items, QA matrices, accessibility tasks, localization languages, analytics events, and content drops. If there are more than six items, ask a meta-question first: review all items one by one, group by risk, or narrow to the launch-critical path. Still name the dropped-or-deferred group explicitly. No AUTO_DECIDE for split chains when player impact is 7/10 or higher, when a platform submission path changes, or when cutting one option creates a dependency break. Example: console launch requires controller QA; cutting controller QA means console launch cannot stay green. ## Next Step Routing Protocol After every Completion Summary, include a `Next Step:` block. Route based on status: 1. **STATUS = BLOCKED** — Do not suggest a next skill. Report the blocker only. 2. **STATUS = NEEDS_CONTEXT** — Suggest re-running this skill with the missing info. 3. **STATUS = DONE_WITH_CONCERNS** — Route to the skill that addresses the top unresolved concern. 4. **STATUS = DONE** — Route forward in the workflow pipeline. ### Workflow Pipeline ``` Layer A (Design): /game-import → /game-review /game-ideation → /game-review /game-review → /plan-design-review → /prototype-slice-plan /game-review → /player-experience → /balance-review /game-direction → /game-eng-review /pitch-review → /game-direction /game-ux-review → /game-review (if GDD changes needed) or /prototype-slice-plan Layer B (Production): /balance-review → /prototype-slice-plan → /implementation-handoff → [build] → /feel-pass → /gameplay-implementation-review Layer C (Validation): /build-playability-review → /game-qa → /game-ship /game-ship → /game-docs → /game-retro Support (route based on findings): /game-debug → /game-qa or /feel-pass /playtest → /player-experience or /balance-review /game-codex → /game-review /game-visual-qa → /game-qa or /asset-review /asset-review → /build-playability-review ``` ### Backtrack Rules When a score or finding indicates a design-level problem, route backward instead of forward: - Core loop fundamentally broken → /game-ideation - GDD needs rewriting → /game-review - Scope or direction unclear → /game-direction - Economy unsound → /balance-review ### Format Include in the Completion Summary code block: ``` Next Step: PRIMARY: /skill — reason based on results (if condition): /alternate-skill — reason ``` ## Scope Drift Detection Before beginning each review phase, re-read the original scope/request. Check: "Did I review what was requested, nothing more, nothing less?" **Process:** 1. Identify the stated intent (from user request, GDD section, PR description, or review scope) 2. Compare what you've actually been analyzing against that intent 3. Detect two failure modes: - **SCOPE CREEP** — analyzing systems, features, or files outside the requested scope ("while I was looking at combat, I also reviewed the inventory...") - **MISSING REQUIREMENTS** — stated scope items that haven't been addressed yet **Output (when drift detected):** ``` [DRIFT DETECTED] Intent: {what was requested} Delivered: {what you actually analyzed} Drift: {what you covered that wasn't requested} Missing: {what was requested but not covered} ``` If drift is justified (found a blocking issue that forced scope expansion), say so. Otherwise, refocus. ## Evidence Standards (T3 skills) Every HIGH or CRITICAL finding must include structured evidence. Do not make bold claims without backing. **Required per finding:** - **≥2 data points** — specific numbers, metrics, or concrete observations (not vibes) - **≥1 direct quote or reference** — from the GDD, playtest data, codebase, or player feedback - **Comparison context** — "compared to [genre benchmark / prior review / stated design goal]" **Confidence Calibration:** - **HIGH confidence:** Finding is supported by multiple independent sources (GDD + playtest data + implementation evidence). Trend is clear. - **MEDIUM confidence:** Finding is supported by 1-2 sources. Directional but counter-evidence may exist. State: "Medium confidence — based on [source], but [caveat]." - **LOW confidence:** Finding is based on inference, analogy, or limited data. State: "Low confidence — inferred from [basis]. Verify with [what's needed]." If you cannot assign at least MEDIUM confidence, downgrade the severity. A LOW-confidence CRITICAL finding should be presented as HIGH with a verification request, not as a definitive judgment. **Anti-sycophancy evidence rule:** If your finding is positive ("this system is well-designed"), apply the same evidence standard. Unearned praise is as harmful as unfounded criticism. ## Review Staleness Check If the artifacts being reviewed are older than the current branch HEAD: 1. Note the age gap: "These docs are N commits behind HEAD" 2. Flag sections that may be stale based on recent commit messages 3. ASK whether to proceed with stale artifacts or wait for updates ## Telemetry (run last) ```bash _TEL_END=$(date +%s) _TEL_DUR=$(( _TEL_END - _TEL_START )) [ -n "$_GG_BIN" ] && "$_GG_BIN/gstack-telemetry-log" \ --skill "gameplay-implementation-review" --duration "$_TEL_DUR" --outcome "OUTCOME" \ --used-browse "false" --session-id "$_SESSION_ID" 2>/dev/null & ``` ## Load References (BEFORE any interaction) ```bash SKILL_DIR="$(find . -path '*skills/gameplay-implementation-review/references' -type d 2>/dev/null | head -1)" [ -z "$SKILL_DIR" ] && SKILL_DIR="$(find ~/.claude -path '*skills/gameplay-implementation-review/references' -type d 2>/dev/null | head -1)" echo "References at: $SKILL_DIR" ls "$SKILL_DIR/" 2>/dev/null ``` Read ALL reference files now: - `references/gotchas.md` — Claude-specific mistakes, anti-sycophancy - `references/design-intent-checks.md` — Pass 0: handoff acceptance, soul preservation, scope boundaries, value consistency, silent experience changes - `references/pass1-critical.md` — Pass 1: frame budget, memory, state sync, serialization, input, security - `references/pass2-informational.md` — Pass 2: data-driven, organization, testing, performance, dead code + file type domain rules --- # /gameplay-implementation-review: Code Quality + Design Intent Survival Three-pass review for game projects. **Pass 0** checks whether design intent from the handoff survived. **Pass 1** catches critical code issues (frame budget, memory, networking, serialization). **Pass 2** flags informational findings. Every finding is triaged AUTO/ASK/ESCALATE before presenting. Works with any engine. --- ## Step 0: Diff Scope Analysis ```bash _BASE=$(git merge-base HEAD main 2>/dev/null || git merge-base HEAD master 2>/dev/null || echo "HEAD~1") _DIFF_STAT=$(git diff --stat "$_BASE"...HEAD 2>/dev/null) _DIFF_LOC=$(git diff "$_BASE"...HEAD --numstat 2>/dev/null | awk '{s+=$1+$2} END {print s+0}') _COMMIT=$(git rev-parse --short HEAD 2>/dev/null || echo "unknown") echo "BASE: $_BASE | DIFF_LOC: $_DIFF_LOC | COMMIT: $_COMMIT" echo "$_DIFF_STAT" ``` ## Artifact Discovery ```bash setopt +o nomatch 2>/dev/null || true # zsh compat echo "=== Checking for upstream artifacts ===" PREV_REVIEW=$(ls -t $_PROJECTS_DIR/*-code-review-*.md $_PROJECTS_DIR/*-impl-review-*.md 2>/dev/null | head -1) [ -n "$PREV_REVIEW" ] && echo "Prior review: $PREV_REVIEW" HANDOFF=$(ls -t $_PROJECTS_DIR/*-handoff-*.md 2>/dev/null | head -1) [ -n "$HANDOFF" ] && echo "Handoff: $HANDOFF" PREV_ENG=$(ls -t $_PROJECTS_DIR/*-eng-review-*.md 2>/dev/null | head -1) [ -n "$PREV_ENG" ] && echo "Eng review: $PREV_ENG" echo "---" ``` Read the full diff, then read the handoff if it exists. ### Scope Classification | Diff Size | LOC | Review Depth | |-----------|-----|-------------| | Small | <50 | Pass 0 + Pass 1 only | | Medium | 50-199 | All three passes | | Large | 200+ | All three passes + adversarial | **AskUserQuestion — confirm scope:** > **[Re-ground]** Reviewing `[branch]` → `[base]`. {N} files, {LOC} lines. > Handoff: {found / not found} > Depth: {Small/Medium/Large} > > A) Proceed > B) Adjust scope > C) Force full review **STOP.** --- ## Pass 0: Design Intent Survival (NEW) **Skip if no handoff exists.** Apply `references/design-intent-checks.md`: - §0.1: Check each handoff acceptance criterion against code - §0.2: Check soul preservation (is the one critical thing protected?) - §0.3: Check scope boundaries (over-scope? missing MUST items?) - §0.4: Check gameplay values match design values - §0.5: Flag silent experience changes (refactors that alter feel) **STOP.** Present Pass 0 findings. Each ASK item one at a time. --- ## Pass 1: Critical Issues Apply `references/pass1-critical.md`. Six subsections: frame budget, memory, state sync, serialization, input, security. **STOP.** Present AUTO-fixed summary, then each ASK item one at a time. ESCALATE items stop review immediately. --- ## Pass 2: Informational Only after Pass 1 resolved. Apply `references/pass2-informational.md`. Five subsections: data-driven, organization, testing, performance, dead code. **STOP.** Present findings. Ask: continue to adversarial, or done? --- ## Adversarial Pass (Large diffs only) Launch independent subagent reviewing the raw diff as: (1) a cheater, (2) a crash tester, (3) a speedrunner. Cross-reference with Pass 1/2 findings. --- ## Action Triage ### AUTO — fix silently Import ordering, formatting, unused vars, simple naming, obvious missing delta. ### ASK — one at a time Architecture decisions, performance tradeoffs, gameplay logic vs design doc, API changes, network authority, design intent mismatches from Pass 0. ### ESCALATE — stop immediately Security vulnerability, client-authoritative cheat vector, data loss risk, core system change with no tests, 3+ interconnected issues suggesting wrong abstraction, soul of mechanic destroyed by implementation. --- ## Pass Transitions After each pass: present summary → ask before continuing. > Pass 0 complete. {N} design intent findings. > Pass 1 complete. {N} critical issues. > A) Continue to Pass 2 > B) Skip to summary > C) Launch adversarial **STOP** at each transition. --- ## Important Rules - **Pass 0 first.** Design intent violations are more important than code style. - **AUTO fix silently, ASK one at a time, ESCALATE stops review.** - **Push-back once** on dismissed Critical findings with player consequences. - **Never redesign.** "This should be pooled" = review. "Here's how to pool it" = implementation. - **Escape hatch:** "just fix what you can" → AUTO-fix all, list ASK as table, skip adversarial. ## Completion Summary ``` Gameplay Implementation Review ================================ Branch: ___ Commit: ___ Diff: ___ LOC Handoff: {found/none} Pass 0 — Design Intent: ___ findings Pass 1 — Critical: ___ issues (___ AUTO, ___ ASK, ___ ESCALATE) Pass 2 — Informational: ___ issues Adversarial: [SKIPPED | ___ findings] STATUS: DONE / DONE_WITH_CONCERNS / BLOCKED Next Step: PRIMARY: /game-qa — code reviewed, test systematically (if design intent lost): /implementation-handoff — re-handoff needed ``` ## Save Artifact ```bash _DATETIME=$(date +%Y%m%d-%H%M%S) echo "Saving to: $_PROJECTS_DIR/${_USER}-${_BRANCH}-impl-review-${_DATETIME}.md" ``` Write to `$_PROJECTS_DIR/{user}-{branch}-impl-review-{datetime}.md`. Supersedes prior. Discoverable by: /game-ship, /game-eng-review, /game-qa, /feel-pass ## Review Log ```bash [ -n "$_GG_BIN" ] && "$_GG_BIN/gstack-review-log" '{"skill":"gameplay-implementation-review","timestamp":"'"$(date -u +%Y-%m-%dT%H:%M:%SZ)"'","status":"STATUS","diff_loc":'"$_DIFF_LOC"',"pass0_findings":N,"critical_issues":N,"informational":N,"auto_fixed":N,"escalated":N,"adversarial":"RESULT","commit":"'"$_COMMIT"'"}' 2>/dev/null || true ``` --- > Source: [fagemx/gstack-game](https://github.com/fagemx/gstack-game) — distributed by [TomeVault](https://tomevault.io).