agentleFS
AhmedMerzaAhmedMerza/agent-skills/skills/handover-save/SKILL.md

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
  1. Distinctive:

    If that file already exists, read it first and update it in place (preserve any checked-off progress) rather than clobbering it.

    line 20
  2. Distinctive:

    Read/grep) — stale anchors are the main way these docs rot.

    line 33

≈ “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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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 $ARGUMENTS if provided. Otherwise run git branch --show-current and derive a slug from the branch (strip feat/, 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-resume on 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>.

Download now (ZIP)

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.