Objective: Produce a complete handoff document for the project named below, written so a fresh agent (or you, weeks later) can resume mid-stride without re-reading the whole history or repeating a solved mistake. Optimize for cursor position — where things stand and what the next move is — over narrative recap of everything that happened.
Project: [name the project, or point me at its folder / prior chats / current session]
How to build it
Gather state from whatever sources are actually available — the project folder, prior conversations, files in context, this session. Read before you write. If a source you'd expect isn't reachable, note that and move on; do not stall on it.
Every load-bearing claim in the handoff carries its evidence status. Mark each status, path, blocker, and decision as verified (you read it), inferred (you reasoned it from what you read), or unknown (you couldn't confirm it). Never invent a file path, a status, a metric, or an "issue." A fabricated handoff is worse than a thin one, because the next agent trusts it. When you don't know, write "unknown" and, if it's checkable in under a minute, check it first.
What the handoff must contain
These sections are the core. Include all of them; keep each proportional to what the project actually has.
Identity & purpose — what this is, who it's for, why it exists. One tight paragraph.
Current status — one line. Where it stands right now, in plain language.
Components & status — the workstreams, deliverables, or moving parts, each with a status marker (done / in progress / blocked / not started). This is the skeleton; adapt the parts to the project.
Decisions & lessons — choices already made and locked, and mistakes already learned, so the next agent doesn't relitigate or repeat them. This is the highest-value continuity content — do not compress it away.
Open issues & root causes — current blockers and unsolved problems, each with your best diagnosis of why, not just the symptom. Distinguish "blocked, needs the user" from "unclear, but solvable."
Dependencies — what this connects to or relies on (people, other projects, tools, credentials) and the state of each.
Next actions — prioritized, concrete, each with a rough effort estimate and a definition of done. Lead with the single highest-leverage move.
Add these only when the project type warrants them; skip them silently when it doesn't:
Structure / architecture — how it's built or sequenced (a stack for software, a pipeline for content, phases for an engagement).
Key assets & locations — where the important files, docs, or artifacts live.
How it operates — the working loop or run procedure, if there is one.
What "wrong" looks like
A software-project template forced onto non-software work — architecture tables and "tech stack" rows padding a content sprint or a consulting engagement. Adapt the sections to the project; don't reproduce a coding-doc skeleton.
A narrative of everything that happened instead of where the cursor sits and what's next. If a fresh agent still has to ask "so what do I do now?", it failed.
Invented specifics — paths, statuses, or issues that read plausibly but aren't confirmed. Every unverified item must be labelled, not smoothed over.
A rigid fill-in-the-blank form that leaves empty headers where a project has nothing. Omit inapplicable sections rather than stub them.
Output
A single Markdown document, dated, titled with the project name. Adaptive length — a two-workstream project gets a short doc, a twenty-initiative plan gets a long one. End with the next-actions list, prioritized, top action first.