auto-handoff plugin
A Claude Code plugin writes a handoff document while the session's prompt cache is still warm and costs stay low.
- 106 ★ on the repository
- Last commit
- MIT
Extended access
Why this level
- The skill writes a file in `docs/handoffs` and reads git state unattended, and the plugin runs the configured command by itself.
Install
- Works in
In your terminal, with SkillFoxx CLI
npx skillfoxx add plugins/auto-handoffDetects the agents on your machine, shows the access level and pins the version.
Other ways to install
Access and checks
How we reviewExtended accessThe tool runs code or makes network calls and only reads external data.
- The skill writes a file in `docs/handoffs` and reads git state unattended, and the plugin runs the configured command by itself.
This is third-party code. Review the repository files before installing.
What it does
Claude Code keeps session context in a prompt cache that lives an hour after the last request. A turn inside that hour reads the conversation at a reduced price, and after the cache expires the next turn pays in full. The plugin watches the gap: when a session has sat idle for 50 minutes it runs a handoff command while the cache is still warm. By default that is the bundled `/auto-handoff:handoff` skill. It runs `date` and `git status`, then writes one file `docs/handoffs/<timestamp>-<slug>.md` covering the goal, status, decisions, dead ends, files, verification commands, next steps and open questions. Nothing is committed. The skill pre-approves the tools it needs through `allowed-tools`, since nobody is there to answer a permission prompt.
Who it is for. People running long Claude Code sessions who often step away and later resume in a fresh session.
Good fit when
- A session with a large context sits idle and returning after an hour would be expensive.
- Work moves to a fresh session that needs a file with decisions and dead ends.
- The laptop stays awake while the session waits through a lunch or a meeting.
- A team has its own handoff skill and wants to run it on a timer.
Not a fit when
- The session uses the five-minute cache, as in usage overage: a 50-minute gap needs tuning.
- The plugin stops when you quit Claude Code because the timer lives in its process.
- You need a stable API: the plugin relies on an early-access hooks feature.
Example request
Configure auto-handoff for 40 idle minutes and show which file it will create after I leave the session.Limitations
The plugin is built on the function hooks API, which is early access and may change between Claude Code releases. Development and testing happened on version 2.1.289. The 50-minute default assumes the one-hour cache and the plugin cannot tell which cache a session has. The handoff itself is a turn like any other: each model request costs one cached read of the conversation and the turn keeps the cache warm for another hour. If the model reaches for a tool without a pre-approved permission, the turn waits at a prompt until you return. A laptop that slept through the wait wakes with a cold cache and the plugin skips that handoff.
How to disable. Disable the plugin through `/plugin` or remove it with `/plugin uninstall auto-handoff@auto-handoff`. Created files stay in `docs/handoffs`.
FAQ
How do I install auto-handoff?
Run `/plugin marketplace add obie/auto-handoff` and `/plugin install auto-handoff@auto-handoff`. The plugin loads at the next session start.
How do I change the idle time?
Open `/plugin configure auto-handoff` and set `minutes`. The default is 50 and for a five-minute cache the value must be much smaller.
Can I use my own skill?
Yes, the `command` option takes any slash command with arguments. It needs `allowed-tools` or a permission mode that lets it write without a prompt.
What happens after `/clear`?
A pending handoff is cancelled. A new idle clock starts after the next turn.
How many files are created per absence?
One. The plugin then stays quiet until you send a prompt or run a command yourself.
Discussion
No questions or reviews yet.
Related
PluginsA Claude Code plugin that replaces auto-compact: it writes a handoff brief, clears the session and continues from it
A Claude Code and Codex handoff plugin: a clean session with decisions and tasks kept, or history moved to the other client.
A Claude Code template: each session checks the last one's notes against git and GitHub, picks the day task and writes a handoff.
A Claude Code plugin that picks the model's effort level for every prompt and shows the prompt cache countdown
Table Skills: project-handoff
Table Skills (project-handoff)
The project-handoff skill saves goals, decisions and the next step to PROJECT_STATE.md for a fresh Codex or Claude Code session
Eight Claude Code skills for Obsidian: Granola notes, NotebookLM imports, TaskNotes tasks, recall of past sessions, chat export
README in short
The README covers timer rules, the bundled skill, two options and the limits. For development the repository is linked into `~/.claude/skills` and checked with `claude plugin validate` and `claude plugin test`.
README badge
Original SKILL.md
--- name: handoff description: Write a handoff document so a fresh session can pick up this work. Use when a session is about to end or go cold, before switching tasks, or when the user asks for a handoff. allowed-tools: Write(docs/handoffs/**), Edit(docs/handoffs/**), Bash(date *), Bash(git status *), Bash(mkdir -p docs/handoffs*) --- # Handoff Write one markdown file that lets a new session continue this work. Its reader starts with none of this conversation. This skill often runs unattended, after the session has sat idle with nobody at the keyboard. Ask no questions and wait for no confirmation. Write the file from what you already know. The steps below are pre-approved. Any other command or file write may raise a permission prompt that nobody is there to answer, and the handoff would never be written. Stay inside the steps. ## Steps 1. Run this one command, exactly as written: `date +%Y-%m-%d-%H%M; git status --short --branch`. Outside a git repository its second half fails, and that is fine. Skip any other investigation, because every extra tool call rereads the whole conversation. 2. Write the file with the Write tool to `docs/handoffs/<timestamp>-<slug>.md` under the project root. `<slug>` is two to five lowercase words naming the work, joined by hyphens. Write creates the directory when it is missing, so run no `mkdir`. 3. Reply with the file's path and one sentence on what it covers. Leave the file uncommitted. When the conversation holds no work worth resuming, say so in one sentence and write nothing. ## What goes in the file Use these headings in this order, and drop any that would be empty. - **Goal**: what the person is trying to get done, in their own terms. - **Status**: what is finished, what is half done, and what has not been started. - **Decisions**: each choice made and the reason for it, including options the person ruled out. - **Dead ends**: what was tried and failed, so the next session skips it. - **Files**: the paths that matter, each with a phrase on why. - **Verification**: the commands that show whether the work is working, with their last known result. - **Next steps**: an ordered list whose first item is specific enough to start on at once. - **Open questions**: what only the person can answer. Use exact paths, command lines, identifiers and error text. Record any standing instructions the person gave about how to work, since the next session will not have heard them.