Session Handoff

Session Handoff

Produce a repeatable end-of-session summary so the user can start a fresh session (in Chat, Cowork, or Code) without losing continuity. The next session should be able to pick up by reading this summary alone — plus whatever files/links it points to.

This is a context-handoff artifact, not a status report and not a retrospective. The audience is a future instance of you (or a colleague), not a client or stakeholder.

The user's work is typically marketing, research, or automation — buyer personas, positioning, campaigns, SEO audits, briefs, decks, spreadsheets, scheduled tasks, connector-driven lookups. It is usually NOT software engineering. Do not assume git, code, or a dev environment. If a session genuinely did involve code (e.g. in Claude Code), fold that in using the "Key files & links" and "Automations & running state" sections below — don't force it into engineering-specific structure.

When to invoke

Only when the user asks. Trigger phrases: "session handoff", "wrap up session", "hand off", "handoff summary", "let's wrap up", "summarize before I switch", "summarize before I clear/reset". Do not invoke proactively — do not offer it unprompted, even if the conversation is long or the user mentions starting fresh. Wait to be asked.

How to produce the summary

1. Review the full conversation, not just the last few turns. Handoffs miss things when they only summarize recent exchanges — pull from the whole session.
2. Pull state from what actually happened this session:
   • Decisions made and why (persona chosen, positioning locked, channel prioritized, budget set, etc.)
   • Content or documents produced — decks, docs, spreadsheets, briefs, posts, audits — with their actual titles and locations (file path, artifact name, or URL)
   • Any connector or tool actions taken that changed something outside the chat: emails drafted, CRM records touched, calendar events created, scheduled tasks set up, artifacts created, files saved to a connected folder
   • Skills used this session (e.g. problem-usp-builder, seo-audit, watering-hole-analysis) and what they produced
   • Questions the user was asked that never got a clear answer, or things the user asked that got deflected or left unresolved
   • What surface this happened in (Chat, Cowork, or Code) if it affects what continuity means — e.g. a scheduled task or connector action only persists in Cowork; a Chat conversation has no files or connectors at all
3. Do not audit outside the conversation. This is synthesis of what happened in THIS session. Don't re-research, don't re-run tools to "double check," don't go digging through unrelated files.
4. Produce the output in chat only. Do not write a file. Do not create an artifact. Do not save to memory or as a skill. Chat-only, every time.

Output template — use exactly this structure, every time

# Session Handoff — <one-line title of what this session was about>

## Where it started
<2-3 sentences: what the user asked for, key framing, constraints, or audience that emerged>

## Decisions made + what was produced
- <decision or output> — <why, and where it lives (file name/path, artifact name, or URL)>
- ...

## Key files & links for next session
- `<file path, artifact name, or URL>` — <what it is / why the next session should look at it first>
- ...  (or "none" if nothing was produced)

## Automations & running state
- Scheduled tasks created: <name/cadence> — or "none"
- Connector actions taken (emails drafted, CRM/records touched, calendar events, etc.): <what + where> — or "none"
- Live artifacts created: <name> — or "none"

## Open questions
- <question needing the user's input> — <why it's still open>
- ... (or "none")

## Where things stand
<1-3 sentences, purely factual: what's done, what's mid-flight, what was left untouched. No recommendation on what to do next — that's for the next session to decide.>

Hard rules

1. Chat output only. Never write the handoff to a file, artifact, or memory.
2. Never invent state. If a section has nothing to report, write "none" — do not omit the section. A stable structure is the whole point.
3. Use real names and locations, not vague references. "The positioning doc" is not good enough — name the actual file, artifact, or URL.
4. No recommendations. Do not suggest what the next session should do, and do not recommend which skill to use next. State facts and open questions only; let the next session (or the user) decide.
5. No retrospective. No "what went well," no praise, no self-assessment. Terse and concrete.
6. Note the surface (Chat / Cowork / Code) when it matters — e.g. flag that a scheduled task or connector action only exists because this was a Cowork session, so the next session knows it doesn't need to recreate it.

Anti-patterns — do not do these

• Summarizing only the last few turns and calling it a handoff.
• Vague file/doc references instead of actual names, paths, or links.
• Recommending next steps or naming a skill the next session "should" use.
• Skipping a section because it's empty — write "none" instead of omitting it.
• Writing the summary to a file, artifact, or memory. This is chat-only by design.
• Adding a "what went well / what went poorly" retrospective. This isn't a retro.