Should every follow-up include the whole original prompt?

Usually the affected behavior and its surrounding constraints are more useful. Include the original rule when it resolves ambiguity, but avoid burying the requested difference inside unrelated world, art and progression requirements.

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-0042 · CORE GUIDE

Editorial review 2026-09-26

How Follow-Up Prompts Work in Roblox Build

Write a follow-up around the difference between what you observed and what you intended. Name the affected behavior, request a bounded change, state what must remain intact, and repeat the same check after the response.

Objective

Produce a follow-up instruction with an observable before-and-after result.

Before you start

Write down the action that produced the unexpected behavior.
Decide what the intended result should be.
Identify nearby behaviors that must survive the change.

Steps

Describe the current result without guessing the hidden implementation.
Classify the request as a correction, addition or deliberate rule change.
State the smallest coherent difference you want.
Attach preservation constraints relevant to that difference.
Send the follow-up, then repeat the original scenario.
Record the new result and any regression before choosing the next instruction.

Verification

The message identifies both the triggering action and the observed outcome.
A tester can tell whether the requested difference happened.
The response text is not being used as evidence that the fix worked.
A successful local correction does not conceal a broken adjacent behavior.

Limitations

This is an editorial revision method, not a guarantee that a generated change will follow the brief.
An observation may have several causes; avoid claiming a specific internal cause without evidence.
Complex changes can require a different workflow when the intended behavior cannot be inspected reliably.

Working notes

A useful follow-up carries enough context to identify the fault without restating the entire game concept. Describe the action you took and the visible result. 'Retry is wrong' leaves several possibilities open; 'after using the checkpoint, retry returns to that checkpoint instead of the entrance' identifies a reproducible state transition.

Decide whether the message is a correction, an addition or a design change. Correcting an attempt reset should not quietly add permanent progress or redesign the level. If you actually want the checkpoint to survive a retry, say so as a new rule and update your test expectations instead of calling every different outcome a defect.

Separate instructions from evidence. The generated response may describe a fix, but that description is not the result of your own inspection. Keep the earlier observation until you run the scenario again. Record any new behavior that changed outside the requested scope before sending another message.

Avoid chaining speculative fixes when you cannot reproduce the problem. Save the last prompt and the steps that led to the unexpected result. If the symptom disappears under different conditions, compare those conditions first. A longer conversation is not a substitute for knowing which event triggers the fault.

Examples

Correction brief: 'After I activate the checkpoint and press Retry, the character returns to that checkpoint. Retry should clear the current attempt checkpoint and return to the entrance. Keep the level layout, movement and checkpoint behavior during an active attempt unchanged. I will check retry before and after activating the checkpoint.'
Addition brief: 'The depot already ends the delivery. Add a visible completion message when the existing completion state begins. Do not award progress again while the player remains at the depot, and keep the current restart behavior.' This asks for feedback around an existing event rather than a second completion system.
Follow-up record: previous observation—checkpoint survives Retry; requested difference—clear attempt checkpoint; new observation—fill after trying the same route; unaffected checks—movement and normal checkpoint activation. If the new observation is still unknown, do not mark the correction complete.

Common questions

Should every follow-up include the whole original prompt?: Usually the affected behavior and its surrounding constraints are more useful. Include the original rule when it resolves ambiguity, but avoid burying the requested difference inside unrelated world, art and progression requirements.