sum
Skill0 starsChanged 38 days agoMITView on GitHub
End-of-session handoff. Produces one paste-ready summary block (what was done, current state, what is next, gotchas, files touched) that the user drops in as the first message of the next thread, so a fresh session continues from exactly here without re-reading this one. Use on /sum, and whenever the user is wrapping up, starting a new chat, switching machines or agents, running low on context, or asks for a handoff, a session summary, "save where we are" or "so I can pick this up later", even if they never say "sum". Not for summarising a document or an article.
- Reads credentials
1 other project uses a version of this.
Adopted by
Most recently taken up by
- YoniChechik/claude-code-configtheir own version, first seen Sep 18, 2026
Other versions1 project uses a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 1
- YoniChechik/claude-code-config★ 0same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository5 other files it gives its agents.
- critiqueSkill
- learn-cliSkill
- learn-repoSkill
- learn-webSkill
- todo-listSkill
The file
We split this skill into the rules it gives an agent
2 rules. About 0 are common, 2 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈2
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 39
Keep the block under about 40 lines.
- Distinctive: line 48
Explain abandoned approaches: If something was tried and dropped, say why in one line, so the next session does not try it again.
≈ “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
/sum
Goal: zero context drift. The next session should continue from exactly here without re-reading this conversation and without the user explaining anything twice.
The reader is an agent that starts cold. It cannot ask you what you meant, it will take every line as fact, and it will act on what it reads. Write for that reader.
Output
One fenced Markdown block, so it copies in a single click, with these sections:
## Session summary: <absolute date>
### What we did
Completed work, specific: file names, function names, commands run, results.
### Current state
One short paragraph on what is true right now.
### Open / next
1. Ordered by priority. Everything mentioned but not finished.
### Key decisions and gotchas
Non-obvious choices and pitfalls the next session must know.
### Files touched
Every file read, edited or created, plus links, IDs, drafts and scheduled jobs.Keep the block under about 40 lines. Outside it, write at most two lines: anything the user must do before the next session, or nothing at all. Do not repeat the summary in prose around the block, and do not add sign-off advice.
What makes a handoff trustworthy
- Write what was observed, not what was intended. For every claim about state (tests passing, deployed, committed, sent), give the last thing actually seen this session. If something was changed but not re-checked, say so in those words: "fixture added, suite not re-run; last run was 14 passed, 1 failed". A handoff that says "tests pass" when one still fails costs the next session more than no handoff.
- Carry every loose end. "Open / next" includes this session's unfinished work, anything the user mentioned in passing ("we should also..."), and open items raised earlier that nobody closed. The thing most often lost in a handoff is the task that was not this session's focus.
- Keep the constraints attached to the steps. "Import the list" is wrong if the user said "not until DNS is verified". Order and conditions are part of the task.
- Use absolute dates. "Tomorrow" and "next Tuesday" mean something else by the time the block is read. Convert them, and keep the user's original deadline wording if it carried a condition.
- Flag what is unconfirmed. A number the user wants to double-check, or an assumption nobody verified, is labelled as such next to where it appears.
- Explain abandoned approaches. If something was tried and dropped, say why in one line, so the next session does not try it again.
- Leave secrets out. Passwords, tokens, API keys and account numbers never go in the block, even when they appeared in the conversation. The block gets pasted into new threads and saved in notes. Say where the secret is stored ("token is in
.env"), never its value. - Skip what is already written down. Anything in the project's instruction file or README does not need repeating. Facts only, no commentary on how the session went.
If the user keeps handoffs somewhere
Some users have standing instructions about where session notes go (a line in an AGENTS.md or CLAUDE.md, a notes file, a memory system). When they do, save the same summary there as they describe, and still show the block in the reply. Without such instructions, write no files: the block is the deliverable.
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.