A Practical Handoff Template for Game Agent Tasks

/01

State the outcome and the boundary

Begin with the observed problem and the intended behavior. For the puzzle, a player starts dragging a tile, switches tabs, releases the pointer elsewhere, and returns to find the tile still moving. The desired outcome is a canceled drag with the board unchanged. Name the input module and related scene as the starting ownership boundary, and identify any other active work that must be preserved.

Define what the task does not authorize when that boundary could otherwise be misunderstood. A focused drag fix does not imply changing the puzzle rules, replacing the renderer, or publishing a new build. List the actual decision owner for any expansion. This keeps implementation choices reviewable and makes it possible for independent work to proceed without two contributors rewriting the same subsystem.

/02

Attach context that can be reproduced

Record the repository, branch or revision, build command, affected scene, and shortest reproduction sequence. Git's revision documentation explains how HEAD identifies the commit underlying the working tree; capture the exact revision and separately describe relevant uncommitted changes. A commit identifier alone cannot represent those changes. Include the expected runtime and device or browser details when they affect the symptom.

Link the smallest useful evidence: an input trace, a short recording, a failing test, or a screenshot of the wrong state. Explain what the evidence demonstrates and where it stops. If the failure appears only in a hosted frame, include an authorized test route or local equivalent. Keep credentials, private player data, and unrelated project material out of the handoff.

/03

Use a task brief that names checkable facts

Write the brief in compact fields so the recipient can distinguish requirements from suggestions. The following example describes work to perform; it does not claim that any implementation or test has already passed. Replace the project-specific module names with paths verified in your own repository, and keep the reproduction concrete enough to execute without asking the original reporter what they meant.

Add known constraints and one useful starting hypothesis. For the puzzle, the hypothesis might be that transient input survives the visibility transition. Label it as a hypothesis, not the cause. Invite the recipient to disprove it through a trace. This prevents a handoff from turning an early guess into an instruction to patch the wrong subsystem.

• Outcome: cancel an interrupted tile drag without moving a board piece or changing the score.
• Reproduction: start dragging, leave the tab, release outside the game, return, and move the pointer.
• Evidence to return: the identified state owner, the minimal patch, and before-and-after results for that sequence.
• Acceptance: ordinary dragging still works, interruption cancels once, and repeated tab switches create no stuck action.

/04

Return evidence and the remaining decision

Ask for a completion note that names what changed, why it addresses the failure, and exactly how it was verified. A command that exited successfully is different from a device interaction that was observed. Record both where relevant. If the recipient could only run desktop checks, keep mobile verification open instead of allowing a broad statement that input is fixed everywhere.

Review the resulting patch against the ownership boundary and replay the original sequence. Then check one neighboring behavior, such as a successful drop or an explicit cancel. The handoff is complete when another person can locate the change, reproduce the verification, and identify any remaining work. Preserve useful discoveries in project documentation so future tasks need a smaller brief rather than a longer conversation dump.