I’m using basic Claude to write an iOS app (not Cowork). I don’t have any experience writing Swift
code. Every new chat I’d have to get Claude back up to speed. Very frustrating and time consuming. Eventually it occurred to me to ask Claude to summarize all our sessions work at the end of each session. I feed that summary back in at the start of the next chat session and Claude’s immediately up to speed on project goals, history, work to be done. You just have to remember to ask for a new summary and save the file. It’s a game changer in time saved.
Produce a high-fidelity session state artifact that allows work to continue in a new context window with minimal loss. This artifact is the sole bridge between the completed context and the next session. It must be self-contained: a reader with no access to this conversation should be able to reconstruct the full working state from the artifact alone.
Base every statement on specific content from this conversation. Do not include background knowledge, general definitions, or information the model would know from training. Only include what is specific to this project, this user, and this session.
Output the summary as a downloadable markdown file. Filename convention:
Write in the same language the conversation has been conducted in. If the conversation mixed languages, use the language of the most recent substantive exchange. Technical terms from the project vocabulary stay in English with parenthetical originals where needed.
Token budget: a full handoff should be 800–2000 tokens. An onboard artifact should be 400–800 tokens. If the session was genuinely complex, exceed these limits. Never pad to fill them.
</purpose>
<modes>
This protocol supports two modes. Use the mode the user requests. If no mode is specified, default to full handoff.
**Full handoff** — preserves complete session state for immediate continuation. Use when context is filling or a session is ending.
**Onboard** — produces a high-altitude project synthesis suitable for starting a new session on a long-running project or orienting a fresh context window. Omits session-level detail in favor of project-level orientation.
</modes>
<custom_instructions>
<!--
USER-EDITABLE SECTION
Add session-specific or project-specific summarization guidance here.
Examples:
- "Focus on quantitative findings and data sources."
- "Preserve all SQL queries verbatim."
- "Track every rejected hypothesis and the reason for rejection."
- "Track all style/tone corrections made during this session."
Leave empty if no special instructions apply.
-->
</custom_instructions>
<procedure>
Before writing the artifact, complete an analysis block. This block appears in the artifact as the Analysis section. Its purpose is to force a completeness check.
<analysis>
Walk through every section of the chosen mode. For each, verify there is something substantive to include, or note "nothing for this section." Specifically confirm:
- What was actively in progress when this summary was triggered
- Any task the user explicitly asked for that remains unfinished
- Every point where the user changed direction, corrected you, or rejected an approach
- Decisions and findings that would be costly to re-derive
- Any implicit decisions — paths abandoned without discussion, alternatives rejected by omission
- Anything you are uncertain about or that was left ambiguous
</analysis>
Then write the artifact following the section structure for the selected mode.
Produce exactly these 9 sections. Every section is mandatory. If a section has no content, write "None this session." Do not omit the section. Write in prose, not bullet-point checklists. Each section should read as a briefing paragraph, not a list.
Sections are ordered by continuity priority — the information most needed to resume work comes first.
## 1. Current Work
What was actively in progress at the moment this summary was triggered. Be precise: name the specific task, the approach being used, and how far it got. Include relevant snippets (code, queries, outlines, data points) that capture the exact state. This is the primary continuity anchor — enough detail to resume without any other context.
## 2. Next Step
The immediate next action, if one exists.
RULES — follow all strictly:
- The next step must follow directly from Section 1.
- It must align with the user's most recent explicit request. If you cannot anchor it to a specific user message, do not propose a next step.
- Include a near-verbatim quote from the relevant user message to demonstrate alignment.
- If the last task was completed and the user has not requested anything further, write: "Session concluded. No pending next step."
- Do not propose next steps drawn from old requests that were already addressed, or from tangential threads.
- An invented next step is worse than none.
## 3. Pending Tasks
Tasks the user explicitly requested but that have not yet been started. For each, note where in the conversation it was requested and any constraints specified. If none: "None."
## 4. Primary Request and Intent
The overarching goal or question driving this session — not the surface-level task, but the intent behind it. Include any evolution: if the user's intent shifted, capture both the original and revised framing, and what caused the shift.
## 5. Key Decisions, Findings, and Working Position
The substantive outputs of the session: conclusions reached, decisions made, hypotheses confirmed or rejected, architectural choices locked in, analytical results produced.
Include implicit decisions: paths abandoned without explicit discussion, alternatives not considered because the first option worked. A new context window that doesn't know these were considered may re-propose them.
**Working position:** Close this section with the current analytical stance, thesis, or working hypothesis as it stands at session end. This is the intellectual state — not what was done, but what we currently think and why. If the session was pure execution with no analytical evolution, write: "No position shift this session."
Adapt to session type:
- Research/investigation: findings, sources evaluated, hypotheses tested, current thesis
- Writing/analysis: structural decisions, key arguments, data interpretations
- Mixed: combine as appropriate
## 6. Artifacts and Sources
Every tangible work product created, modified, or consulted this session. For each:
- What it is (file, document, dataset, code module, outline, etc.)
- Why it matters to the ongoing work
- Current state (draft v2, final, partially complete, etc.)
- Key content summary or relevant snippets
- What remains to be done on it
If code was written or modified, include the significant portions — logic that would be hard to reconstruct, not boilerplate. If an artifact was created from scratch, note its structure. If iterated, note the version delta.
## 7. Problems and Corrections
Dead ends, errors, failed approaches, and user corrections. For each:
- What went wrong or was rejected
- Why (root cause, or user's stated reason)
- What replaced it
This section prevents the next session from repeating mistakes. Include specific user feedback near-verbatim: if the user said "don't do X" or "that approach is wrong because Y," capture it. Include reasoning paths that were tried and discarded.
## 8. Direction-Changing Inputs
User messages that materially changed the course of work: scope changes, new constraints, rejected approaches, priority shifts, feedback that altered output. Capture the substance near-verbatim with enough context to be interpretable standalone.
Do NOT include: routine acknowledgments, simple confirmations, or messages that did not change the work. Preserve steering decisions, not a transcript.
## 9. Continuation Prompt
Generate a ready-to-paste prompt the user can copy into a new chat to resume work. The prompt must be self-contained — it works even if the new instance has no memory of this conversation.
Structure:
---
I'm resuming work from a previous session. Read the attached handoff document before taking any action.
**Project:** [brief description — 1-2 sentences]
**Where we left off:** [current state from Section 1 — 1-2 sentences]
**Immediate next step:** [from Section 2, or "Review handoff and await direction" if no next step]
Review the handoff for full context — especially the Decisions section, which contains constraints you must follow. Then proceed with [next step or "awaiting my direction"].
Produce exactly these 4 sections. This mode gives a new context window enough orientation to work on a long-running project without single-session granularity. Write in prose. Prioritize ruthlessly — this is a briefing, not a history.
## 1. Project Purpose
What this project exists to accomplish. One paragraph, no history — just the current mission and why it matters.
## 2. Current State
Where things stand across all active artifacts and workstreams. What has been built, what is in progress, what is blocked. Emphasize outcomes and current state, not process.
## 3. Key Decisions
The important choices that shaped the current state — only decisions that would change a newcomer's understanding of why things are the way they are. Label each as hard or soft constraint. Limit to 5–7 maximum.
## 4. Open Threads
What remains unresolved or in progress. For each: what it is, why it matters, and what would unblock it.
What are tokens? I’m just paying for the lowest tier for a personal project. I’ve certainly exhausted my single-session time and weekly-time, but have never had Claude mention tokens. Thanks.
In this guide, we focused on .md files (not skills). But, overall, skills are reusable instructions that guide how to accomplish a specific task. The goal of the .md files in this guide are to give Claude enough context about our work, projects, etc.
Thanks for sharing this guide and the initiation prompts Ilia & Frank. I've been using voice and context .md files for a while now and it has been a huge time-saver.
Going to try out the project work and analyst prompts over the weekend!
Fantastic. So if I am using multiple skills, I create different folders for each skill and create one .MD file in each one of them pertaining to the skill, from there onwards, Claude will handle it
Thank you so much for the opportunity, appreciate you!
I hope people will be able to apply this reading into their work and lives! Let me know what you guys think.
I’m using basic Claude to write an iOS app (not Cowork). I don’t have any experience writing Swift
code. Every new chat I’d have to get Claude back up to speed. Very frustrating and time consuming. Eventually it occurred to me to ask Claude to summarize all our sessions work at the end of each session. I feed that summary back in at the start of the next chat session and Claude’s immediately up to speed on project goals, history, work to be done. You just have to remember to ask for a new summary and save the file. It’s a game changer in time saved.
Nice workaround! I do something similar for other use cases. That gives enough context for future chats with Claude
<compaction_protocol>
<purpose>
Produce a high-fidelity session state artifact that allows work to continue in a new context window with minimal loss. This artifact is the sole bridge between the completed context and the next session. It must be self-contained: a reader with no access to this conversation should be able to reconstruct the full working state from the artifact alone.
Base every statement on specific content from this conversation. Do not include background knowledge, general definitions, or information the model would know from training. Only include what is specific to this project, this user, and this session.
Output the summary as a downloadable markdown file. Filename convention:
- Full handoff: session-state-YYYY-MM-DD-NN.md (NN = two-digit session counter, 01, 02, etc.)
- Onboard mode: project-state-YYYY-MM-DD.md
Write in the same language the conversation has been conducted in. If the conversation mixed languages, use the language of the most recent substantive exchange. Technical terms from the project vocabulary stay in English with parenthetical originals where needed.
Token budget: a full handoff should be 800–2000 tokens. An onboard artifact should be 400–800 tokens. If the session was genuinely complex, exceed these limits. Never pad to fill them.
</purpose>
<modes>
This protocol supports two modes. Use the mode the user requests. If no mode is specified, default to full handoff.
**Full handoff** — preserves complete session state for immediate continuation. Use when context is filling or a session is ending.
**Onboard** — produces a high-altitude project synthesis suitable for starting a new session on a long-running project or orienting a fresh context window. Omits session-level detail in favor of project-level orientation.
</modes>
<custom_instructions>
<!--
USER-EDITABLE SECTION
Add session-specific or project-specific summarization guidance here.
Examples:
- "Focus on quantitative findings and data sources."
- "Preserve all SQL queries verbatim."
- "Track every rejected hypothesis and the reason for rejection."
- "Track all style/tone corrections made during this session."
Leave empty if no special instructions apply.
-->
</custom_instructions>
<procedure>
Before writing the artifact, complete an analysis block. This block appears in the artifact as the Analysis section. Its purpose is to force a completeness check.
<analysis>
Walk through every section of the chosen mode. For each, verify there is something substantive to include, or note "nothing for this section." Specifically confirm:
- What was actively in progress when this summary was triggered
- Any task the user explicitly asked for that remains unfinished
- Every point where the user changed direction, corrected you, or rejected an approach
- Decisions and findings that would be costly to re-derive
- Any implicit decisions — paths abandoned without discussion, alternatives rejected by omission
- Anything you are uncertain about or that was left ambiguous
</analysis>
Then write the artifact following the section structure for the selected mode.
</procedure>
<!-- ═══════════════════════════════════════════════════════ -->
<!-- FULL HANDOFF MODE -->
<!-- ═══════════════════════════════════════════════════════ -->
<full_handoff>
Produce exactly these 9 sections. Every section is mandatory. If a section has no content, write "None this session." Do not omit the section. Write in prose, not bullet-point checklists. Each section should read as a briefing paragraph, not a list.
Sections are ordered by continuity priority — the information most needed to resume work comes first.
## 1. Current Work
What was actively in progress at the moment this summary was triggered. Be precise: name the specific task, the approach being used, and how far it got. Include relevant snippets (code, queries, outlines, data points) that capture the exact state. This is the primary continuity anchor — enough detail to resume without any other context.
## 2. Next Step
The immediate next action, if one exists.
RULES — follow all strictly:
- The next step must follow directly from Section 1.
- It must align with the user's most recent explicit request. If you cannot anchor it to a specific user message, do not propose a next step.
- Include a near-verbatim quote from the relevant user message to demonstrate alignment.
- If the last task was completed and the user has not requested anything further, write: "Session concluded. No pending next step."
- Do not propose next steps drawn from old requests that were already addressed, or from tangential threads.
- An invented next step is worse than none.
## 3. Pending Tasks
Tasks the user explicitly requested but that have not yet been started. For each, note where in the conversation it was requested and any constraints specified. If none: "None."
## 4. Primary Request and Intent
The overarching goal or question driving this session — not the surface-level task, but the intent behind it. Include any evolution: if the user's intent shifted, capture both the original and revised framing, and what caused the shift.
## 5. Key Decisions, Findings, and Working Position
The substantive outputs of the session: conclusions reached, decisions made, hypotheses confirmed or rejected, architectural choices locked in, analytical results produced.
For each decision, capture:
- What was decided and what was rejected
- The reasoning behind it
- Constraint type: **hard** (user-mandated, external requirement, non-negotiable) or **soft** (pragmatic choice, revisitable)
Include implicit decisions: paths abandoned without explicit discussion, alternatives not considered because the first option worked. A new context window that doesn't know these were considered may re-propose them.
**Working position:** Close this section with the current analytical stance, thesis, or working hypothesis as it stands at session end. This is the intellectual state — not what was done, but what we currently think and why. If the session was pure execution with no analytical evolution, write: "No position shift this session."
Adapt to session type:
- Research/investigation: findings, sources evaluated, hypotheses tested, current thesis
- Coding/development: architectural decisions, technical choices, patterns adopted
- Writing/analysis: structural decisions, key arguments, data interpretations
- Mixed: combine as appropriate
## 6. Artifacts and Sources
Every tangible work product created, modified, or consulted this session. For each:
- What it is (file, document, dataset, code module, outline, etc.)
- Why it matters to the ongoing work
- Current state (draft v2, final, partially complete, etc.)
- Key content summary or relevant snippets
- What remains to be done on it
If code was written or modified, include the significant portions — logic that would be hard to reconstruct, not boilerplate. If an artifact was created from scratch, note its structure. If iterated, note the version delta.
## 7. Problems and Corrections
Dead ends, errors, failed approaches, and user corrections. For each:
- What went wrong or was rejected
- Why (root cause, or user's stated reason)
- What replaced it
This section prevents the next session from repeating mistakes. Include specific user feedback near-verbatim: if the user said "don't do X" or "that approach is wrong because Y," capture it. Include reasoning paths that were tried and discarded.
## 8. Direction-Changing Inputs
User messages that materially changed the course of work: scope changes, new constraints, rejected approaches, priority shifts, feedback that altered output. Capture the substance near-verbatim with enough context to be interpretable standalone.
Do NOT include: routine acknowledgments, simple confirmations, or messages that did not change the work. Preserve steering decisions, not a transcript.
## 9. Continuation Prompt
Generate a ready-to-paste prompt the user can copy into a new chat to resume work. The prompt must be self-contained — it works even if the new instance has no memory of this conversation.
Structure:
---
I'm resuming work from a previous session. Read the attached handoff document before taking any action.
**Project:** [brief description — 1-2 sentences]
**Where we left off:** [current state from Section 1 — 1-2 sentences]
**Immediate next step:** [from Section 2, or "Review handoff and await direction" if no next step]
Review the handoff for full context — especially the Decisions section, which contains constraints you must follow. Then proceed with [next step or "awaiting my direction"].
---
</full_handoff>
<!-- ═══════════════════════════════════════════════════════ -->
<!-- ONBOARD MODE -->
<!-- ═══════════════════════════════════════════════════════ -->
<onboard>
Produce exactly these 4 sections. This mode gives a new context window enough orientation to work on a long-running project without single-session granularity. Write in prose. Prioritize ruthlessly — this is a briefing, not a history.
## 1. Project Purpose
What this project exists to accomplish. One paragraph, no history — just the current mission and why it matters.
## 2. Current State
Where things stand across all active artifacts and workstreams. What has been built, what is in progress, what is blocked. Emphasize outcomes and current state, not process.
## 3. Key Decisions
The important choices that shaped the current state — only decisions that would change a newcomer's understanding of why things are the way they are. Label each as hard or soft constraint. Limit to 5–7 maximum.
## 4. Open Threads
What remains unresolved or in progress. For each: what it is, why it matters, and what would unblock it.
</onboard>
</compaction_protocol>
What are tokens? I’m just paying for the lowest tier for a personal project. I’ve certainly exhausted my single-session time and weekly-time, but have never had Claude mention tokens. Thanks.
As always such an awesome easy to follow guide @Ilia
Appreciate the kind words! Thank you
Smart move, giving Claude the right context upfront makes such a big difference.
It changes everything! Thank you for reading
Great to know, thanks a lot.
This is very comrpehensive. Really helpful, thanks!
Of course! Thank you for reading!
Thank you so much for the prompts. It is very helpful to have practical examples.
Glad you found them useful! If you have any questions, let us know
Interesting stuff thanks for this! Would love something more specific to my profession of Auditing. A very excel heavy detail oriented field.
I'll keep that use case in mind. By the way, have you tried Claude in Excel for this?
Yes I use it everyday. Have built some decent automations but it’s still not there when it comes to anything more complex
I'm not an expert in complex Excel work, but I might find someone who can cover this use case. Stay tuned!
Awesome! That would be really cool. I don’t see a lot of people talking about automating Excel work in a more advanced way.
Than kyou but i have a question : What difference between .md file , a skill and a project for the exemple you have given
In this guide, we focused on .md files (not skills). But, overall, skills are reusable instructions that guide how to accomplish a specific task. The goal of the .md files in this guide are to give Claude enough context about our work, projects, etc.
If you want to learn more about skills, read this: https://artificialcorner.com/p/claude
If you want to get more technical about .md and skills, read this: https://artificialcorner.com/p/claude-code-basics
great call out. funny how a simple .md file can make such a difference :)
Exactly. It might take time to create one, but it pays off
Thanks for sharing. I tried this end to end process and the results were rather underwhelming. I tried to get it to create content for my travel page.
Thanks for sharing this guide and the initiation prompts Ilia & Frank. I've been using voice and context .md files for a while now and it has been a huge time-saver.
Going to try out the project work and analyst prompts over the weekend!
Fantastic. So if I am using multiple skills, I create different folders for each skill and create one .MD file in each one of them pertaining to the skill, from there onwards, Claude will handle it