/game-playtest

name: game-playtest
description: >
  Plans, runs and analyzes playtests: research questions, observation and think-aloud protocols,
  remote and browser sessions (itch.io, Steam Playtest), consent, surveys and evidence-graded
  findings, with AI playtest agents as validated supplements. Use for "playtest", "player feedback",
  "playtest report". Not for bug hunting or test automation (use game-qa-lead).
argument-hint: "[build, feature or question to test]"
allowed-tools: Read, Glob, Grep, Write, Edit, AskUserQuestion
effort: medium

AlterLab GameForge -- Structured Playtest

Playtesting is not asking players whether they had fun. It is disciplined observation of what players do, so you can see where the design communicates and where it fails. What players say is useful context; what their hands do is evidence. This workflow turns sessions with real people into findings the team can act on, and keeps the newer tools (AI playtest agents, feedback summarizers, browser builds) in their proper place: useful supplements, never the primary instrument.

Purpose & Triggers

**Use this workflow when:**

• A build is ready for outside eyes and you need structured findings, not reactions.
• A specific design question needs an answer: "Do players understand crafting?" rather than "Is it good?"
• Onboarding needs validation: can a new player learn the core verb without a tutorial?
• The difficulty curve needs checking against real players, not the team's muscle memory.
• You have raw notes, recordings, survey exports or Discord/Steam feedback to analyze.
• You want a repeatable remote or browser-based playtest setup as a solo developer.

**Do NOT use this workflow when:**

| Need | Route to | |---|---| | Testing one raw mechanic in isolation | `game-prototype` | | Finding bugs, smoke tests, automated or AI-agent QA runs | `game-qa-lead` | | Tuning numbers, simulations, win rates | `game-balance-check` | | Heuristic usability review or onboarding redesign | `game-ux-designer` | | Testing with disabled players, accommodation checks | `game-accessibility-specialist` (co-run) | | Building the telemetry pipeline and dashboards | `game-analytics-setup` | | Market validation, wishlist tests, marketing quotes | `game-market-research` | | Publishing a public web build to portals | `game-web-publish` |

If the build crashes or softlocks on the path you want to test, stop: run the playtest-build gate in `game-qa-lead` first. Testers who spend the session hitting bugs give you bug reports, not design findings.

Inputs I Read First

• `.gameforge/project.json` (phase, pillars, engine), the GDD sections for the feature under test

in `design/`, previous reports in `tests/playtests/`, and `production/session-state/active.md`.

• Then ask up to three AskUserQuestion items, each with a default:

1. **Goal**: first impression (default for early builds), targeted feature, difficulty curve, full playthrough. 2. **Format**: remote moderated over a call (default for solo devs), in person, remote unmoderated (browser build or Steam Playtest). 3. **Tester pool**: friends of friends, the game's Discord, strangers (Steam Playtest, itch.io restricted page). Default: people who have never seen the game and match the target audience.

Critical Rules

1. **Questions before testers.** Every playtest answers 3-5 specific, observable questions. "Is it fun?" is not a question. "Do players use the dodge roll unprompted in the first two encounters?" is. 2. **The facilitator does not play, help or react.** Your neutral face is an instrument. If a tester asks "what do I do?", answer "what do you think you should do?" 3. **Size the round to the question.** About five testers per round surfaces most qualitative usability problems for one homogeneous audience segment (Jakob Nielsen, "Why You Only Need to Test with 5 Users", 2000), provided you iterate and test again. Quantitative claims (completion rate, average rating, A/B differences) need far more; below about 20 testers, report counts ("4 of 6"), not percentages. 4. **The team is not the sample.** Internal sanity passes are fine; they do not count as playtests. The team cannot un-know the game. 5. **Behavior outranks words.** "The controls feel fine" plus 11 wrong-button presses in ten minutes is a controls finding. 6. **Observe now, interpret later.** Record what happened during the session. Decide what it means afterward, with all sessions side by side. 7. **Humans are the primary instrument.** AI playtest agents and feedback summarizers supplement human sessions; their output is a lead to check, never a finding on its own. 8. **Consent before recording.** No screen, face, voice or telemetry capture without informed, written consent that says who will see it, how long it is kept and whether any AI service processes it. 9. **Ground the analysis in theory.** Use Flow and MDA from `${CLAUDE_PLUGIN_ROOT}/docs/game-design-theory.md` when reading engagement and difficulty.

Workflow

**Step 1: Define Questions and Signals**

Write 3-5 questions. Each must be observable (answerable by watching), actionable (the answer changes a design decision) and scoped (answerable in one session). For each question, define:

• **Positive signals**: behaviors that mean the design works.
• **Negative signals**: behaviors that mean it fails.
• **Observation window**: where in the session to watch closest.

Q2: Do players discover the grapple without the tooltip?
  Positive: uses grapple on the first anchor within 60 s of seeing it
  Negative: walks past 2+ anchors; tries to jump the gap 3+ times
  Window:   Room 4 (first anchor) through Room 6

**Step 2: Choose the Format**

| Format | Best for | You lose | |---|---|---| | In person, silent observation | First impressions, onboarding, emotion | Scale; testers act politer when watched closely | | Remote moderated (call + screen share + webcam) | Default for small teams; targe