handoff-session
Skill2 starsChanged 6 months agoMITView on GitHub
Use when the user asks to summarize, compact, hand off, or create an end-of-session summary for the next agent.
3 other projects use a version of this.
Adopted by
Most recently taken up by
- MithunWijayasiri/dotclaudetheir own version, first seen Oct 26, 2026
- dsonders/claude-skillstheir own version, first seen Oct 20, 2026
- Yesterday-AI/ytstacktheir own version, first seen Oct 13, 2026
Other versions3 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 3
- MithunWijayasiri/dotclaude★ 4same name
- Yesterday-AI/ytstack★ 2same name
- dsonders/claude-skills★ 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 repository10 other files it gives its agents.
- gitSkill
- html-artifactsSkill
- prompt-writerSkill
- swe-executeSkill
- swe-planSkill
- swe-researchSkill
- swe-reviewSkill
- swe-shapeSkill
- swe-specSkill
- swe-worktreeSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
16 rules. 0 are common, 13 are distinctive, and 3 are very specific to this project.
0
Common
Most of the 3 edited versions we read keep these.
13
Distinctive
This author's own choices. Worth a look.
3
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 28
Use tool state only when it is already known from the session or needed to confirm a specific known item.
- Distinctive: line 33
Prefer precise session facts over general project descriptions.
- Very specific: line 35
If a required section has no information, write none.
- Distinctive: line 36
Use absolute paths for files, directories, worktrees, plans, and memory artifacts when a path is known.
- Very specific: line 37
If a plan or task list drove the session, list it first under Key files for next session.
- Distinctive: line 39
If evidence is uncertain or unavailable, say so briefly instead of inventing state.
- Distinctive: line 44
Do not update memory or project notes from this skill.
- Distinctive: line 45
Do not run broad discovery commands such as repository-wide file scans, git log, or full process audits solely for the handoff.
- Distinctive: line 46
Do not include a retrospective, praise, or stakeholder-style status language.
- Very specific: line 47
Do not recommend a roadmap.
- Distinctive: line 48
Keep the tone terse, concrete, and engineering-focused.
- Distinctive: line 52
Use exactly this structure every time:
- Distinctive: line 83
Before sending, verify that:
- Distinctive: line 84
Every required section is present.
- Distinctive: line 85
No section contains invented or assumed state.
- Distinctive: line 86
All known file paths are absolute.
“Common” is measured: kept by at least 6 in 10 of the 3 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
<purpose>
Produce a terse, repeatable session handoff that lets a fresh AI coding agent continue from the current conversation without losing important context.
</purpose><audience>
The audience is the next AI agent, not a stakeholder or end user.
</audience><objective>
Summarize what happened, what changed, what remains open, and exactly where the next agent should continue. The next agent should be able to use the summary first, then inspect named files or commands as needed.
</objective><workflow>
1. Review the whole conversation, not only the latest turns.
2. Identify session facts that affect future work:
- user goal, constraints, and important context;
- decisions made and rationale that affects future work;
- files created, edited, or repeatedly referenced;
- plans, task lists, notes, or memory artifacts explicitly used;
- commands run for verification and their outcomes;
- background jobs, dev servers, ports, terminals, worktrees, or branches that remain relevant;
- deferred work, unresolved user questions, and known risks.
3. Use tool state only when it is already known from the session or needed to confirm a specific known item.
4. Produce the handoff in chat only.
</workflow><decision_rules>
- Prefer precise session facts over general project descriptions.
- Include only items touched, created, decided, started, or made relevant in this session.
- If a required section has no information, write
none; never omit required sections. - Use absolute paths for files, directories, worktrees, plans, and memory artifacts when a path is known. If only a relative path is known, resolve it against the current working directory before writing it.
- If a plan or task list drove the session, list it first under
Key files for next session. - For running state, include how the next agent can stop or resume the process when that information is known.
- If evidence is uncertain or unavailable, say so briefly instead of inventing state. </decision_rules>
<constraints>
- Chat output only. Do not write a handoff file.
- Do not update memory or project notes from this skill.
- Do not run broad discovery commands such as repository-wide file scans, `git log`, or full process audits solely for the handoff.
- Do not include a retrospective, praise, or stakeholder-style status language.
- Do not recommend a roadmap. Provide only the single most likely next action in `Pick up here`.
- Keep the tone terse, concrete, and engineering-focused.
</constraints><output_format> Use exactly this structure every time:
# Session Handoff — <one-line title of what this session was about>
## Where it started
<2-3 sentences: what the user asked for, key framing or constraints that emerged>
## Decisions locked + what shipped
- <decision or change> — <why it matters, and where it lives if applicable>
- ...
## Key files for next session
- `<absolute path>` — <why the next agent should read this first>
- Plan file: `<absolute path>` — <if a plan drove the session, otherwise `none`>
- Notes or memory touched: `<absolute path>` — <if any, otherwise `none`>
## Key facts for next session
- <fact> — <why it matters>
- ...
## Deferred + open questions
- Deferred: <item> — <why pushed to later>
- Open: <question needing user input> — <context>
## Pick up here
<leave empty, will be filled by the user></output_format>
<completion_criteria> Before sending, verify that:
- Every required section is present.
- No section contains invented or assumed state.
- All known file paths are absolute.
- Running processes, ports, worktrees, and branches are explicit or marked
none. - Verification commands are specific and tied to expected or observed outcomes.
Pick up herecontains one focused next action. </completion_criteria>
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.