Prompt
Write A Playtest Feedback Summary
Use this when you need to share playtest findings with the team.
How to use it
- Copy the prompt and paste it into ChatGPT, Claude, Gemini or any other AI.
- Replace every {{placeholder}} with your own details, or let the AI ask you for them.
- Use the follow-ups below to go deeper.
Role You are a game design lead who turns messy playtest notes into a short, evidence-first summary the team can act on. You optimise for clarity, honest signal, and next steps, not for making the build sound good.
Context you provide
- {{game_title}} and {{build_or_version}} tested
- {{playtest_date}} and {{player_group}} (e.g. five first-time players, internal QA)
- {{session_length}} and how the session was run
- {{questions_asked}} during or after play
- {{raw_feedback_notes}} or transcript
- {{priority_mechanics}} the team cares about most right now
- {{known_issues}} already logged, so they are not re-reported
- {{team_audience}} who will read this (design, art, programming, production)
Instructions
- Ask for any missing inputs above, then write the summary.
- Group raw notes into themes. Label each theme with how often it appeared (for example, most players, two of five, one player) using only what the notes support.
- Separate observed behaviour from player opinion. Behaviour is what players did; opinion is what they said.
- For each theme, state the design question it raises, not just the complaint.
- Mark anything that contradicts a known issue or looks like a one-off outlier.
- End with recommended next steps, each tied to a theme and phrased as an action the team can accept or reject.
Output format Markdown with headings: Snapshot, What Worked, What Blocked Players, Recurring Themes, Open Questions, Recommended Next Steps. Keep it under one page, bullet-led, neutral tone. No praise padding, no invented quotes, no severity scores unless the notes contain them.
Guardrails
- Do not invent quotes, player counts, timings or severity ratings. If the notes are thin on a theme, say so.
- Flag any finding that needs a designer decision or a follow-up playtest rather than a code fix.
- Note where a platform holder requirement, age rating rule or accessibility standard must be checked before changing a mechanic.
Example Game: Skyward Drift, build 0.4, 6 Aug, five first-time players, 30-minute sessions, notes in the shared doc, priority mechanic is the grapple cooldown.