---

name: write-continue-here locale: caveman-lite source_locale: en source_commit: 82c77053 fence_basis_commit: 82c77053 translator: "Julius Brussee homage — caveman" translation_date: "2026-05-03" description: > Write a CONTINUE_HERE.md file capturing current session state so a fresh Claude Code session can pick up where this one left off. Covers assessing recent work, structuring the continuation file with objective, completed, in-progress, next-steps, and context sections, and verifying the file is actionable. Use when ending a session with unfinished work, handing off context between sessions, or preserving task state that git alone cannot capture. license: MIT allowed-tools: Read Write Bash Grep Glob metadata: author: Philipp Thoss version: "1.0" domain: general complexity: basic language: multi tags: session, continuity, handoff, context, workflow, write

Write Continue Here

Write a structured continuation file so the next session starts with full context.

When to Use

• Ending a session with work still in progress
• Handing off a complex task between sessions
• Preserving intent, failed approaches, and next steps that git cannot capture
• Before closing Claude Code when mid-task

Inputs

• Required: An active session with recent work to summarize
• Optional: Specific instructions about what to emphasize in the handoff

Procedure

Step 1: Assess Session State

Gather facts about recent work:

git log --oneline -5
git status
git diff --stat

Review the conversation context: what was the objective, what was completed, what is partially done, what was tried and failed, what decisions were made.

Got: Clear understanding of current task state — completed items, in-progress items, and planned next steps.

If fail: If not in a git repository, skip git commands. The continuation file can still capture conversational context and task state.

Step 2: Write CONTINUE_HERE.md

Write the file to the project root using the structure below. Every section must contain actionable content, not placeholders.

# Continue Here

> Last updated: YYYY-MM-DDTHH:MM:SSZ | Branch: current-branch-name

## Objective
One-paragraph description of what we are trying to accomplish and why.

## Completed
- [x] Finished item with key file paths (e.g., `src/feature.R`)
- [x] Decisions made and their rationale

## In Progress
- [ ] Partially complete work — describe current state (branch, file:line)
- [ ] Known issues with partial work

## Next Steps
1. Immediate next action (most important)
2. Subsequent actions in priority order
3. **[USER]** Items needing user input or decision

## Context
- Failed approaches and why they did not work
- Key constraints or trade-offs discovered
- Relevant issue/PR links

Guidelines:

• Objective: Capture the WHY — git log shows what changed, not why
• Completed: Mark items clearly done to prevent re-work
• In Progress: This is the highest-value section — partial state is hardest to reconstruct
• Next Steps: Number by priority. Prefix user-dependent items with **[USER]**
• Context: Record negative space — what was tried and rejected, and why

Got: A CONTINUE_HERE.md file at the project root with all 5 sections populated with real content from the current session. The timestamp and branch are accurate.

If fail: If Write fails, check file permissions. The file should be created in the project root (same directory as .git/). Verify .gitignore contains CONTINUE_HERE.md — if not, add it.

Step 3: Verify the File

Read back CONTINUE_HERE.md and confirm:

• Timestamp is current (within the last few minutes)
• Branch name matches git branch --show-current
• All 5 sections contain real content (no template placeholders)
• Next Steps are numbered and actionable
• In Progress items describe current state specifically enough to resume

Got: The file reads as a clear, actionable handoff that a fresh session could use to immediately resume work.

If fail: Edit sections that contain placeholder text or are too vague. Each section should pass the test: "Could a fresh session act on this without asking clarifying questions?"

Validation

• CONTINUE_HERE.md exists at the project root
• File contains all 5 sections with real content (not placeholders)
• Timestamp and branch are accurate
• .gitignore includes CONTINUE_HERE.md
• Next Steps are numbered and actionable
• In Progress items specify enough detail to resume without questions

Pitfalls

• Writing placeholders instead of content: "TODO: fill in later" defeats the purpose. Every section must contain real information from the current session.
• Duplicating git state: Do not list every file changed — git already tracks that. Focus on intent, partial state, and next steps.
• Forgetting the Context section: Failed approaches are the most valuable thing to record. Without them, the next session will retry the same dead ends.
• Overwriting without reading: If CONTINUE_HERE.md already exists from a prior session, read it first — it may contain unfinished work from an earlier handoff.
• Leaving stale files: CONTINUE_HERE.md is ephemeral. After the next session consumes it, delete it. Stale files cause confusion.

Related Skills

• read-continue-here — the complement: reading and acting on the continuation file at session start
• bootstrap-agent-identity — cold-start identity reconstruction that consumes the continuation file this skill produces
• manage-memory — durable cross-session knowledge (complements this ephemeral handoff)
• commit-changes — save work to git before writing the continuation file
• write-claude-md — project instructions where optional continuity guidance lives