Continuity

Continuity: a context-transfer protocol for sessions, users, and agents

Why this exists

Every new session starts blank. When work is interrupted — because the session got slow, because the person picking it up next is someone else, or because a different agent or tool will continue it — losing the thread is expensive: the goal has to be re-explained, what was already tried has to be recalled, and there's a real risk of retrying a path already ruled out for good reason, or worse, assuming something is safe or true when it was never verified.

A Continuity document is not a courtesy summary — it's a protocol. Handing off between two instances of the same session is the easy case; the harder (and more common in practice) cases are handing off to a different user who wasn't in the room for the original conversation, or to a different agent that has no memory of it at all and possibly different tools or access. A normalized structure matters most in exactly those harder cases: it forces explicit statements about what was assumed, what was decided, what's off-limits, and what's genuinely still open — instead of leaving the next reader to guess.

When to use it

Only when explicitly requested. Don't offer it proactively and don't generate it "just in case" when a task wraps up — the trigger is a direct request like "make me a continuity doc," "handoff," "I want to hand this off to someone else," "prep this for another agent to pick up," etc.

If requested mid-task (not at the end), generate it anyway — the document describes the state at that moment; it doesn't require the task to be finished.

Who is this for?

Before writing, work out who receives this, since it changes what needs spelling out:

