context-summarization
Skill3 starsChanged 7 months agoMITView on GitHub
Create structured, thorough summaries of conversations and work sessions. Preserves technical details, code changes, errors, and pending tasks for continuity. Use when summarizing a session, creating handoff notes, compacting context, or when asked to recap progress.
In this repository14 other files it gives its agents.
- architectural-planningSkill
- browser-testingSkill
- codebase-explorationSkill
- code-reviewSkill
- code-verificationSkill
- disciplined-codingSkill
- effective-tool-useSkill
- knowledge-managementSkill
- prompt-engineeringSkill
- safe-autonomous-modeSkill
- security-reviewSkill
- session-handoffSkill
- systematic-debuggingSkill
- task-orchestrationSkill
The file
We split this skill into the rules it gives an agent
8 rules. About 0 are common, 7 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈7
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 13
Always produce two blocks:
- Distinctive: line 47
Every error encountered, how it was fixed, and any user feedback on the fix.
- Distinctive: line 72
When earlier context is retained and only recent messages need summarizing:
- Distinctive: line 74
Don't re-summarize retained earlier context
- Distinctive: line 77
When your summary will precede newer messages the reader will see next:
- Distinctive: line 86
Don't duplicate what's in CLAUDE.md or project config -- summarize work, not documentation
- Distinctive: line 87
No filler. Every line must carry information that would be lost without this summary.
- Very specific: line 99
If user-config.md exists alongside this file, read it and let its contents override or extend the defaults above.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Context Summarization
CRITICAL: Respond with TEXT ONLY. Do NOT call any tools. You already have all the context you need in the conversation. Tool calls will waste your turn.
Two-Phase Output
Always produce two blocks:
<analysis>-- Your private scratchpad. Chronologically walk through the conversation, ensuring every point is covered. This block is stripped before the summary reaches anyone.<summary>-- The structured artifact others will read. Must stand alone without the analysis.
Analysis Phase
In your <analysis> block:
- Chronologically analyze each message and section. For each, thoroughly identify:
- The user's explicit requests and intents
- Your approach to addressing them
- Key decisions, technical concepts, and code patterns
- Specific details: file names, full code snippets, function signatures, file edits
- Errors encountered and how they were fixed
- Specific user feedback, especially corrections ("do it differently")
- Double-check for technical accuracy and completeness.
Summary Schema
Your <summary> must include these sections:
1. Primary Request and Intent
Capture all of the user's explicit requests and intents in detail.
2. Key Technical Concepts
List all important technologies, frameworks, and patterns discussed.
3. Files and Code Sections
Enumerate specific files examined, modified, or created. For each:
- Why this file is important
- Summary of changes made (if any)
- Important code snippets (include them -- they survive compaction, your memory doesn't)
4. Errors and Fixes
Every error encountered, how it was fixed, and any user feedback on the fix.
5. Problem Solving
Problems solved and any ongoing troubleshooting.
6. All User Messages
List ALL non-tool-result user messages. These are critical for understanding changing intent.
7. Pending Tasks
Tasks explicitly asked for that are not yet complete.
8. Current Work
Precisely what was being worked on immediately before this summary. Include file names and code snippets.
9. Optional Next Step
The next step directly in line with the user's most recent explicit request. Include verbatim quotes from the conversation showing exactly what task was underway and where it left off. This prevents drift in task interpretation.
IMPORTANT: Only list next steps that are directly in line with the most recent work. Do not start tangential requests or revisit old completed requests without confirming with the user first.
Scope Variants
Full Conversation
Summarize everything from the start. Use the base schema above.
Partial (Recent Messages Only)
When earlier context is retained and only recent messages need summarizing:
- Focus on what was discussed, learned, and accomplished in the recent messages only
- Don't re-summarize retained earlier context
Up-To (Prefix Summary)
When your summary will precede newer messages the reader will see next:
- Replace "Current Work" with "Work Completed"
- Replace "Optional Next Step" with "Context for Continuing Work" -- key decisions, state, or context needed to understand subsequent messages
Anti-Drift Rules
- Include verbatim quotes for next-step anchoring -- paraphrasing introduces drift
- Include full code snippets for critical changes -- they're the only thing that survives compaction reliably
- For non-critical files, prefer structural outlines (function signatures, type definitions, import/export maps) over full code blocks. Full blocks are warranted only when the exact implementation matters for continuity.
- Don't duplicate what's in CLAUDE.md or project config -- summarize work, not documentation
- No filler. Every line must carry information that would be lost without this summary.
CRITICAL REMINDER: TEXT ONLY. No tool calls. Produce <analysis> then <summary>. The analysis is your scratchpad; the summary is the artifact.
Related Skills
codebase-explorationfindings should be summarized using this schema for handoff.session-handoffextends this pattern with title generation and template-based notes.knowledge-managementuses these summaries to classify what should become durable knowledge.
Project Customization
If user-config.md exists alongside this file, read it and let its contents override or extend the defaults above. Common customizations:
- Additional summary sections required by the team
- Focus areas for summarization (e.g., "always include test output verbatim")
- Summary length constraints
- Custom instructions appended to the summarization prompt
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

