handoff
Use when the user asks to hand off the current session to a new chat, transfer context, or runs /handoff. Produces a self-contained handoff document in the OS temp directory (NOT in the repo) — works regardless of whether an active plan file exists. Always prints the absolute path so the user can paste it into the new chat.
Best use case
handoff is best used when you need a repeatable AI agent workflow instead of a one-off prompt.
Use when the user asks to hand off the current session to a new chat, transfer context, or runs /handoff. Produces a self-contained handoff document in the OS temp directory (NOT in the repo) — works regardless of whether an active plan file exists. Always prints the absolute path so the user can paste it into the new chat.
Teams using handoff should expect a more consistent output, faster repeated execution, less prompt rewriting.
When to use this skill
- You want a reusable workflow that can be run more than once with consistent structure.
When not to use this skill
- You only need a quick one-off answer and do not need a reusable workflow.
- You cannot install or maintain the underlying files, dependencies, or repository context.
Installation
Claude Code / Cursor / Codex
Manual Installation
- Download SKILL.md from GitHub
- Place it in
.claude/skills/handoff/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How handoff Compares
| Feature / Agent | handoff | Standard Approach |
|---|---|---|
| Platform Support | Not specified | Limited / Varies |
| Context Awareness | High | Baseline |
| Installation Complexity | Unknown | N/A |
Frequently Asked Questions
What does this skill do?
Use when the user asks to hand off the current session to a new chat, transfer context, or runs /handoff. Produces a self-contained handoff document in the OS temp directory (NOT in the repo) — works regardless of whether an active plan file exists. Always prints the absolute path so the user can paste it into the new chat.
Where can I find the source code?
You can find the source code on GitHub using the link provided at the top of the page.
SKILL.md Source
# Handoff — Self-Contained Context Transfer
Produce a handoff document a fresh agent session can pick up from **without re-investigating**. Lives in the OS temp directory — handoffs are short-lived by design; do NOT pollute the repo.
## The Principle
**Whatever is not in this doc, the new chat will not have.** Capture every load-bearing fact at the highest possible value: the user's goal, the current state, the decisions made, the constraints discovered, the file paths touched, the open questions. Do not assume the new agent can re-derive what was learned.
This holds **whether or not a plan / chronicle file exists.** A plan reference is OPTIONAL bonus; the handoff doc must stand alone.
## Step 1 — Compute the path
```
${TMPDIR:-/tmp}/claude-handoff-YYYY-MM-DD-HHMMSS-{slug}.md
```
- `YYYY-MM-DD-HHMMSS` = current timestamp (prevents collisions, time-orders multiple handoffs).
- `{slug}` = kebab-case topic of the current session. If the user passed `$ARGUMENTS`, derive the slug from there; otherwise infer from the work performed.
- The `claude-handoff-` prefix namespaces the file inside `$TMPDIR`.
Resolve `${TMPDIR:-/tmp}` via `Bash` (`echo "${TMPDIR:-/tmp}"`) so the path is correct on the user's OS (macOS uses `/var/folders/.../T/`, Linux usually `/tmp`).
## Step 2 — Write the doc
Use the `Write` tool with the full absolute path. Fill every section. Empty sections → write *"None"* (do NOT delete the header — the contract with the new agent depends on the section being present).
```markdown
# Handoff — YYYY-MM-DD HH:MM — {topic}
### Goal (in the user's own words)
[Quote the user's intent literally. Don't paraphrase into agent-speak.]
### Focus of the next session
[If the user passed `$ARGUMENTS`, restate that as the directive for the next agent. Otherwise: "continue from current state".]
### Current State
[File-anchored. What's working · what's broken · the next concrete step. Name files, line numbers, exact errors. Avoid abstract status.]
### Key Decisions
- **[Decision]** — chosen because [reason]. Alternative considered: [name], rejected because [reason].
### Important Context (gotchas · invariants · constraints)
- [Hidden invariants — things that look wrong but are right]
- [Subtle traps — things that look right but are subtly wrong]
- [Environment quirks — env vars, paths, tool versions that matter]
### Relevant Files
- `path/to/file.ext` — [what · why · which part is in scope]
### Open Questions / Unknowns
- [What wasn't resolved · what may surface · what the user still needs to decide]
- (or "None")
### Existing Artifacts (reference, do NOT duplicate)
- Plan: `docs/plans/NNNN__...md` — *(or "None")*
- Chronicle: `docs/chronicles/NNNN__...md` — *(or "None")*
- Other: PRDs · ADRs · GitHub issues · open PRs · key commits — *(path or URL each, or "None")*
### Suggested Skills for the New Agent
- `development-skills:<name>` — [why the next session should invoke this]
- ...
### Prompt for New Chat
```
Read the handoff at: {full absolute path written above}
Then continue from the "Current State" section.
```
```
## Step 3 — Announce the path prominently
After writing the file, print to chat in this format (so the user can copy-paste without hunting):
```
HANDOFF WRITTEN: {full absolute path}
Paste into your new chat:
Read the handoff at: {full absolute path}
```
One line, prominent, complete. The user pastes the second line; the new agent reads the file and has everything.
## Rules
- **Self-contained, not reference-only.** Even when a plan / chronicle file exists, write the Goal + Current State inline. The handoff doc must be readable as a standalone artifact. The plan is for depth; the handoff is for bootstrap.
- **Reference existing artifacts, do NOT duplicate.** Plans · chronicles · PRDs · ADRs · GitHub issues · commits — link by path or URL; restate ONLY a one-line summary of each in the handoff. Duplicating long content bloats the handoff and drifts from the source.
- **No fluff.** Every section is load-bearing. No "Summary" filler that restates the title. No filler openers.
- **User language over agent language.** Quote the user's own words for Goal and Open Questions where possible. The user's framing is signal.
- **File-anchored over abstract.** *"`src/api/cart.py:42-89` validation incomplete"* beats *"validation needs work"*. File paths and line numbers transfer; vague summaries don't.
- **Redact sensitive data.** API keys, passwords, OAuth tokens, PII, internal URLs that expose secrets → strip or replace with `[REDACTED]`. The handoff file lives in OS temp, but it may still be readable by other processes on the machine.
- **No invented files or facts.** If unsure whether a file or function exists, mark it as an Open Question rather than asserting it.
---
**Cross-link.** Principle 11 (Context is the constraint) in `../../shared/iron-rules.md`. The plan file (when one exists) is the canonical persistent record **within** a session; this handoff doc is the canonical transfer **across** sessions.Related Skills
using-development-skills
Use when starting any conversation - establishes how the development-skills plugin works and how to invoke its components on each platform (Claude Code, Codex). Read first.
update-reqs
Use when user wants to update requirements.in with latest PyPI versions while preserving version patterns
update-reqs-dev
Use when user wants to update requirements-dev.in with latest PyPI versions while preserving version patterns
update-precommit
Use when user wants to update .pre-commit-config.yaml hooks to their latest versions from GitHub
typescript-dev
TypeScript development. Use for TypeScript, Node.js, Express, Fastify, Zod, vitest, jest. Backend, CLI, libraries only — no frontend frameworks.
swift-dev
Swift development. Use for Swift, SwiftUI, UIKit, Vapor, SPM, XCTest, Combine.
staff-review
Use when user wants a code review, deep code review, or staff-level code review of a local branch, repo, directory, or file. Use when user says code review, deep code review, review this branch, review the branch X, review my code, staff review, review locally, or /staff-review.
roast-my-code
Use when user wants a brutally honest code roast, quality critique, or AI-readiness audit. Use when user says roast, roast my code, critique my code, tear apart my code, review quality, or AI-readiness check. Supports --fix flag to auto-fix CRITICAL and HIGH issues via core-dev workflow.
resolve-merge
Use when the user asks to resolve merge conflicts, fix a failed merge, rebase conflict, or run /resolve-merge. Use when git status shows UU/AA/DD conflicts, when there are <<<<<<< conflict markers, when git merge or git pull failed with CONFLICT, or when numbered docs/plans need renumbering after merge. Triggers on: merge conflict, conflict markers, both modified, git merge failed, rebase conflict, resolve conflicts.
python-dev
Python development. Use for Python, FastAPI, Pydantic, asyncpg, pytest, pandas, SQLAlchemy.
produce-feedback
Use when user wants to produce a factual chronicle of development-skills plugin interactions in the current conversation for later ingestion, or runs /produce-feedback. Pure record, no judgment.
java-dev
Java development. Use for Java, Spring Boot, Maven, Gradle, JPA, Hibernate.