Skip to content

Handoff Template

Slack handoffs follow a standard shape. Both chat-session and CC-on-VM handoffs use this template. The point is so that next-Rob (or next-Claude) opening Slack can reconstruct state quickly without reading every prior handoff.

Standard handoff structure

*[Session type] handoff — [one-line headline]*

_Headline_
[2–3 sentences: the most important thing that happened or was decided.
If a reader stops after this paragraph, what do they need to know?]

_What was decided / What landed_
[Bulleted list of concrete outputs. Commits, migrations applied, ADRs
drafted, files produced. Each with enough specificity that the next
session can find the artefact.]

_Verification / Pilot results_
[Where applicable. Actual numbers, sanity checks, observed behaviour.]

_Stumbles worth recording_
[Pattern-recognition material. Things that nearly went wrong, surprises,
lessons. These accumulate into the patterns recorded on the ops site's
session-protocol page over time.]

_State of the system after this session_
[Repo state, commit hash, what's deployed, anything a reader needs to
know about "where things are right now."]

_Deferred / parked items_
[The queue. Everything that was raised, considered, and explicitly
NOT done this session. Each with one line of context.]

_Direction for next session_
[What the next session should open with. If this is a chat handoff to
CC-on-VM, the explicit cycle plan. If chat-to-chat, the interpretive
question to be answered first.]

_Loose ends from this session specifically_
[Small things that aren't quite parked items — credential setups,
configuration changes, one-off observations.]

_Sent using_ Claude

When to use which session type label

The handoff opens with one of:

  • *Chat session handoff — [headline]*
  • *CC-on-VM handoff — [headline]*
  • *Session handoff — [headline]* (if combining or unclear which lane it belongs in)

The label matters because next-Rob skimming the channel needs to know at a glance whether the handoff is interpretive or build-output.

The pinned canonical-spec note

Separate from per-session handoffs, the #esg-screening channel has a pinned note that records the canonical hierarchy — what wins when sources disagree. This is updated when the hierarchy changes (e.g. when ADR-0006 lands and the ops site joins the hierarchy as a rendered surface).

Current pinned hierarchy (priority order):

  1. ADRs
  2. Design note
  3. Migrations
  4. v0.4 workbook

What NOT to put in a handoff

The handoff is the event log, not the standing reference. If you find yourself writing:

  • An explanation of how scoring works → link to the ops site's Scoring methodology page
  • A definition of a term → link to the Glossary
  • A description of the data model → link to the Data model page
  • A description of the operating model → link to Session protocol

The handoff should be specific to this session: what changed, what landed, what's next. Standing knowledge belongs on this site.

Worked example — what a good handoff looks like

The 19 May 2026 chat-session handoff in #esg-screening is a good exemplar. It:

  • Opens with a single-paragraph headline (the methodology shift, the five ADRs, the cycle plan)
  • Lists the eight artefacts produced, by filename and intended commit path
  • Specifies a first action of the next cycle (commit the eight files)
  • Gives the next 4–5 CC-on-VM cycles in dependency order
  • Records deferred items
  • Flags known unknowns where chat-side drafts will need CC reconciliation
  • Specifies verification steps per cycle

That handoff is long because it covers a multi-cycle work plan. Most handoffs should be shorter; a single-cycle handoff might be 8–15 lines.

What a bad handoff looks like

(Recording these patterns so they aren't repeated.)

  • No headline. Reader has to scan the whole thing to know what it's about.
  • Repeats methodology. Re-explains coverage-weighted scoring every time it comes up. Methodology belongs on this site.
  • Implicit state. "We finished the thing." Which thing? What state is the repo in now?
  • No next-session pointer. What should the next session open with?
  • Mixed event log and reference. Long passages explaining how the system works alongside specific session outputs. Split them — handoff is event, site is reference.

Cadence

There is no fixed cadence. Sessions happen when there's work to do — sometimes multiple per day, sometimes weeks apart. Every session ends with a handoff. Even a 20-minute session worth doing is worth a 5-line handoff.

If a session was abandoned without producing anything, write a one-line handoff saying so. The point is continuity, not completion.