Hand off a Claude workflow with a five-part packet

Write the five parts before you share anything

Most working Claude processes live in one person’s head and one long chat. The chat holds the instructions, the corrections and the good examples in an order only the builder remembers. Sharing the chat hands over a transcript and keeps the method with the builder.

The packet below is our recommendation; Anthropic publishes no template for it. Keep it as one document next to the Project or Skill it describes, short enough to read before a run and specific enough that a colleague can point at a line and say it is wrong.

• Instructions: the exact text the workflow runs on, copied from the Project instructions or the Skill file, with the date it last changed.
• Worked example: one real or clearly labelled practice input, the output you accepted, and one output you rejected with the reason.
• Access rule: who may run the workflow, which sources it may read, and who approves the output before sales or a customer sees it.
• Recheck date: when the next unassisted run happens, and which inputs get refreshed first.
• Owner: the one person whose calendar holds that date and whom a successor asks when a result looks wrong.

Sort the chat into instructions, files and the brief

Open the chat that produced your last few good runs and sort what you typed into three groups. Text you pasted every time belongs in the Project instructions. Evidence you referred to, such as a competitor file or approved messaging, belongs in the Project’s knowledge files. Whatever changed from run to run is the per-task brief, and it stays out of the Project. The Project setup lesson covers how instructions and files behave; the job brief lesson covers the per-task part.

Then delete what no longer applies. A correction written once to fix one bad answer often survives as a permanent rule. Read each line and ask whether the next run needs it; a shorter instruction set is easier for a successor to trust.

Anthropic's Project documentation does not describe version history for instructions. Copy the final instruction text into the handoff packet with its date.

Write who runs it and who approves it

Anthropic’s Projects article, checked September 14, 2026, says that on Team and Enterprise plans a Project can be shared with other members of the organization. Outside such an organization there is no mechanism inside Claude to hand a Project to a teammate. Export the instructions and files, and the new owner rebuilds the Project under their own account.

The sharing setting says who can see the Project. The access rule says who is allowed to start a run and who signs off on the output before anyone acts on it. Write both as names, each with a backup, in one sentence.

If the workflow reads a connected source, the rule covers the connector as well. Anthropic’s connector documentation describes organization-level connector controls. A sentence in the instructions asking Claude to work read-only is a request; the effective connector setting is a control. A member added to a shared Team or Enterprise Project can view its current instructions. Connector access still follows that member's source-system permissions and the organization's connector settings. The MCP for marketers lesson shows what those permissions look like per tool.

Test the handoff with one unassisted run

A workflow that still needs its builder to interpret the output has not been handed off. Run this test before you rely on the packet, and again on every recheck date.

1. Choose an input the successor can reach

   Use a real task or a practice input labelled as such. Confirm that the successor can open every source the instructions name under their own account. A source the builder could reach and the successor cannot is the most common silent failure.

2. Have the successor run it from the packet alone

   They read the packet, open the Project, run the task and note every point where they had to guess. Confirm that they did not message the builder during the run.

3. Compare the result with the worked example

   List each difference. Each one should be either an acceptable variation or a specific line in the packet that needs to change. A difference nobody can classify is a judgment call that lives only in the builder’s head, and it goes into the packet as a rule.

4. Fix the packet, then rerun

   Change the instructions, the example or the access rule. Confirm that the second run passes without the guesses from the first.

Here is an invented case of drift, written for this lesson. A battlecard refresh workflow tells Claude to use the competitor file, and nobody refreshed that file after the competitor changed its pricing page. The successor’s run produces a confident card with last quarter’s price. The comparison catches it because the worked example records the date its sources were checked, and the file is older than that date. Without the date, the stale card reads as correct.

Name an owner and set a recheck date

Name one person. Their calendar holds the next recheck date, they answer the successor’s questions, and their name in the packet tells whoever inherits the account in a year whom to ask. When that person changes role, updating this line is the first handoff task.

Set the recheck interval from how fast the inputs change. A workflow that reads a pricing file needs a check whenever that file is refreshed; one that summarises internal call notes can wait longer. Write the interval next to the date, and add a “last checked” line the owner updates each time. Anthropic's Project guide documents no workflow reminder for a standard chat Project, so put the date wherever your team already manages reminders. Cowork projects can include scheduled tasks on paid plans. Claude Code can rerun a Skill with session-scoped /loop or a cloud Routine.

What does not survive the handoff

If your team already works in a code repository, a Claude Code Skill is a more transferable package than a chat Project. Anthropic’s Skills documentation, checked September 14, 2026, describes a Skill as a SKILL.md file plus supporting files, committed to .claude/skills/ so everyone working in that repository gets it, or distributed through managed settings or a plugin to reach an organization. Git adds a history of every change to the instructions and a pull request as the review step. The cost is that Skills need Claude Code, which many product marketers do not use.

Anthropic's Project documentation does not describe an instruction diff or approval queue. For reruns, choose session-scoped /loop, a Desktop scheduled task or a cloud Routine according to the files, persistence and review the job needs; Anthropic's scheduled-tasks documentation, rechecked September 16, 2026, distinguishes these options. Scheduling runs the job; it does not approve the output. Define the review before someone acts on the result.

Where a built product handles the approval step

No user-facing feature was found that packages or hands off an arbitrary Claude workflow, so Steve does not replace the packet. When news changes a battlecard, Steve shows the current text beside a suggested update and lets you keep the current text, apply the update or accept both.

If the packet exists mainly because battlecards keep going stale between owners, Steve’s competitive-intelligence product is worth evaluating for that job. For other Claude workflows, write the five-part packet and test it before the new owner relies on it.