Claude Code Handoff: Pass the Task and the Next Step

A Claude Code handoff should pass the task’s goal, current code state, human decisions, verification results, and the next action. Save that record before stopping, then have the receiving session inspect the actual files before making changes. A transcript can explain the conversation, but it does not establish what is currently on disk.

fenbs keeps the task, Decisions and rules, and Where we left off available to the next connected assistant. You can use the same handoff routine when another Claude Code session, a different coding assistant, or a teammate takes over.

What should you do before handing over?

1. Reach a stable stopping point. Identify commands or processes that are still running, and say whether they should remain active.
2. Inspect the working files and changes. Name the branch or revision, any uncommitted work, and files created or changed during this task.
3. Record the human decisions and limits that still apply. Separate approved choices from proposals awaiting an answer.
4. List checks actually run, their results, and checks still needed. Include the relevant environment when it changes the meaning of a pass.
5. Write one next action and its prerequisite. Ask the receiver to restate that action after inspecting the project.

This takes less effort when you update the task as you work. Do not wait for an abrupt session limit or a laptop shutdown to reconstruct every important detail. After each useful milestone, save the smallest account that would prevent the next session from repeating your investigation.

Which code state does the next session need?

A coding handoff needs both the explanation and the files it describes. Name the repository, working directory, branch, and checked revision where applicable. Say whether the useful changes are committed, uncommitted, or available as an explicitly shared patch. A commit identifier by itself is not enough if the recipient cannot access that commit.

Read-only checks such as git status --short and git diff --stat can help describe the working tree, the current collection of files and edits. Review the relevant changes as well; a file count does not tell you whether a task is finished. Include new files, which may not appear in an ordinary diff of tracked files.

If several assistants are working, identify which files belong to this task and which contain someone else’s work. Tell the next session to preserve those other changes. A handoff should never imply that every modification in a shared folder was created by the departing assistant.

Anthropic documents parallel working copies in its common workflows↗ (opens in a new tab). Our Claude Code worktrees guide explains that arrangement separately; the handoff still needs to identify the particular copy containing the work.

How do you separate decisions from suggestions?

Record who chose the approach and what the choice covers. For example, “The owner approved keeping the existing sign-in flow; the new screen may change its wording only” is actionable. “We decided to simplify sign-in” hides both the decision maker and the limit.

Label unresolved choices plainly. If the assistant proposed changing a database field but nobody approved it, the handoff should say that approval is pending. Do not let a confident summary turn a suggestion into an instruction. Keep the proposed change distinct from the work the next session is already authorized to do.

In fenbs Decisions and rules, a person’s recorded rule can stay visible before the next assistant reads ordinary notes. That helps a session preserve the reason for a limit instead of treating it as an incidental line in old chat history.

What counts as useful verification evidence?

Write down the check, result, and boundary of the result. “Ran the form validation tests in the changed package; all passed; did not exercise a real email delivery” tells the next session what remains. “Tests passed” is too broad when only one test file ran.

If a command was interrupted, inspect its effects before rerunning it. Anthropic’s session documentation↗ (opens in a new tab) distinguishes restored conversation state from interrupted work. Treat an incomplete result as unknown until you check the relevant files or system.

Keep the record free of secrets and private output that the recipient does not need. A short failure description and the location of an authorized log are often enough. The goal is to transfer useful evidence, not every line a terminal happened to print.

What should the receiving assistant read first?

Give the receiver the applicable project instructions, task, current decisions, and progress checkpoint. Then ask it to inspect the current files and compare them with the handoff. Files may have changed since the summary was written, especially when a teammate is working in parallel.

Task: Add an empty state to the customer list.
Approved scope: Wording and layout only; preserve the data request.
State: Draft changes are uncommitted in the named working copy.
Files: CustomerList.tsx and its display test.
Verified: The display test passed against the current draft.
Not checked: Narrow-screen layout and keyboard focus.
Waiting: Owner approval of the final wording.
Next: Inspect the diff, then check keyboard focus without changing data behavior.

Use a specific receiving prompt: “Read this handoff, inspect the files, and tell me the first action you will take.” A correct answer should identify the outstanding checks and respect the waiting decision. If it misses either, fix the misunderstanding before allowing more edits.

A saved session can be convenient, and Claude Code checkpoints can help with limited recovery. Anthropic notes in its checkpointing documentation↗ (opens in a new tab) that checkpoints do not replace version control. They also do not replace an explanation another person can follow.

How to do this with fenbs

1. Create a free account, add the project, and create the coding task you intend to hand over.
2. Keep the implementation steps and file scope in the task plan. Record decisions a person actually made and leave unanswered choices open.
3. Connect your supported coding assistant and ask it to read the project context. Before stopping, save task progress with the checks and their actual results.
4. Save Where we left off with the working-copy location, remaining work, and next action. Have the receiving assistant read it and inspect the files before editing.

fenbs does not transfer your repository, run tests for you, or copy a local Claude Code runtime to a teammate. If you need only to reopen your own unchanged session, its session controls may suffice. fenbs fits when tasks and decisions must stay usable across people or assistants.

For background, start with what Claude Code is. Use the AI handoff library for the wider routine, and the separate debugging guide when diagnosis itself is the task being handed over.