Build Bug-Fix Prompt Builder

Working notes

Describe the starting state and actions in order, using a separate line for each step. Include the condition needed to see the failure, such as a fresh round or carrying an item. If you cannot reproduce a problem safely, record that limitation instead of performing a destructive action merely to complete this form.

Expected and observed results must differ. Write what the player should see beside what appeared, retaining meaningful capitalization and symbols when the mismatch is a label. An observation such as 'the score increased twice' does not establish why it happened. The generated request explicitly avoids treating a guessed cause as evidence.

Keep the repair bounded by listing behavior that already works. A scoring correction should not become an unrelated movement rewrite. For a scoring problem, the scoring guide helps distinguish the intended event from its displayed feedback; the follow-up guide helps describe the correction without claiming an internal diagnosis. Use the refinement workspace instead if you simply want a different rule.

Retest the action that originally failed, including its necessary starting state, then inspect each protected behavior. A passing attempt is an observation about that attempt, not proof that every case is fixed. The prompt requests missing observations when the supplied steps are insufficient; the builder itself cannot detect whether those steps reproduce the game.

All comparison and retest fields are required and allow six hundred characters each. Reproduction and preservation lists allow eight nonempty lines, with two hundred characters per line. Blank lines are omitted and outer whitespace is trimmed. Validation keeps your entered draft intact when a field is missing, too long or identical to its comparison.

No account, project or private game is read by this workspace. Generation stays in this browser and does not use storage or a remote service. An edit invalidates the previous prompt, and Reset removes the local draft. If clipboard access fails, the output remains selectable for manual copying; this is not a successful-copy notification.

Examples

• Observed scoring example: start a fresh round and collect a star. The intended score increment is one, but the visible score rises by two. Preserve movement controls and retest after restarting. Report the duplicate increment without asserting an event-handler or networking cause that the observation does not establish.
• Label repair example: the expected button text is EXIT, while the visible text is Exit. Those are different observations even though a case-insensitive comparison would hide the discrepancy. A label correction should preserve the button's existing action, which needs its own regression check.
• Insufficient reproduction: 'sometimes it breaks' does not state an action, starting state or result. Collect a safe concrete observation first. A polished generated request cannot turn an unspecified failure into a confirmed defect.

Common questions

Does the builder identify the cause of a bug?

No. It keeps the expected-versus-observed mismatch separate from any unverified diagnosis and asks for missing observations when reproduction is incomplete.

Why are identical results rejected?

A repair request needs a stated mismatch. If the behavior is working but you want a new rule, use the refinement builder. Case and symbol differences remain meaningful here.

Can I treat the output as a completed test?

No. It is a repair brief and proposed retest. Run the relevant safe checks yourself and record the actual result, including failures and cases you could not inspect.