handover-save
Skill2 starsChanged 41 days agoMITView on GitHub
Materialize the current conversation's plan into a durable handover doc under .claude/handover/ (survives /clear and session handoffs). Usage: handover-save [slug] (optional; defaults to current branch name)
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 20
If that file already exists, read it first and update it in place (preserve any checked-off progress) rather than clobbering it.
- Distinctive: line 33
Read/grep) — stale anchors are the main way these docs rot.
≈ “Common” is an estimate: at least 1 in 5 of the 308,232 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
You are capturing the plan we have developed in this conversation into a durable, gitignored
handover document, so it survives /clear, context compaction, and handoff to a fresh session or
another engineer. This is NOT a fresh plan — extract what we already worked out.
1. Resolve the target file
- Slug: use
$ARGUMENTSif provided. Otherwise rungit branch --show-currentand derive a slug from the branch (stripfeat/,fix/etc. prefixes; keep it kebab-case). If that yields nothing (detached HEAD or not a git repo), ask the user for a slug — never write to.claude/handover/.md. - Sanity-check a branch-derived slug against what this conversation is actually about. If the
plan we discussed isn't the current branch's work, say so and confirm the slug (or ask for one)
before writing — otherwise the plan is filed under an unrelated name and
/handover-resumeon that branch will never surface it. - Path:
.claude/handover/<slug>.md. - If that file already exists, read it first and update it in place (preserve any checked-off
progress) rather than clobbering it. If it describes clearly different work, append
-2(then-3, …) to the slug and tell the user the final filename so they know what to resume.
2. Extract from THIS conversation — do not re-plan from scratch
First, sanity-check there's actually something worth persisting. If no real plan or in-flight work was developed here (a quick one-off, or work that's fully done with no follow-ups), say so and ask the user to confirm before writing — don't manufacture a plan just to fill the template.
Pull from what we actually discussed: the goal, decisions made (and rejected alternatives), the files and line numbers we touched or identified, open questions, and the concrete next steps. Where you cite code, verify the file:line anchors are still accurate before writing them (a quick Read/grep) — stale anchors are the main way these docs rot.
3. Write the doc in this structure (mirror an existing doc in .claude/handover/)
# <Title> (HANDOVER)
**Status:** <not started | in progress: what's done vs pending | blocked on X>
**Branch:** `<branch>` (cut off `upstream/dev` if not yet created)
**Last updated by session:** <one line of context — what we just finished>
---
## 1. The problem / goal
<What we're solving and why. The "so what". Include the decision and any rejected alternatives.>
## 2. Plan — concrete steps
- [ ] Step with enough detail to execute without re-deriving it
- [ ] ...
(Use checkboxes so a resumed session sees done-vs-pending at a glance. Check off anything
already completed in this conversation.)
## 3. Key code anchors
| Location | What it does / what to change |
|---|---|
| `path/to/file.php:NN` | ... |
## 4. Gotchas / constraints / things learned
<Non-obvious things that would bite whoever picks this up. Cross-reference memory entries by name
if relevant.>
## 5. Open questions
<Anything unresolved that needs a decision before or during execution.>4. After writing
Report the path and a two-line summary of what was captured. Remind the user it's gitignored
(personal scratch) and can be reloaded later with /handover-resume <slug>.
Other versions1 project uses a version of this.
Word for word · 1
- AhmedMerza/claude-skills★ 2100% same
Edited · 0
None found.
Wrote their own version · 0
None found.
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 repository53 other files it gives its agents.
- animateSkill
- api-docs-completeSkill
- best-optionSkill
- browseSkill
- changelog-generateSkill
- checkpointSkill
- claimSkill
- commitSkill
- courtSkill
- design-driftSkill
- designSkill
- expandSkill
- explainSkill
- fix-reviewSkill
- grill-meSkill
- handover-listSkill
- handover-resumeSkill
- i18n-syncSkill
- issueSkill
- leadSkill
- mr-approveSkill
- mr-assignSkill
- mr-createSkill
- mr-guideSkill
- mr-listSkill
- mr-mergeSkill
- mr-review-requestSkill
- mr-reviewSkill
- mr-statusSkill
- persona-walkthroughSkill
- ponytailSkill
- prove-the-testSkill
- qa-crawlSkill
- qa-sweepSkill
- reflectSkill
- reviewSkill
- root-causeSkill
- scoutSkill
- second-opinionSkill
- ship-checkSkill
- skill-auditSkill
- skill-compareSkill
- spinoffSkill
- story-siteSkill
- tool-compareSkill
- ui-auditSkill
- ui-polishSkill
- usage-weekSkill
- ux-auditSkill
- validate-planSkill
- video-teardownSkill
- wait-whatSkill
- where-were-weSkill
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
Reviews can't be read right now.
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.

