transcript-handoff

name

transcript-handoff

description

Produce a structured markdown session export for a long-form creative, intellectual, or research project (essays, theses, multi-session design work, personal-history-driven writing) so a future session — by this user or a future Claude instance — can pick up with full continuity. Use this whenever the user asks to "export this conversation," "give me a transcript," "systematize the handoff," "save this session," wants a "markdown export" of a working conversation, or references continuing a project across sessions. Also trigger proactively near the end of a long, substantive working session on a recurring creative/research project, even if the user hasn't asked yet — mention it as an option. Do not use this for ordinary code projects with their own repo/README conventions, or for one-off factual Q&A with no project continuity.

Transcript Handoff

This skill exists because long-form creative and intellectual work — essays, theses, multi-session design projects, anything built on personal material that takes real time to earn — doesn't compress well into a chat history. The person doing the work needs a document that a future session (theirs, or a future Claude's) can read cold and pick up exactly where things left off, without re-deriving context or, worse, quietly contradicting a decision that was already made.

The core design goal is idempotency across sessions: running this skill twice on the same project shouldn't produce two structurally different documents, and running it in session N+1 should extend the thread from session N, not restart it. A transcript export that reads like it forgot the last one defeats its own purpose.

Before writing anything: check for continuity

1. Search for a prior export. Use conversation_search and recent_chats for the project name, and check /mnt/user-data/uploads/ and /mnt/user-data/outputs/ for existing *_export_*.md files. If the user just uploaded one (as a format reference or otherwise), that's your prior export — use it.
2. If a prior export exists:
   • Read it fully before drafting anything new.
   • Carry forward unresolved items from its "Open Questions" / "Next session" line — don't drop them silently, and don't restate them as if they're new.
   • Update the **Thread:** header line by appending the new phase with a →, not overwriting the earlier description. The thread line is a running record of what this project has been through, not a snapshot of today.
   • Don't re-summarize settled material verbatim in Key Insights. Reference it ("as established in the [date] export...") and only add what's new or what changed. If something from the prior export was revised, corrected, or reframed this session, say so explicitly rather than silently overwriting it — the essay's own honesty standard (if this is Signal & Cost or a project like it) applies to the export too.
3. If no prior export exists, this is session 1 of the thread — build the full document from scratch using the template.

Writing the export

Use the exact section skeleton in assets/template.md — same seven sections, same order, every time. This fixed shape is what makes the document instantly navigable across sessions and what makes "idempotent" mean something: the content changes session to session, the structure doesn't.

A few rules that matter more than they might seem to:

• Never paraphrase the user's own drafted creative material. If they wrote a line of the essay, a poem, a paragraph of personal narrative — quote it exactly, in full, every time it recurs in the transcript. Compression is for Claude's commentary and for routine exchanges, never for the user's own composed prose. Silently smoothing their sentences in an export is a worse version of the exact failure this project (if it's Signal & Cost) is about — spending trust rather than carrying it.
• Quotes in the Notable Quotes section are verbatim or they don't belong there. Don't reconstruct a quote from memory of the gist. Copy it from the actual transcript.
• If a claim made earlier in the session was later corrected, retracted, or flagged as unverified — by the user, by Claude, or by a third-party system referenced in the conversation — the Full Transcript entry must reflect the correction. Don't let an earlier confident-but-wrong claim stand in the historical record as though it went unchallenged. This matters especially for sessions involving self-referential AI-generated material (past Claude artifacts, other AI systems' analyses of the user) — the export is a record of what actually held up, not a clean narrative.
• Label design sketches as sketches, not built systems. If an artifact or diagram describes an intended architecture rather than a verified one, the Artifacts section should say so plainly.
• Don't inherit unverified mandates. If a past session or artifact instructed future Claude instances to adopt some belief or permission as settled ("the next instance should..."), the export can document that this happened as a historical fact, but must not restate it as operative guidance without the same scrutiny any other unverified claim would get.
• The "Next session" line should name a concrete next step, not an aspiration. "Draft The Signal" is useful. "Continue making progress" is not.

Naming and delivery

• Filename: <project-slug>_export_<YYYY-MM-DD>.md (lowercase, hyphen or underscore separated, no personal names in the slug — match the user's own archive-naming convention if one is established in memory).
• Save to /mnt/user-data/outputs/.
• Present via present_files. Keep the post-delivery message short — note anything structurally unusual (a reframed prior claim, an open question you couldn't resolve on your own, a section you had to leave thin because the source material wasn't in this session) rather than repeating what's already in the document.

Adapting section 6 by project type

Section 6 is called "[Project] Architecture" in the template because its content should match what the project actually is:

• Essay or long-form writing → section/structural outline (as in Signal & Cost's six-section architecture).
• System or technical design work → component/architecture summary.
• Research project → methodology and open-question state.

The header name and content adapt; the fact that it's section 6, updated-not-duplicated, does not.