Prompts and task breakdown

A useful prompt states the goal, scope, constraints, and acceptance criteria. Change one observable result at a time instead of combining refactoring, asset replacement, and publishing.

Recommended template

State the goal and scope, then verify each small task by running the game

Goal: <the single observable result to change>
Context: <files, scene nodes, Inspector references, or errors>
Scope: <files you may read and edit>
Constraints: <versions, dependencies, or behavior to preserve>
Acceptance: <observable results after running the game>
Process: analyze first, present a plan, and wait for confirmation before editing.

For example, split changes to Pink Demo into these tasks:

1. Explain scene component references and the click-to-score flow without editing files.
2. Move only the initial target position to the center: update TARGET_POSITIONS[0] and the initial Canvas/Target coordinates in the scene. Preserve the other four positions and animation sequence. Verify startup and reset positions.
3. Change only the text of Canvas/ResetButton/Label, preserving scripts, node names, references, and behavior.
4. Check the scene, scripts, asset references, and build output.

Edit static text and layout in the scene; edit scoring, movement routes, and reset rules in the script. resetGame() moves the target to TARGET_POSITIONS[0], so a scene-only coordinate change will be overwritten at runtime. Include the file that actually controls the result.

Task breakdown principles

• Give each task one main outcome.
• Make every step independently runnable or checkable.
• Approve high-impact operations separately from routine code changes.
• Fix the first error before investigating errors caused by it.
• Verify build success and correct gameplay as separate checks.