• Same user, new session — they already know the implicit context (why the project matters, house conventions, tone). You can be terser about background and focus on state and next steps.
• A different user (a colleague taking over, a client's team, etc.) — spell out background and conventions the original user took for granted. Don't assume they'll recognize shorthand or internal references.
• A different agent or system — assume zero shared memory and possibly different tool access. Be literal and unambiguous; don't reference "the tool we used" without naming it and how to get it.

State the intended recipient explicitly in the document header — it's a load-bearing fact, not metadata.

What language to write it in

Write the document in the same language the session has been using. If the conversation is in Spanish, the document is in Spanish; if English, English; and so on — the point is to be read and acted on immediately, not to default to any one language.

How to generate the document

1. Reconstruct the whole session

Review the entire current conversation from the start, not just the last few messages. Pay special attention to:

• The original request and how it evolved (the goal sometimes shifts mid-way — reflect the current goal, not a stale initial one).
• Moments where someone redirected, rejected a proposal, or said "let's do it this way instead" — these are gold: they reveal real decisions and rejected paths, not just what you'd guess was "probably" ruled out.
• Files, code, or documents actually produced (with their real path or location, not a placeholder).
• Anything treated as true without being checked — a assumed file format, an assumed timezone, an assumed default — these become the Assumptions section.
• Anything explicitly kept out of scope for privacy/security reasons — credentials, personal data, proprietary details — these become the Excluded sensitive data section.
• Boundaries already in force — a budget, a deadline, a platform limitation, a compliance rule, a style guide — these become the Constraints section, and are distinct from Risks (a constraint is a fixed rule; a risk is something that might go wrong).

If something was left ambiguous or never explicitly discussed (e.g. the business objective behind the task, or why an option was discarded), don't invent it. Ask before writing it down, or mark it "not explicitly discussed." A fabricated decision is worse than a flagged gap — the gap is visible, the fabrication isn't.

2. Build the file name

Format: CONTINUITY-[topic]-[YYYY-MM-DD].md

• [topic]: a short slug (2-5 words, lowercase, hyphenated) identifying the task — infer it from the conversation (e.g. voice-server-migration, continuity-skill, client-proposal-acme). If the topic isn't obvious, or two tasks are mixed together, ask before naming the file.
• [YYYY-MM-DD]: today's date. Included so resuming the same task repeatedly builds a history of handoffs instead of overwriting the previous one.
• If one with the same topic and date already exists, append -v2, -v3, etc.

3. Write the document with this structure

Use exactly these sections, in this order. If a section doesn't apply (e.g. no known risks, or nothing sensitive was excluded), include it anyway with a line saying so ("None identified") — don't omit it. An omitted section reads as "forgotten to check"; a stated "none" reads as "checked, and there's nothing here."

# CONTINUITY: [Short task title]

**Topic:** [slug]
**Date:** [YYYY-MM-DD]
**Origin:** [what session/context produced this document, and what triggered the handoff]
**Intended recipient:** [same user in a new session / a different user / a different agent or system]

## 1. Objective
Why this task exists and what it's trying to achieve — the problem it solves or
the goal it serves, not just what was literally asked. If this changed during
the session, describe the current, up-to-date objective.

## 2. Current state (executive summary)
2-4 sentences someone can read and immediately understand where things stand
right now, without reading the rest of the document.

## 3. Completed / resolved
What was accomplished and considered closed. A concrete list, not a generic one.

## 4. Decisions made
What was decided and why (the reason matters as much as the decision — without
it, the next reader might undo something already validated). Decision → reason.

## 5. Decisions rejected
What options were considered and turned down, and why — so the next reader
doesn't reopen a path already proven not to work. If something was rejected
without an explicit reason, say so.

## 6. Constraints
Fixed boundaries the work must respect: budget, deadlines, technical or
platform limits, legal/compliance rules, brand or style requirements, access
limitations. Not a risk — a rule already in force.

## 7. Assumptions
Things treated as true but not independently verified (e.g. "assumed the
staging environment mirrors production," "assumed the export is UTF-8").
Flag each one so the next reader knows what to double-check before relying on
it further.

## 8. Excluded sensitive data
What was deliberately left out of this document — credentials, personal data,
proprietary or confidential information, secrets — and why, plus where the
recipient should go to get it through proper channels instead of assuming it's
embedded here. If nothing sensitive came up, state that explicitly.

## 9. Artifacts produced
Documents, code, files, or deliverables produced, with real location (path,
file name) and one line on what each contains. If nothing's been produced yet,
say so explicitly.

## 10. Open items / next steps
What's left, ordered by priority — what should happen first when this is
picked back up.

## 11. Risks or blockers
Anything that could stall progress: external dependencies, pending approvals,
missing data, technical risks identified but not resolved.

## 12. Open questions
Decisions not yet made that whoever continues this will need to resolve.

## 13. How to resume
Concrete instructions for whoever picks this up — tailored to the intended
recipient from the header. If it's a new chat with an agent, a literal
first message ready to paste in. If it's a person taking over, a short
briefing note in plain language.

## 14. References
Links or mentions of threads, tickets, external documents, or prior
conversations relevant here. If none, say "None."

4. Save and deliver the file

Save the .md file to the outputs folder and share it via present_files (or the environment's equivalent). No need to convert it to Word or PDF — Markdown is intentional: easy to paste into a new session and easy for another agent to parse.

Common mistakes to avoid

• Generic filler. "Significant progress was made" is useless to someone who wasn't there. Every section needs content that's specific and verifiable against the actual conversation.
• Inventing the "why." If the reason behind a decision was never stated, don't fabricate one for polish. "Reason not stated" beats an invented justification that could drive a bad decision later.
• Forgetting rejected paths. "Decisions rejected" is usually the most valuable and easiest section to skip.
• Treating "excluded sensitive data" as optional. Even when nothing sensitive came up, say so explicitly — silence reads as an oversight, not a clean bill of health.
• Confusing constraints with risks. A constraint is a rule already in force (a deadline, a budget); a risk is something that might go wrong. Keep them in separate sections — conflating them hides which one requires action versus which one just needs to be respected.
• Assuming the recipient is identical to the original user. Re-check the "Intended recipient" field before writing — a handoff to a different user or a different agent needs more spelled-out background than a same-user, same-session resume.
• Generic or invented file paths. Use an artifact's real location exactly as it appears in the conversation, never a placeholder.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: alfredcertain
• Source: alfredcertain/claude-skills
• License: Apache-2.0

Install and usage instructions live in the source repository linked above.