Playtest Report
Playtest like it matters: a structured pass over the mechanics, the edge inputs, and the score loop, every finding written with its repro steps — a ranked fix list, not vibes. Locks the test plan FIRST — what to try and what correct looks like — then plays through it taking notes, then writes the findings with a ranked issue table. Use for playtesting a game before sharing it, 'is the game actually solid', bug hunts on an arcade page, pre-release game QA, and turning playtest feelings into a fix list.
Steps
Entry step: scope. Each step names the specialist role it wants; the full working prompt is expandable.
- Write the test planreviewerentry
mechanics list, edge inputs, what the score loop should do
Show working prompt
Plan the playtest before playing a frame. Step 1: read index.html from the workspace and list the mechanics — movement, actions, collisions, scoring, lives or health, game over, restart — and how the score is kept between rounds. Step 2: write the edge-input list — keys mashed and held, action during game over, restarting mid-motion, playing again three times in a row, anything a ten-year-old with a keyboard would do in the first minute. Step 3: state what correct looks like per item — especially the score loop: what the score should read after a restart, and what should carry over versus reset. Step 4: write an acceptance-criteria checklist ('every mechanic exercised', 'every edge input tried', 'every finding has repro steps', 'findings ranked by player impact', 'the score loop gets an explicit verdict'). Call write_task_note with the plan size + checklist and write notes/scope.md. - Play through the planreviewer
structured playthrough notes, observed versus expected, with repros
Show working prompt
Work the plan against the code and write down what actually happens. Step 1: walk each mechanic and each edge input through the game's logic, tracing the code path the input takes; record observed versus expected for every item — passes too, not just failures. Step 2: for every mismatch, write the repro then and there: the exact steps, what happens, what should happen; a finding without a repro is a rumor. Step 3: give the score loop special care — trace a full round, game over, and restart, and record exactly what the score does at each point. Step 4: write the structured notes to notes/playtest.md and call write_task_note with the pass/fail counts.
- Write the findingscopywriter
ranked issue table, repros attached, honest verdict
Show working prompt
Write the playtest report at report.md. Step 1: open with the honest one-paragraph verdict — what state the game is in and whether it is ready to share. Step 2: the issue table — a Markdown table with columns Issue, Severity, and Repro, one row per finding, ranked by player impact (what ruins a session outranks what merely looks off). Step 3: under the table, give each finding its detail — the full repro steps, what happens, what should happen, and where in the code the trail leads. Step 4: state the score-loop verdict explicitly, and close with what passed cleanly so the good news is on record too. Write report.md and call write_task_note with the finding count and the top-ranked issue.
- Evaluatereviewer
Grade the deliverable against every acceptance criterion. All pass → finish; any fail → loop back and fix the gap.
Show working prompt
Open report.md and notes/playtest.md against notes/scope.md and verify every criterion: every mechanic and edge input from the plan appears in the notes with observed versus expected; every finding in the report carries repro steps a stranger could follow — re-trace one against the code to check it is real, a finding that does not reproduce is worse than none; the table ranks by player impact with severities that match the prose; and the score loop has its explicit verdict. Write PASS/FAIL per criterion; on any failure, name the finding or the gap and loop back to report. Then route — this is the whole point of the loop: - **Every criterion PASSES →** call `advance_task_step({ ref, stepId: "evaluate", next: "finish" })`. - **Any criterion FAILS →** write the specific gaps to notes, then call `advance_task_step({ ref, stepId: "evaluate", next: "report" })` to loop back. The builder fixes exactly those gaps. Never route to `finish` while any criterion is unmet. The build phase's completion gate already blocked a grossly-incomplete deliverable; your job is the judgment an automated check cannot make (does it actually work, read well, look right). After ~3 unproductive loops, stop and report DONE_WITH_CONCERNS so the user can step in. - Finishdeveloper
All acceptance criteria met. Stamp a short summary and report DONE.
Show working prompt
Every acceptance criterion passed. Write a one-paragraph DONE summary to task notes via `write_task_note`: what was built, the deliverable path(s), and a one-line confirmation that each criterion is met. Then report DONE.
Triggers
Phrases that suggest this craftbook to a crew.
- playtest the game
- is the game solid
- test the arcade game before i share it
- find the bugs in the game
- playtest report
Source
View this craftbook on GitHub · MIT license