A useful AI task handoff for teams should work when one developer uses a terminal agent and another uses an editor assistant. The transferable part is the task contract: inputs, allowed changes, required evidence, and a reviewer. The conversation history is optional context.
Here is a practical template for a small repository change: reject a malformed configuration value with a clear error before the application starts.
1. Define the boundary before assigning a runner
The component owner prepares the request. For this example, configuration accepts a positive integer for a local worker count. A blank value should retain the existing default. A non-integer string should fail with a useful message. The author must confirm those requirements against the actual application before anyone edits it.
outcome: reject invalid worker-count configuration before startup
scope:
allowed: config parser and focused parser tests
excluded: deployment, credentials, queue architecture
inputs:
revision: record the real base commit
config_key: replace with the actual key
reproduction: supply a synthetic invalid value
acceptance:
- omitted value preserves the current default
- valid positive integer preserves behavior
- zero, negative, and non-integer values are rejected
- error names the key without printing secret configuration
stop_when:
- the parser contract conflicts with documented behavior
- the change requires a production configuration update
- unrelated failures prevent a trustworthy comparison
~~~
These are proposed acceptance cases. They are not assertions that a particular repository already behaves this way.
## 2. Apply an eligibility gate, then compare fit
Access is a gate. The runner must already be authorized to read the repository and use the required environment. A teammate with a powerful model but no repository permission is not eligible merely because someone else can paste them a token.
After access, compare expertise and available tools. For this parser task, choose someone who can distinguish a parsing regression from an unrelated build failure. Their agent must be able to inspect the code and run the project's documented tests. Browser-only chat can help explain a proposed change, but cannot itself demonstrate that local tests ran.
Suppose Ren has authorized repository access and the relevant configuration knowledge, but only a text chat. Ada has the same access, a terminal agent, and familiarity with the parser tests. Ada can run this task, while Ren can clarify the expected error message. If Ada cannot explain a failed boundary case, the task needs the component owner again; repeated prompting is not a substitute for understanding the requirement.
## 3. Give the runner a small evidence protocol
The runner records the base revision and checks for existing work before changes. They run the documented reproduction, capture the actual error, and ask the agent to identify the responsible code. The first proposed diff should stay within the stated boundary.
~~~text
Before: command, exit code, observed output, base revision
Change: files and reason each file is necessary
After: same reproduction, focused tests, actual exit codes
Uncertainty: checks not run and why
Review: commit reference and named acceptance owner
~~~
Keep machine-generated explanations separate from observations. “The model says validation is fixed” is a hypothesis. A command and its output are evidence that a check ran. The reviewer still needs to assess whether that check covers the intended failure.
## 4. Hand back a result, including an honest non-result
The author prepares the technical brief. The runner executes with their own authorized tools and supervises the checks. A qualified reviewer inspects the diff and decides whether the acceptance cases are met. Deployment remains a separate decision when the task excludes it.
If the runner discovers that a worker count of zero deliberately means automatic sizing, they should stop and return that fact. The template was wrong for this repository. The correct action is to revise the requirement, not to change working behavior to satisfy an invented test.
The [Wagglet explanation of task handoffs](https://wagglet.com/blog/close-team-skill-gaps-with-ai-task-handoffs) provides the broader preparation-and-review model. This template applies it to a specific configuration change without requiring teammates to share accounts or standardize on one assistant.
Before accepting the work, verify the recorded revision, reproduce the named cases, inspect the error for accidental configuration disclosure, and check that no deployment or unrelated cleanup slipped into the diff. The template helps structure evidence; it cannot guarantee a correct implementation or replace domain review.
Top comments (0)