Is this the first prompt for a new game?

No. It assumes you can describe behavior that already exists. Use a first-prompt workflow when the game loop has not been built; use the repair workspace when expected and observed behavior disagree.

Does this send my prompt or check the game?

No. It formats your inputs into a local text draft. You choose whether to copy it elsewhere, and you must inspect the resulting game yourself.

Why did my result disappear after an edit?

The output belongs to the inputs that produced it. Rebuild after editing so the copied request includes your latest change and preservation boundary.

Plan and test game mechanics

A mechanic needs an observable rule: an action, a change in state and feedback to the player. Before adding more systems, test whether the first action, win condition and restart work together. The existing guides below provide the starting workflow and debugging checks.

Open Mechanics collection ↗

Prepare a game for publishing

Publishing starts with a game that can be tested, understood and maintained. Check the available creator controls, audience settings and safety requirements before a release. Use the publishing guide for the sequence, and the troubleshooting guide for an actual blocked step.

Open Publish collection ↗

BC-1412 · INTERACTIVE TOOL

Editorial review 2026-09-27

Follow-Up Prompt Builder

Turn a working game's current behavior and a single requested change into a focused refinement brief. Name what must stay unchanged and how you will recognize success. The output is a request draft to review and copy, not a generated game or proof that the change will work.

Tool workspace

FOCUSED REFINEMENTLOCAL · NOT SAVED

Change one thing. Protect what works.

Describe a single refinement, then name the behavior that must stay intact. This drafts text only; it does not inspect or change your game.

Behavior

Turns a current behavior, one requested change, preserved systems and an acceptance test into a focused refinement brief with regression checks. Does not inspect or modify a game.

Privacy

This tool runs locally and needs no account.

Working notes

Start with an observation you can compare later. 'The round ends while the player is returning to the gate' describes a behavior; 'make it better' does not define a useful change. Keep separate feature ideas outside this draft so the acceptance test answers a clear question.

Preservation is a test boundary, not a magic instruction. List working systems individually, then check their visible behavior after the requested revision. If a longer round conflicts with a challenge rule you wanted preserved, resolve that conflict deliberately instead of assuming every constraint can remain true.

The acceptance test should name an action and an observable outcome. The builder repeats your preserved systems as regression checks, but it does not discover missing dependencies or judge whether the test is sufficient. Read the controlled-change guide when the requested difference is still too broad, and the preservation guide when 'keep everything else' hides important behavior.

Every field is required. Narrative fields accept up to six hundred characters; the preservation list accepts up to eight nonempty lines with two hundred characters per line. Leading and trailing whitespace is removed, blank list lines are ignored, and line endings are normalized. Oversized entries remain in the draft with an error so you can revise them without silent truncation.

This browser-local workspace sends no draft to a service and saves no draft in storage. Editing any field removes the previous output so an old result cannot look current. Reset clears the fields and result. Copy uses your browser's clipboard permission; when copying is unavailable, select the visible output and copy it manually. A copied prompt is outside this workspace's control.

Examples

Editorial before-and-after example: the current round ends after thirty seconds; the requested change is a forty-five-second round. Preserve the score counter and restart button. Test the end of the round, then check scoring and restart independently. The timer values are chosen game parameters, not a platform limit or recommended benchmark.
Conflict example: a creator asks for a longer collection route while preserving the existing round duration and every travel distance. The brief asks the recipient to explain incompatible constraints rather than silently altering a protected system. Decide which boundary can change before sending another request.

Common questions

Is this the first prompt for a new game?: No. It assumes you can describe behavior that already exists. Use a first-prompt workflow when the game loop has not been built; use the repair workspace when expected and observed behavior disagree.
Does this send my prompt or check the game?: No. It formats your inputs into a local text draft. You choose whether to copy it elsewhere, and you must inspect the resulting game yourself.
Why did my result disappear after an edit?: The output belongs to the inputs that produced it. Rebuild after editing so the copied request includes your latest change and preservation boundary.