handing-off-work

Handing Off Work

Overview

A handoff transfers responsibility, not just context. The next person or agent has to know what changed, what is left, what they are allowed to do, and when to stop.

When to Use

• Another agent, a reviewer, a verifier, a releaser, or a support owner will keep working.
• A long thread is being picked up again after the context changed.
• Work has open evidence, decisions not yet made, or limits on what the owner may do.
• Release work, incident work, or a lesson from real operation (OPEX) has to move to another owner.

When Not to Use

• The work is done and the change record already holds the evidence and the decision.
• A tiny Quick change needs only a diff and a proof note.
• The request is just to summarize a file, with no transfer of responsibility.

Inputs

• The change-record path, the current phase, and the chosen mode.
• The work that is done, the conditions that changed, the assumptions still in play, and the open gaps.
• Allowed files, commands, and tools; actions that are off limits; the evidence still owed; and when to stop.
• The next owner and their role: reviewer, verifier, or releaser.

Process

1. Name the state you are handing off: the last action that finished, the artifacts that are done, and the evidence produced.
2. Name the conditions that changed, anything odd, the attempts that failed, and the assumptions not yet checked.
3. Flag the exact items under control, the targets not to touch, the hold points, and the approval gates.
4. Name the next decision, the next action, the most important action, the likely error, and how to guard against it.
5. Make the incoming owner restate the scope, what they may do, the proof needed, and when to stop, before they act.

Outputs

• A turnover.md file, a turnover section in the context pack, or a release or support handoff note.
• The point to resume from, the conditions that changed, the work that remains, and the next decision gate.
• Confirmation back from the incoming owner when the stakes call for it.

Verification

• A new agent can keep going without reading the full chat history.
• The handoff states what is done, what is left, what changed, and what must not be done.
• The limits on authority and the stop conditions are clear enough to obey.

Escalation

• Stop if the next owner cannot restate the limits on what they may do.
• Escalate if credentials, production data, release authority, public claims, or unresolved evidence gaps are involved.

Common Rationalizations

• "The next agent can figure it out." Handoffs fail when the state is only implied.
• "Everything important is in chat." Chat is not a controlled record.
• "Just continue from here." A resume point with no stated authority and no evidence is not a handoff.

Red Flags

• No record of the last action that finished.
• No section for the conditions that changed.
• New build work is mixed into the handoff.
• The incoming owner is told to act before confirming the scope and the stop conditions.

Source-lineage note

This skill is an original software-workflow translation of turnover, effective communication, place-keeping, flagging, task briefing, and review practices from DOE-HDBK-1028-2009 as public source lineage. It does not create DOE compliance, formal assurance, safety, security, certification, or regulatory adequacy.