playtest-report

!bash "${CLAUDE_SKILL_DIR}/../../hooks/yaml-helper.sh" resolve_config --keys review_mode,automation

Resolved above — use as-is; --review overrides review_mode for this run. No block → defaults in .claude/docs/config-resolution.md.

Playtest Report

Phase 1: Parse Arguments

See .claude/docs/director-gates.md for the full check pattern. Individual gate definitions live in .claude/docs/director-gates/[gate-id].md — the spawned agent reads its own gate file; do not read it in the parent session.

Every AskUserQuestion call follows .claude/docs/automation-modes.md (collaborative asks always · guided major-only · autonomous logs and proceeds; automation_always_ask categories always prompt).

Determine the mode:

• new → generate a blank playtest report template. This mode ends after Phase 2A: a blank template has nothing to route, review or save.
• analyze [path] → read raw notes and fill in the template with structured findings
• No argument → ask via AskUserQuestion: [A] New blank template / [B] Analyze notes — I'll give you the path

Phase 2A: New Template Mode

Generate this template and output it to the user:

# Playtest Report

In new mode, stop here with: Verdict: COMPLETE — blank template output; nothing saved.

Phase 2B: Analyze Mode

Read the raw notes at the provided path. Cross-reference with existing design documents. Fill in the template above with structured findings. Flag any playtest observations that conflict with design intent.

An observation that describes a defect — a crash, a framerate drop, a softlock, something that plainly breaks rather than plays badly — goes in the Bugs Encountered table, not under Gameplay Flow → Pain points, and is routed as a bug in Phase 3. Pain points are for how the game feels to play.

Phase 3: Action Routing

Categorize all findings into four buckets:

• Design changes needed — fun issues, player confusion, broken mechanics, observations that conflict with the GDD's intended experience
• Balance adjustments — numbers feel wrong, difficulty too spiked or too flat
• Bug reports — clear implementation defects that are reproducible
• Polish items — not blocking progress, but friction or feel issues for later

Present the categorized list, then route:

• Design changes: "Run /propagate-design-change [path] on the affected design document to find downstream impacts before making changes."
• Balance adjustments: "Run /balance-check [system] to verify the full balance picture before tuning values."
• Bugs: "Use /bug-report to formally track these."
• Polish items: "Add to the polish backlog in production/ when the team reaches that phase."

Phase 3b: Creative Director Player Experience Review

Review mode check — apply before spawning CD-PLAYTEST:

• solo → skip. Note: "CD-PLAYTEST skipped — Solo mode." Proceed to Phase 4 (save the report).
• lean → skip (not a PHASE-GATE). Note: "CD-PLAYTEST skipped — Lean mode." Proceed to Phase 4 (save the report).
• full → spawn as normal.

After categorising findings, spawn creative-director via Agent using gate CD-PLAYTEST (.claude/docs/director-gates/cd-playtest.md).

Pass: the structured report content, game pillars and core fantasy (from design/gdd/game-concept.md), the specific hypothesis being tested. If game-concept.md does not exist — expected at minimal, where design/game-brief.md replaces it — the brief has no pillars: pass its one-sentence pitch and its "Who it's for / what they feel" line instead, and say they stand in for pillars. If neither document exists, say so in the prompt: "No pillars available — assess against the hypothesis alone." A director gate handed silence about pillars will invent them.

Present the creative director's assessment before saving the report. If CONCERNS or REJECT, add a ## Creative Director Assessment section to the report capturing the verdict and feedback. If APPROVE, note the approval in the report. If NOT ASSESSED (the director lacked an input — .claude/docs/director-gates.md), add the same section naming what was missing; it is not an approval.

Phase 4: Save Report

Ask: "May I write this playtest report to production/qa/playtests/playtest-[date]-[tester].md?"

If yes, write the file, creating the directory if needed.

Phase 5: Next Steps

Verdict: COMPLETE — playtest report generated.

• Act on the highest-priority finding category first.
• After addressing design changes: re-run /design-review on the updated GDD.
• After fixing bugs: re-run /bug-triage to update priorities.