BC-0072 · CORE GUIDE
Editorial review 2026-09-26
How to Reuse a Roblox Build Prompt
Reuse the structure of a prompt only after comparing its assumptions with the new project. Preserve the interaction logic that still applies, replace context-specific rules deliberately, and inspect the new result instead of expecting an identical recreation.
Objective
Adapt a prompt's useful reasoning without importing incompatible assumptions.
Before you start
- Have the original prompt and its actual observation notes.
- Describe the new project's interaction and state boundaries.
- Identify whether the instruction creates a new loop or changes an existing one.
Steps
- Extract the original action, feedback, ending and reset rules.
- Compare each rule with the new project's requirements.
- Replace incompatible assumptions rather than only themed nouns.
- Save the adapted text with a short explanation of changes.
- Inspect the new result against its own acceptance checks.
- Keep the new outcome record separate from the source prompt's history.
Verification
- Every imported rule has a reason to apply in the new context.
- Intentional retained state is not accidentally cleared by an old repair.
- Changed mechanics receive new checks, not an inherited success label.
- The new result is inspected even when its appearance resembles the original.
- The record does not promise identical generation or recovery.
Limitations
- Reuse does not guarantee the same generated output.
- A prompt from another creator may contain assumptions or rights issues that need separate review.
- Substantial mechanical differences can make a fresh brief more useful than extensive adaptation.
Working notes
Start by identifying what made the original instruction useful. It may define a clear action, an observable completion state or a careful reset boundary. Those relationships can transfer more safely than surface nouns. Replacing 'parcel' with 'crystal' does not address a new design in which objects can be carried together or delivered to different destinations.
Compare starting states before sending a follow-up from another project. A repair that clears checkpoint state assumes such state exists and should be cleared. In a project with intentional session checkpoints, the same instruction may remove desired progress. Record mismatched assumptions before deciding whether to adapt the prompt or start a new brief.
Keep the adapted wording and the original separate. Mark what changed and why, especially completion, failure and retention rules. That distinction lets you interpret the resulting behavior without attributing it to the old prompt's previous success.
Retest the contract, not the appearance. Similar scenery does not establish that collection, completion and retry behave the same way. Compare the intended inputs and outcomes in the new project, then record any difference as its own observation. Reuse carries design reasoning into a new brief; it is not a procedure for reconstructing a saved game state.
Examples
- Transferable structure: action—pick up an item; feedback—show carrying state; completion—deliver to the marked destination; reset—restore attempt objects. Before adapting it to a sorting game, define which destination accepts which item and what an incorrect delivery does.
- Assumption mismatch: an old retry prompt clears all collected progress. The new design intentionally retains completed route choices during the session. Replace that reset rule explicitly instead of swapping themed object names and leaving the destructive instruction intact.
- Adaptation record: source purpose—delivery prototype; new purpose—sorting interaction; changed rule—destination depends on item category; preserved principle—clear carrying feedback; required check—wrong destination must not silently count as success.