Write for someone continuing the work with no conversation history. Preserve what they need to understand the current direction and resume at the actual stopping point. Keep the result readable, with detail where losing it would change their next action.
Recover the active thread and how it got here
Read the available conversation, including earlier user instructions and later corrections, together with relevant existing notes. Identify the work being continued from the current intent; an incidental last question need not be the active task. Ask one focused question only if the intended thread is unclear.
Distinguish separate topics from stages of the same investigation:
- If A and B are unrelated completed topics and C is underway, focus on C. Carry forward earlier instructions that still apply across the session. Do not turn completed topics into pending work or import another project's rules.
- If researching A led to C, retain the original need, the finding that changed direction, the resulting decision, and why C is now the work to continue. Preserve enough evidence and rationale to avoid proposing A or repeating that investigation merely because the new session lacks its history.
Keep decisions and their actual reasons, applicable constraints, rejected approaches that could otherwise recur, and unresolved ideas that affect continuation. Preserve a paused obligation when it still matters, without making it the immediate task. Apply later corrections to the specific decisions they change. Distinguish explicit user choices, factual findings, proposals, and tentative interpretations; do not promote an offered option into an agreed direction. If a reason was not captured, say so without inventing one or undoing an explicit choice.
Establish the stopping point from available evidence
Read the actual relevant artifacts and files. For repository work, inspect the checkout, branch/revision, status, relevant staged and unstaged changes, and untracked contents. Account for committed work too. Use equivalent sources outside Git; discussion-only work needs no invented repository or code-phase classification.
Describe what was done and why, what is partly done, and the exact remainder. Separate implemented work from verification, saved work from publication, and settled decisions from unanswered questions. Do not turn an interrupted check, an author's claim, or a clean working tree into proof of completion.
Identify the files, important locations, documents, and commands needed to resume, explaining each one's role. Use recognizable project identity and repository-relative paths where possible; a machine-specific absolute path alone is insufficient for another computer. Capture essential conversation-only details in the summary itself, including precise rules or values that a new session would otherwise have to guess. Link supporting artifacts without making the reader repeat the research to discover the conclusion.
Include relevant observed checks with their command, result, scope, and source basis when known. Mark unverified or stale evidence honestly. Inspect current facts needed for the summary without reopening the task, running a new review, or repeating tests solely to summarize. Report material unavailable context rather than reconstructing it.
For a move between computers or checkouts, identify relevant uncommitted, untracked, or unpushed work and other needed local artifacts. State what must be available at the destination and what availability is unknown. A summary does not transfer files; do not commit, push, copy work, or assume missing edits exist on the other machine.
Write a usable continuation
Lead with the current goal, direction, and stopping point. Explain how the work arrived there, then connect decisions, current progress, relevant files, and open questions to the next action. Use short paragraphs, headings, or a small list as helpful; require no fixed section inventory, phase form, or transcript.
Preserve details that prevent drift or repeated work. Compress repeated discussion and irrelevant completed detours rather than erasing the reason behind a decision. Make references such as "option B" or "the previous fix" explicit. Use the requested language, otherwise the conversation's language.
End with the concrete action to resume and any real prerequisite or pending user decision. Preserve the existing scope and authorization; do not create a new plan, choose an unresolved option, or add a generic menu asking what to do next. Direct the next session to locate the needed sources, confirm they still match the recorded state, and continue from the remainder. Relevant changed evidence can require a targeted recheck; starting a new session alone does not reopen settled research.
Return a self-contained, paste-ready summary by default. When a file is requested,
use the supplied destination or established project location; otherwise choose a
descriptive file under .summaries/ in the intended project. Check existing content
before writing and preserve unrelated or intervening edits. Return the saved path
and a short starter message identifying that summary and where to resume. Keep
essential decisions in the summary in either form; do not assume private session
memory or access to the original computer.
Before returning, read the result as the new session: is the actual current task clear, is its route and rationale preserved, are shared instructions carried forward, and can the reader identify the correct files, unfinished work, and next action? Check that old topics cannot be mistaken for current work and that uncertainty or missing files are visible. Recheck relevant sources if they changed while writing. End after delivering the summary; do not start the resumed work or another session.