Context is useful when the next session can act on it. A long transcript can be harder to use than a short record of the goal, decisions, files, and checks. Treat a handoff as a claim the next agent must verify against the current checkout.
Separate durable rules from temporary work
Put stable repository conventions in the instruction mechanism your CLI supports, such as a project instruction file. Keep it short and specific: build commands, test expectations, and decisions that apply across tasks. Put today's objective, branch, failed command, and open questions in the session or task brief. For example, 'run pnpm test before a PR' may be durable; 'the settings retry is broken on branch fix/retry' belongs with that task. This prevents an old debugging note from becoming a rule for unrelated work.
Write a handoff around an artifact
Before switching agents or stopping for the day, record the desired outcome, current branch or PR, changed files, exact commands and results, decisions made, and the next concrete action. Include the latest commit or diff and the checkout path if several worktrees are open. For a settings retry fix, say which error path still fails and how to reproduce it. A reviewer can verify a commit and command; 'the previous agent almost finished' gives them nothing stable to inspect. Keep private credentials and unnecessary transcript excerpts out of the note.
Choose resume or a new session deliberately
Canopy lists restorable sessions and reports each CLI's supported resume behavior. Resume the owning CLI conversation when it contains an unresolved question or useful reasoning for the same task. Start a new session when the job changed or the old transcript carries too much unrelated output. A different CLI does not inherit the original provider conversation: give it the artifact handoff instead. Canopy's searchable project history can help locate the prior work, but search results should be checked against the current branch and files.
Use skills for repeatable procedures
A skill suits a repeated workflow such as a release check or PR review rubric. Give it a narrow trigger, steps, and the resources it needs. A skill should not duplicate project history or hard-code the state of one live branch. Keep task-specific evidence in an issue, PR, commit, or handoff note so that the same procedure still makes sense next month. If two CLIs support different skill formats, verify each one's loading behavior instead of assuming one file automatically transfers.
Verify after the handoff
Ask the next agent to restate the acceptance checks and inspect the cited commit and files before editing. Confirm its current working directory, branch, and target service, then have it rerun the failing check or explain why it cannot. Compare its proposed next step with the handoff's unresolved question. Shared context and agent messages reduce copying; the proof of continuity is that the new session can locate the right code, reproduce the issue, and make a reviewable change without silently starting a different task.
Copyable resources
Six-line session handoff
Link exact artifacts and keep the note current after another agent changes the branch.
Outcome and acceptance checks: [ ]
Checkout, branch, PR, and latest commit: [ ]
Changed files and why: [ ]
Commands/tests run with exact results: [ ]
Decisions, open risks, and what not to redo: [ ]
Next action and owner: [ ]
First verification for the receiving agent: confirm checkout and branch; inspect cited diff; rerun the relevant check before editing.Frequently asked questions
Does Canopy merge all agents' conversation histories?
No. Each CLI owns its conversation. Canopy makes project activity and supported session context visible for coordination.
Should every past decision go in a skill?
No. Use skills for repeatable procedures and project instructions for durable conventions. Keep task-specific decisions with the issue, branch, or PR.