playtest-report
Generates a structured playtest report template or analyzes existing playtest notes into a structured format. Use this to standardize playtest feedback collection and analysis.
pinned to #984023dupdated last month
Ask your AI client: “install skills/playtest-report”.
Requires the metahub MCP server installed in your client. Set up MCP.
mh install skills/playtest-reportmetahub onboarded this repo on the author's behalf.
If you own github.com/Donchitos/Claude-Code-Game-Studios on GitHub, claim the listing to take over publishing. Your claim preserves the existing eval history and badges; only the curator label is replaced with verified-publisher on your next publish.
Stars
23,879
Last commit
last month
Latest release
published
- #ai-agents
- #ai-assisted-development
- #anthropic
- #claude
- #claude-code
- #game-design
- #game-development
- #gamedev
- #godot
- #indie-game-dev
- #unity
- #unreal-engine
About this skill
Pulled from SKILL.md at publish time.
Allowed tools
- Read
- Glob
- Grep
- Write
- Task
- AskUserQuestion
Automated checks the publisher passed at publish time — structure, docs, safety, and whether the artifact behaves as claimed.984023d· last month
Behavioral checks ran but aren't published for this artifact; the static checks above ran at publish time.
Documentation
8 passed1 warningHomepage or repository declaredwarn
No homepage or repository declared.
Add a "homepage" or "repository" field to SKILL.md.
Description quality
24 words · 176 chars — "Generates a structured playtest report template or analyzes existing playtest no…"
README is present and substantial
15,951 chars · 15 sections · 2 code blocks
Tags / topics declared
12 total — ai-agents, ai-assisted-development, anthropic, claude, claude-code, game-design (+6)
README has usage / example sections
found: Getting Started
Homepage / docs URL declared
no homepage declared (registry will use the repo URL) — info-only, not blocking
Description is substantive
Description is 24 words.
Documentation present and substantive
Documentation present (SKILL.md, 719 words).
Documentation shows usage
Documentation includes 1 code example.
Release history
1- releasecurrent984023dwarnlast month
Contents
Phase 1: Parse Arguments
Resolve the review mode (once, store for all gate spawns this run):
- If
--review [full|lean|solo]was passed → use that - Else read
production/review-mode.txt→ use that value - Else → default to
lean
See .claude/docs/director-gates.md for the full check pattern.
Determine the mode:
new→ generate a blank playtest report templateanalyze [path]→ read raw notes and fill in the template with structured findings
Phase 2A: New Template Mode
Generate this template and output it to the user:
# Playtest Report
## Session Info
- **Date**: [Date]
- **Build**: [Version/Commit]
- **Duration**: [Time played]
- **Tester**: [Name/ID]
- **Platform**: [PC/Console/Mobile]
- **Input Method**: [KB+M / Gamepad / Touch]
- **Session Type**: [First time / Returning / Targeted test]
## Test Focus
[What specific features or flows were being tested]
## First Impressions (First 5 minutes)
- **Understood the goal?** [Yes/No/Partially]
- **Understood the controls?** [Yes/No/Partially]
- **Emotional response**: [Engaged/Confused/Bored/Frustrated/Excited]
- **Notes**: [Observations]
## Gameplay Flow
### What worked well
- [Observation 1]
### Pain points
- [Issue 1 -- Severity: High/Medium/Low]
### Confusion points
- [Where the player was confused and why]
### Moments of delight
- [What surprised or pleased the player]
## Bugs Encountered
| # | Description | Severity | Reproducible |
|---|-------------|----------|-------------|
## Feature-Specific Feedback
### [Feature 1]
- **Understood purpose?** [Yes/No]
- **Found engaging?** [Yes/No]
- **Suggestions**: [Tester suggestions]
## Quantitative Data (if available)
- **Deaths**: [Count and locations]
- **Time per area**: [Breakdown]
- **Items used**: [What and when]
- **Features discovered vs missed**: [List]
## Overall Assessment
- **Would play again?** [Yes/No/Maybe]
- **Difficulty**: [Too Easy / Just Right / Too Hard]
- **Pacing**: [Too Slow / Good / Too Fast]
- **Session length preference**: [Shorter / Good / Longer]
## Top 3 Priorities from this session
1. [Most important finding]
2. [Second priority]
3. [Third priority]
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.
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-reportto 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 Task using gate CD-PLAYTEST (.claude/docs/director-gates.md).
Pass: the structured report content, game pillars and core fantasy (from design/gdd/game-concept.md), the specific hypothesis being tested.
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.
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-reviewon the updated GDD. - After fixing bugs: re-run
/bug-triageto update priorities.
Reviews
No reviews yet. Be the first.
Related
Verification Before Completion
Evidence before assertions, always
Writing Plans
Turn specs into phased implementation plans
Test-Driven Development
Red → green → refactor discipline for any feature or bugfix
mh install skills/playtest-report