BC-0073 · CORE GUIDE
Editorial review 2026-09-26
How Specific Should a Roblox Build Prompt Be?
Be specific about observable rules and flexible about details that do not affect the test. Define the action, result and boundaries clearly; avoid adding implementation guesses or decorative requirements that obscure the intended interaction.
Objective
Choose prompt detail that resolves behavior rather than adding noise.
Before you start
- Know the interaction you want to inspect.
- Identify unresolved success, failure or retention rules.
- Separate mandatory outcomes from aesthetic preferences.
Steps
- Underline every rule that changes a player's action or result.
- Add missing trigger, feedback and reset boundaries.
- Move optional appearance preferences out of the core rule description.
- Remove unsupported implementation guesses that do not clarify the outcome.
- Resolve contradictory instructions explicitly.
- Check whether a tester could identify success or failure from the resulting brief.
Verification
- The important action and outcome are not left to interpretation.
- Required behavior is distinguishable from optional style.
- Each named state belongs to an explicit reset or retention rule; the brief never asks to clear a value and preserve it under the same retry condition.
- Extra detail has a clear purpose in the intended experience.
- The brief remains testable without assuming a hidden implementation.
Limitations
- Specific wording does not guarantee generation accuracy.
- There is no universal ideal prompt length established by this editorial method.
- A complex system can remain out of scope even when its description is detailed.
Working notes
Useful specificity removes a real ambiguity. 'Collect parcels and deliver them' leaves carrying, valid destinations and completion open. Explaining that the player carries a parcel to a marked depot and receives visible completion feedback makes the interaction easier to inspect. Describing every distant decoration does not resolve those mechanical questions.
Separate required behavior from preferences. Put rules that determine success, failure and retry in the required group. Keep palette, background theme and optional effects in a preference group unless they communicate an essential gameplay distinction. This helps you decide whether the output failed the brief or merely chose a different aesthetic detail.
Avoid prescribing an internal implementation you cannot inspect or justify. Naming a specific hidden algorithm is less useful than describing the observed state transition when the real need is reliable delivery. If implementation detail becomes necessary for correctness, that is a reason to use an appropriate inspection workflow, not to pretend the prompt proves it was followed.
Read the brief for conflicting instructions. 'Reset all progress' and 'keep completed route access after retry' need a stated boundary between attempt and session progress. Resolve the conflict before sending; extra descriptive length will not make incompatible rules more coherent.
Examples
- Too vague: 'Make a satisfying courier game.' Bounded behavior: 'The player picks up a parcel, sees that it is carried and delivers it to the marked depot. Completion gives clear feedback; retry restores the attempt objects and starting position.' Add art preferences only after these rules are understandable.
- Over-specified without purpose: demanding exact decorative placements while leaving the failure rule unknown. Replace that imbalance with a clear statement of what ends the attempt and which state retry clears; retain only visual details that help communicate the route.
- Conflict repair: replace 'reset everything but keep progress' with 'clear the current parcel, attempt score and outcome; retain the session route unlock.' The revised boundary explains what the player should see after retry.