create-handoff
Create handoff document for transferring work to another session
pinned to #d07ff4bupdated 2 weeks ago
Ask your AI client: “install skills/create-handoff”.
Requires the metahub MCP server installed in your client. Set up MCP.
mh install skills/create-handoffmetahub onboarded this repo on the author's behalf.
If you own github.com/parcadei/Continuous-Claude-v3 on GitHub, claim the listing to take over publishing. Your claim preserves the existing eval history and badges; only the curator label is replaced with verified-publisher on your next publish.
Stars
3,858
Last commit
2 weeks ago
Latest release
published
- #agents
- #claude-code
- #claude-code-cli
- #claude-code-hooks
- #claude-code-mcp
- #claude-code-skills
- #claude-code-subagents
- #claude-skills
- #mcp
About this skill
Pulled from SKILL.md at publish time.
You are tasked with writing a handoff document to hand off your work to another agent in a new session. You will create a handoff document that is thorough, but also **concise**. The goal is to compact and summarize your context without losing any of the key details of what you're working on.
Evaluation report
WarningsAutomated checks the publisher passed at publish time — structure, docs, safety, and whether the artifact behaves as claimed.d07ff4b· 2 weeks ago
Documentation
41Description qualitywarn
9 words · 64 chars — skills use the description as their trigger; aim higher
Aim for 15+ words and include trigger phrases like “use this skill when …”.
README is present and substantial
45,577 chars · 22 sections · 38 code blocks
Tags / topics declared
9 total — agents, claude-code, claude-code-cli, claude-code-hooks, claude-code-mcp, claude-code-skills (+3)
README has usage / example sections
found: Quick Start · Installation · Installation (+1)
Homepage / docs URL declared
no homepage declared (registry will use the repo URL) — info-only, not blocking
Release history
1- releasecurrentd07ff4bwarn2 weeks ago
Contents
You are tasked with writing a handoff document to hand off your work to another agent in a new session. You will create a handoff document that is thorough, but also concise. The goal is to compact and summarize your context without losing any of the key details of what you're working on.
Process
1. Filepath & Metadata
Use the following information to understand how to create your document:
First, determine the session name from existing handoffs:
ls -td thoughts/shared/handoffs/*/ 2>/dev/null | head -1 | xargs basename
This returns the most recently modified handoff folder name (e.g., open-source-release). Use this as the handoff folder name.
If no handoffs exist, use general as the folder name.
Create your file under: thoughts/shared/handoffs/{session-name}/YYYY-MM-DD_HH-MM_description.yaml, where:
{session-name}is from existing handoffs (e.g.,open-source-release) orgeneralif none existYYYY-MM-DDis today's dateHH-MMis the current time in 24-hour format (no seconds needed)descriptionis a brief kebab-case description
Examples:
thoughts/shared/handoffs/open-source-release/2026-01-08_16-30_memory-system-fix.yamlthoughts/shared/handoffs/general/2026-01-08_16-30_bug-investigation.yaml
2. Write YAML handoff (~400 tokens vs ~2000 for markdown)
CRITICAL: Use EXACTLY this YAML format. Do NOT deviate or use alternative field names.
The goal: and now: fields are shown in the statusline - they MUST be named exactly this.
---
session: {session-name from ledger}
date: YYYY-MM-DD
status: complete|partial|blocked
outcome: SUCCEEDED|PARTIAL_PLUS|PARTIAL_MINUS|FAILED
---
goal: {What this session accomplished - shown in statusline}
now: {What next session should do first - shown in statusline}
test: {Command to verify this work, e.g., pytest tests/test_foo.py}
done_this_session:
- task: {First completed task}
files: [{file1.py}, {file2.py}]
- task: {Second completed task}
files: [{file3.py}]
blockers: [{any blocking issues}]
questions: [{unresolved questions for next session}]
decisions:
- {decision_name}: {rationale}
findings:
- {key_finding}: {details}
worked: [{approaches that worked}]
failed: [{approaches that failed and why}]
next:
- {First next step}
- {Second next step}
files:
created: [{new files}]
modified: [{changed files}]
Field guide:
goal:+now:- REQUIRED, shown in statuslinedone_this_session:- What was accomplished with file referencesdecisions:- Important choices and rationalefindings:- Key learningsworked:/failed:- What to repeat vs avoidnext:- Action items for next session
DO NOT use alternative field names like session_goal, objective, focus, current, etc.
The statusline parser looks for EXACTLY goal: and now: - nothing else works.
3. Mark Session Outcome (REQUIRED)
IMPORTANT: Before responding to the user, you MUST ask about the session outcome.
Use the AskUserQuestion tool with these exact options:
Question: "How did this session go?"
Options:
- SUCCEEDED: Task completed successfully
- PARTIAL_PLUS: Mostly done, minor issues remain
- PARTIAL_MINUS: Some progress, major issues remain
- FAILED: Task abandoned or blocked
After the user responds, index and mark the outcome:
# Mark the most recent handoff (works with PostgreSQL or SQLite)
# Use git root to find project, then opc/scripts/core/
PROJECT_ROOT=$(git rev-parse --show-toplevel 2>/dev/null || echo "${CLAUDE_PROJECT_DIR:-.}")
# First, index the handoff into the database
cd "$PROJECT_ROOT/opc" && uv run python scripts/core/artifact_index.py --file thoughts/shared/handoffs/{session_name}/{filename}.yaml
# Then mark the outcome
cd "$PROJECT_ROOT/opc" && uv run python scripts/core/artifact_mark.py --latest --outcome <USER_CHOICE>
IMPORTANT: Replace {session_name} and {filename} with the actual values from step 1.
These commands auto-detect the database (PostgreSQL if configured, SQLite fallback).
Note: If indexing fails, the marking step will show "Database marking was not available" - this is acceptable for the first handoff but indicates the indexing step was skipped.
4. Confirm completion
After marking the outcome, respond to the user:
Handoff created! Outcome marked as [OUTCOME].
Resume in a new session with:
/resume_handoff path/to/handoff.yaml
##. Additional Notes & Instructions
- more information, not less. This is a guideline that defines the minimum of what a handoff should be. Always feel free to include more information if necessary.
- be thorough and precise. include both top-level objectives, and lower-level details as necessary.
- avoid excessive code snippets. While a brief snippet to describe some key change is important, avoid large code blocks or diffs; do not include one unless it's necessary (e.g. pertains to an error you're debugging). Prefer using
/path/to/file.ext:linereferences that an agent can follow later when it's ready, e.g.packages/dashboard/src/app/dashboard/page.tsx:12-24
Reviews
No reviews yet. Be the first.
Related
React Doctor
Your agent writes bad React. This catches it
Planning With Files
Claude Code skill implementing Manus-style persistent markdown planning — the workflow pattern behind the $2B acquisition.
Frontend Slides
Create beautiful slides on the web using Claude's frontend skills
mh install skills/create-handoff