Hand off the work without retelling the whole story

The next person or app needs the assignment, the evidence and a clear return.

A handoff begins when someone else has enough to continue. It ends when their contribution fits back into the work.

That second half is easy to overlook. You can send an excellent brief and still receive a result that uses an old draft, changes a settled decision or leaves no clear way to continue.

In our cross-app work, we've chosen a straightforward arrangement: prepare the relevant context, operate the receiving app, then inspect the actual result when it returns. An open conversation doesn't automatically reread a changed file. We work from explicit handoffs rather than assuming every app shares the same current state.

Send the work that is needed now

Let's hand off the source-checking guide from last week. “Improve this” is too broad if most of it is already settled. A focused brief could say:

Review revision 2 of the attached guide for missing prerequisites and unclear exception instructions. Preserve the current audience and the distinction between an unchanged source and an unresolved check. Return a revised copy and a short note identifying substantive changes. Do not distribute the guide.

This is a proposed example, not a new app run. Its useful parts are the exact object, the specific job, the decisions to preserve and the expected return.

The evidence belongs beside the brief. If the review depends on two source passages, supply them. If it depends on a diagram, make sure the receiving app can actually inspect it. Referencing an attachment that isn't there is a handoff failure, even when the prompt is beautifully written.

Day 2's context lesson applies here, with an additional responsibility: someone else needs to know which context is current. “Use the attached revision 2” is more helpful than “use the latest version” when several copies exist.

Check what came back

When the result returns, compare it with the assigned version. What changed? Which changes answer the request? Did a revised sentence broaden a claim or remove an important exception?

Our own comparison of working arrangements included a writer that used a research memo and rejected an unsupported argument in it. Another contribution integrated conflicting memos by checking the source evidence. Those were useful handoffs. The final copies still needed correction, so the existence of a successful return wasn't enough to accept the whole result.

You don't have to demand a long explanation for every comma. Ask for changes that affect meaning, scope or the next action. Those are the ones that can create trouble when they disappear into a clean rewrite.

For a larger technical project, a version identifier or file hash can help establish which material was reviewed. For a small document, a clearly named revision and preserved original may be enough. The purpose is to make the comparison possible.

Close the loop

After reviewing the contribution, update the current note. If you accept the revised exception section, say which version now carries it. If you reject a proposed change, keep the current decision clear. If a question remains open, name the person or action needed to resolve it.

This is the connection between Days 15, 16 and 17: state tells us where the work stands, a resumption note carries it forward, and current decisions tell the next reader which parts of the history should guide action.

A handoff puts those pieces to use across a boundary. Try one on a small part of your project. The useful question afterward is whether the next contributor could do the assigned work and whether you could confidently incorporate the return.