Write the test before the game edit
An exit that opens after three tokens sounds like a simple change. But does the third token finish the level, or does it merely unlock the way out? Can the player collect the same token twice? What happens if they restart just before reaching the exit?
Those are different rules hiding inside one request. Leaving them for the editing agent to decide makes the result harder to judge: a working implementation can still be the wrong game.
Consider a hypothetical one-room game whose exit currently opens immediately. We want three distinct tokens to unlock it, followed by a separate action—reaching the exit—to finish. The example below is a proposed edit, not a game built or tested for this article.
AI-generated illustration of the hypothetical rule: collect three tokens to open the gate; Reset restores the starting state. Not a screenshot or Rosebud result.
A request with a clear finish line
Rosebud's beginner workflow describes trying the preview, requesting a focused change in chat and playing again. Before that editing step, decide what you will do in the preview to check the change. For this gate, the request could be:
Start each run with three distinct tokens and “Tokens: 0/3”. Collecting a token removes it and increases the counter once.
Keep the exit locked at 0, 1 and 2. Touching it displays “Collect all 3 tokens to exit.” At 3, show “Exit ready”. Finish only when the player touches the exit, not when they collect the last token.
Keep the artwork, movement controls and speed, camera, audio and existing Restart control. Do not add enemies, timers, levels or online features.
Restart restores the original player position and all three tokens, returns the counter to 0/3, locks the exit and clears any exit or completion message.
Explain the planned changes before editing. Afterward, list the checks actually run and mark the rest “not run”.
Notice that this asks for three states: locked, ready and finished. “Collect three tokens to win” would collapse the last two and remove the walk to the exit. If that walk matters to your design, it needs to survive the prompt.
The preservation paragraph serves a different purpose. Keeping the room and controls lets you compare the edit with the game you already know. If the agent also redesigns the level, an unexpected result becomes harder to trace.
Play through the states separately
Save the original build and note the browser and controls used. On the edited build, first touch the exit with no tokens, then with one and two. It should stay locked and explain what is missing.
Collect the third token, but stop short of the exit. This is the easy-to-miss check: the counter should read 3/3 and the gate should be ready, while the level keeps running. Only reaching the exit should finish it.
Next, start a fresh run and collect one token. Cross that token’s former position again; the count should remain at 1/3. That catches a different failure from unlocking too early: an object may disappear visually while its trigger remains active.
Try Restart at 2/3 and after completion. Check the objects as well as the counter. A display of 0/3 is misleading if one token is still missing or the exit remains open. Then compare the same short movement path with the original to check that controls, speed, camera, artwork and audio stayed as requested.
If a check fails, report the action and result before proposing a cause. A hypothetical report would be: “Build B, keyboard controls: crossed token A's former position after collecting it. Expected 1/3; observed 2/3. The token stayed invisible.” That is enough to target a repair without assuming which function caused it.
After the repair, repeat that check and the unlock and restart checks it might affect. Keep an unperformed check marked “not run”, even if the agent's explanation sounds convincing.
These observations settle whether the edit follows your rule. Whether someone understands the objective or enjoys the final walk to the exit still needs a playtest. The prompt gives that playtest a consistent game to start from.