Give an agent a handoff it can finish
Turn a broad request into one owned task, a dependency contract, and a result another person can review.
A bounded assignment and a reviewable completion packet.
Completed example
Original fictional example. These are filled-in worksheet answers, not evidence of a built or tested game.
Implement one basket delivery interaction
- Assignment
- Systems owner: implement the basket's complete and incomplete delivery responses for the approved orchard loop.
- Inputs
- Use the approved brief, the existing player fruit count, and the reviewed basket object. If any input is missing, report it before inventing a replacement.
- Boundaries
- Own only the basket interaction and its focused checks. Do not change fruit rewards, the map layout, account systems, or publishing settings.
- Acceptance
- Two fruit produces a clear refusal without changing progress. Three fruit completes once and opens the gate. Repeating the action does not complete again.
- Return packet
- Return changed paths, the exact revision checked, observed normal and refused cases, and unresolved device or multiplayer checks. Do not label source-only work as tested.
Expected resultAn assignment that another person can execute and review without guessing its dependencies, ownership, or definition of done.
Try it in your blank worksheetStart with one observable result
Describe the change a player or reviewer should be able to observe. 'Improve the shop' leaves the recipient guessing; 'show a readable refusal when a player cannot afford the upgrade' gives them a behavior to implement and a case to check.
Name the exact files or module the recipient owns. Other people may be working nearby. State which shared contracts must remain compatible and which paths are references only. A new task does not silently authorize editing another person's work.
- Result / player-visible reason
- Owned files or module
- Read-only references / preserved behavior
- Inputs received / expected outputs
Make dependencies explicit
List the data shape, event, asset, or accepted decision needed before work can begin. Include a small example of the input and output. If a dependency is unavailable, ask for a documented boundary or work on an independent slice; do not invent an accepted upstream result.
Assign shared code one owner. Multiple people can review the same contract, but parallel editing of the same file makes responsibility and integration harder to track.
- Each dependency has an owner and a status.
- Inputs include units and valid states.
- Failure behavior is specified.
- Shared interfaces have one editing owner.
- Dependency / owner / available artifact
- Input example / output example
- Blocked condition / useful independent work
Write the check before the handoff
Choose the smallest meaningful test that could reject an incorrect result. Include a normal case, the changed boundary, and one refused or recovery case. State which environment is necessary: a source check cannot prove a player can tap the control.
Require concrete evidence rather than a confidence score. Ask for the exact command and result, build identity, and a screenshot or recording when appearance or normal input matters.
Illustrative assignment: implement the insufficient-coins state in the owned shop component. Given 40 coins and a 60-coin upgrade, normal input shows the cost and refusal, spends nothing, and allows the player to close the panel. Recheck the affordable case after the change. This example is not a runtime test.
- Normal input / expected result
- Boundary or refusal / expected result
- Required environment / evidence to retain
- What remains explicitly untested
Return a result someone can continue
A useful completion packet says what changed, which files changed, how it was checked, what failed, and what remains. Keep implemented, locally checked, Studio tested, device tested, and owner accepted as distinct statuses.
If the result misses a requirement, request a bounded repair tied to that requirement. Preserve useful work and evidence. Repeating the whole task without diagnosing the gap wastes the next session.
- Changed files and outputs are listed.
- Fresh check commands and actual results are included.
- Known limitations have a next owner.
- Independent review is recorded separately from author claims.
- Result status / evidence location
- Remaining gap / next owner / concrete next action
Evidence and limits
This is an original task-writing template, not an agent engine, automation service, or proof that a build has been completed. It works for human and agent handoffs; it supplies no account access, model credits, or product entitlement.
You may copy, adapt, and use this BerryBlox worksheet in your own projects and team handoffs. Keep confidential code, credentials, and private player information out of shared task packets.