# Give an agent a handoff it can finish

BerryBlox creator resources
Edition 1.0 · November 5, 2026

Turn a broad request into one owned task, a dependency contract, and a result another person can review.

Take away: A bounded assignment and a reviewable completion packet.
Intermediate · 6 min read

Original BerryBlox editorial worksheet. You may copy, adapt, and use it in your own projects and team handoffs. Linked sources and third-party materials retain their own terms.

Download this Markdown file and fill it in with any text editor. Your notes stay in your copy; this worksheet does not upload or save them to BerryBlox.

## Start 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.