handoff

Write durable session handoff documents for resuming AI engineering work.

5|2|Updated Mar 20, 2026
One-click install
npx skills add https://github.com/dbc-oduffy/coordinator-claude --skill handoff-dbc-oduffy
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: handoff
Source: https://github.com/dbc-oduffy/coordinator-claude/tree/main/plugins/coordinator/skills/handoff
Command: npx skills add https://github.com/dbc-oduffy/coordinator-claude --skill handoff-dbc-oduffy

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill preserves an in-flight AI engineering session when context pressure, restarts, or blockers would otherwise make the next required action lose crucial state.

Core Features & Use Cases

  • Crash- and context-pressure handoffs: Writes a continuation handoff that captures where work stopped so a successor can reliably resume.
  • Continuation vs fork correctness: Enforces that handoffs are continuation-only, while forks use spinoff, preventing broken workstream semantics.
  • Multi-step durability and ordering: Creates the handoff artifact first, then performs lessons, doc alignment, plan updates, archival, and optional code-review consideration.
  • Recovery-flavor integrity sweeps: When marked as recovery, rescues and invalidates affected sibling handoffs to avoid propagating stale gates.
  • Next-session execution guardrails: Blocks incorrect usage for finished work (e.g., merge/commit/shipped scenarios) to prevent “handoff instead of ship-complete” failures.

Quick Start

Use the handoff skill to write a continuation handoff document that the next session can pick up after a restart or context-pressure stop.

Frequently Asked Questions about handoff

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I save in-flight AI engineering session state before a context pressure restart?

To save in-flight session state before a context pressure restart, you create a continuation handoff document with correct frontmatter schema. This artifact captures where work stopped, enabling a successor session to reliably resume the workstream.

What is the difference between a session handoff and a workstream fork?

A session handoff is strictly continuation-only, capturing mid-workstream state for resumption. A fork requires a spinoff process instead, enforcing continuation vs fork correctness to prevent broken workstream semantics.

How do I recover an AI coding session after a crash without losing TODO clusters?

You recover a coding session after a crash by marking the handoff as recovery to trigger an integrity sweep. This rescues and invalidates affected sibling handoffs, preventing the propagation of stale gates and preserving active TODO clusters.

When should I not use a session handoff document for engineering continuity?

You should not use a session handoff for finished work like merge, commit, or shipped scenarios. Next-session execution guardrails block this to prevent handoff instead of ship-complete failures and mislabeling shipped work.

What steps are required to write a durable handoff document for mid-workstream state transfer?

Writing a durable handoff document requires creating the tasks/handoffs/*.md file with correct frontmatter schema first. You then run alignment, archival, and optional code review trail steps to ensure multi-step durability and ordering.