agent-playtesting is a skill from the Summer skill library: a guide your AI agent reads when the task matches, so it builds the good version on the first try. Playtest by driving the live game: deterministic launch, frame-stamped probes, scripted or recorded input.
When your agent uses it
- Proving a gameplay feature works by driving the running game frame by frame with the runtime tools (summer_game_probe, summer_game_input, summer_game_control, summer_runtime_set/call/spawn/animate)
- A bug repro or an A/B needs a deterministic launch (seed, fixed frame rate, offscreen instance), a recorded input replay, or two instances side by side
- Deciding what counts as evidence for “it moved / it fired / the node appeared” — the probe-before, probe-after, frame-stamped discipline
- Asserting exact positions or timings by advancing the live game a physics frame at a time
Install
summer setup installs every skill for your agent. To add only this one:
claude-code for your agent, such as codex or cursor. See Skills for every option.
The skill
Overview
playtesting-a-feature says a feature is not done until someone has played it. This skill is how you play it — not a hidden probe that dies when it finishes, but the live game, driven one action at a time, with a frame-stamped record of what each action did.
The engine’s runtime-control ops make the running game a thing you can see and touch:
Every one of these needs a RUNNING game and answers
game_not_running otherwise. On an engine build that predates them the result is engine_lacks_op naming the fallback — usually the RunVerification probe from playtesting-a-feature. Record that as the expected outcome, not a failure.
<EXTREMELY-IMPORTANT>
An action is not evidence. summer_runtime_set returning applied: true, summer_game_input returning completed: true, summer_runtime_call returning a value — each proves the request was honoured, not that the game did what the feature promises. Only a probe of the frame AFTER, compared with a probe of the frame BEFORE, proves motion, spawning, damage, or a state change. Never claim any of those without the two frame numbers.
</EXTREMELY-IMPORTANT>
The Loop
1. Launch deterministically
Decide before pressing play what the run must pin.- Embedded main game (
summer_playwith no instance): the game the user sees. Addseedandfixed_fpsto pin the RNG and the frame clock —seedonly applies to a game that is not already running (determinism.applied: falsewithreason: already_runningmeanssummer_stopfirst). - Offscreen instance (
summer_play {instance:"a", mode:"offscreen"}): a hidden child process the user never sees, addressed by name on every runtime tool. Up to three at once.deterministic: truelaunches it with--fixed-fps 60 --summer-seed <seed> --audio-driver Dummy; this is the only kind of instance on whichsummer_game_input action:"replay"accepts aseed. - Two variants side by side:
instance:"before"andinstance:"after"(different scenes or differentsummer_runtime_setsetups), the same recorded input replayed into each, probes compared frame for frame.
determinism.seed_scope tells you what the seed does NOT pin: RandomNumberGenerator instances (self-randomized on construction), scripts that call randomize(), wall-clock reads, thread timing. A feature that uses any of those is not deterministic under a seed; assert ranges there, or fix the script to use the global RNG.
2. Wait for boot — never sleep a guessed delay
Boot time varies. Confirm, do not assume:- Main game:
summer_is_runninguntil it reports running. - Offscreen instance:
summer_game_control action:"instances"until the instance showsattached: true. Before that, every runtime op answersrequest_failed(“session has not attached yet”).session_timeoutmeans the child never attached and was killed — readsummer_get_consolefor its stderr.
3. Probe BEFORE
frame.process_frames and frame.physics_frames. Every path you will act on comes from this tree — runtime paths are absolute (/root/Main/Player) and differ from the edited scene when nodes spawn, rename, or reparent at runtime. Look at the screenshot and say what is in it.
4. Act
One action per step, so the AFTER probe attributes cleanly:summer_runtime_set path:"/root/Main/Player" property:"position" value:"Vector3(0, 2, 0)"— readapplied.applied: false(not_applied) means a script rewrote the value the same frame, or the literal type was wrong; do not proceed as if it landed.summer_runtime_call path:"/root/Main/Boss" method:"take_damage" args:[25]—returnis what the method answered; the effect still needs the probe.summer_game_input action:"script" events:[{at_frame:0, type:"action", action:"move_right", hold_ms:500}, {at_frame:30, type:"action", action:"jump", hold_ms:50}]—rejected[]names events the game refused (unknown_action= not in the InputMap; bind it withsummer_input_map_bindand restart, or drivetype:"key"). One script in flight per instance:busymeans wait for the first.summer_runtime_spawn action:"spawn" parent:"/root/Main/Enemies" scene:"res://enemies/goblin.tscn" props:{position:"Vector3(4, 0, -2)"}— use the returnednode.pathfrom here on.
5. Step — for exact assertions
When “after 3 physics frames the velocity is zero” is the claim, do not let wall-clock time decide how many frames ran:before, after, exact, and overshoot; cite them. The game stays suspended after a step — summer_game_control action:"resume" when you want it to run again. Time-based behaviour (a 500 ms hold, a 2 s cooldown) runs on the game’s clock: with fixed_fps a step of N frames IS N/fps seconds; without it, use at_ms and read clock_mapping (“approximate” means the mapping went through the physics tick rate).
A minimized game window draws no frames and cannot step (timeout). game_breaked means the game sits at a script breakpoint; continue it in the debugger first.
6. Probe AFTER, then assert
Same probe as step 3. Compare the two:- positions, velocities, HUD values — as inequalities (
x > before.x + 50), never exact equality unless the run is deterministic AND frame-stepped; tree— the spawned node exists under its parent; the freed one is gone (aqueue_freetakes effect at the end of the frame, so step once before asserting absence);- the screenshots — look at both and describe the difference in words. A tree that says “goblin spawned” and a frame that shows no goblin is a bug, not a pass.
summer_get_debugger_errors — a feature that “worked” while logging null-reference errors did not work.
7. Stop
summer_stop (main) or summer_stop instance:"a" for each offscreen instance you started. Offscreen children also die when the editor exits, but do not leave them for the user to discover.
Input scripts vs. recordings
Recording caps at 20,000 events / about 1 MiB (
truncated: true when hit). Files land in res://.summer/replays/<id>.json; pass that exact path to replay. A waited script or replay is capped at 20 s by the engine — for longer sequences pass wait:false and follow along with probes.
What seed does not pin
Readdeterminism.seed_scope on the play result and believe it. Pinned: the global RNG (randi, randf, randi_range, randf_range, randfn, Array.shuffle, Array.pick_random), re-seeded after SceneTree init and before autoloads and the main scene. Not pinned: RandomNumberGenerator instances, scripts calling randomize(), wall-clock reads (Time.get_ticks_msec used as a source of variation), thread timing, and anything read from the network or the file system. When a replay diverges on a deterministic instance, one of these is the reason — find it in the script before doubting the tooling.
Honesty rules
- Cite frames. “At frame 1834 the player was at x=12.0; after
move_rightfor 30 frames, at frame 1864 x=57.3” is a verification. “The player moved” is not. applied: falseis a no. Do not narrate a value change the read-back denied.completed: falseis a no. The script did not finish inside the wait; probe to see how far it got, do not call it done.rejected[]is part of the result. Report the rejected events and why, even when the rest applied.engine_lacks_opis the expected outcome on an engine without these ops. Say so, fall back to theplaytesting-a-featureprobe loop, and do not describe a runtime playtest you could not run.- A screenshot you did not look at is not a screenshot. Describe what is in it.
- Parallel instances are not the user’s game. Findings from
instance:"a"describe that instance’s launch (scene, seed, fixed_fps); say which instance a claim came from. - Do not hand the walkthrough to the user while any of these tools works. Ask a human only for what a probe cannot judge — feel, beauty, fun (
debugging-game-feel).
Red flags — STOP
Related skills
playtesting-a-feature— the iron law (no shipped claim without a played walkthrough) and theRunVerificationprobe loop this skill replaces when the runtime tools exist.verifying-scenes— evidence discipline for the EDITED scene (snapshot, diff, screenshot).verification-before-completion— the code layer that must be green before any of this.debugging-game-feel— when the feature works but feels wrong.investigating-bugs— root-causing a reproducible bug once a recording reproduces it.
From a shell
No Summer MCP tools in this session? Run each one as a command; whensummer --version is missing or below 4.0, use npx -y summer-engine@latest in place of summer. Fields are flags in kebab-case (--scene-path res://main.tscn) or one --input '<json>', and summer ops describe <op> prints the exact input. The summer-cli skill has the rest.
Related skills
playtesting-a-feature: Before calling a gameplay feature done, run the game and walk through it. Static checks do not count.verifying-scenes: Prove scene work landed: snapshot, diff, screenshots, runtime reads, 3D audits, shot sheets and zooms.verification-before-completion: Run verification and read its output before claiming work done, fixed or passing: evidence first.debugging-game-feel: Debug features that work but feel wrong: floaty jumps, mushy combat, sluggish camera.investigating-bugs: Systematic investigation of any bug, test failure, or unexpected behavior before proposing fixes.
Source:
library/skills/agent-playtesting/SKILL.md, rendered from summer-engine@4.3.0 on npm.
