handoff
Write a compact, decision-ready handoff so the next session (or the user) can continue without reconstructing the current one. Use when the session is ending, context is running low, the user asks for a handoff / 'pass the baton' / 'hand off', or a long-running operation needs a durable state checkpoint.
- License 许可
- MIT
- 最近更新
- 2026-11-11
- Stars
- ★ 4.1w
- Forks
- 3.6k
01 前言 Front Matter
- name
- handoff
- invocation
- model+user
- description
- Write a compact, decision-ready handoff so the next session (or the user) can continue without reconstructing the current one. Use when the session is ending, context is running low, the user asks for a handoff / 'pass the baton' / 'hand off', or a long-running operation needs a durable state checkpoint.
03 SKILL.md 正文
Handoff
Write a compact, decision-ready handoff so the next session (or the user) can continue without reconstructing the current one. Use when the session is ending, context is running low, the user asks for a handoff / "pass the baton" / "hand off", or a long-running operation needs a durable state checkpoint. The goal: the durable artifact survives, the context does not need to.
Invocation: model+user
When to use
- The user says "handoff", "hand off", "pass the baton", "takeover prompt", "write me a handoff", or the session is about to end / compact.
- A long operation (multi-turn, multi-workstream) has state that must survive context loss: commits, branches, PRs, CI, blockers, decisions.
- You are switching to a fresh session and want the new session to start from evidence instead of reconstructing the old one.
What to do
-
Gather the truth from tools, not memory. Run/collect:
git branch --show-current,git status --short,git log --oneline origin/<default>..HEAD(what is local-only),git log --oneline -5(recent context).- Live remote state where relevant (
gh pr list --state open,gh pr checks <n>,gh run list) — only what the user's operation actually depends on; do not pad the handoff with a full GitHub dump. - Any in-flight work: dirty files, uncommitted slices, partial worktrees, running background jobs/workers, queued CI.
-
Write a compact markdown handoff (aim under ~60 lines; the user may also ask for a "short text-only" variant — then aim under ~15 lines):
# Handoff — <operation/session name> — <date> - **State:** <one-line: what is done vs in-flight vs blocked> - **Landed/committed:** <exact SHAs + one-line what> - **Branches/PRs:** <names + states; which are ours vs community> - **CI:** <what is green, what is waiting, what is broken> - **Blockers:** <exact blocker + what would unblock> - **Decisions made:** <the WHY that a fresh session must not re-litigate> - **Next step:** <the single next action, one line> - **Continuation records:** <pointers to partial work that must be preserved (worktrees, uncommitted files, receipts)> -
Persist it. Always write
.codewhale/handoff.mdin the workspace — that is the only path the runtime reads back. On the next session's first turn it is injected as the "## Previous Session Relay" block (HANDOFF_RELATIVE_PATH,crates/engine/src/prompts.rs:85; loader atprompts.rs:301-315). A handoff written anywhere else is never picked up, so the next session starts cold no matter how good the note is.Optionally also write a human-discoverable copy:
- If the workspace has an ops/notes convention (e.g.
codewhale-ops/notes/with a living handoff file), update the living handoff's dated facts and snapshot, or create<topic>-handoff-<date>.mdnext to it. - Otherwise the repo root as
HANDOFF.mdordocs/handoff/<topic>-<date>.md. These are for people; nothing in the runtime reads them. Never overwrite someone else's uncommitted handoff without reading it first.
- If the workspace has an ops/notes convention (e.g.
-
Clear the way for the new session ("clears context"). A skill cannot delete the current context, but it can make the context disposable:
- Ensure nothing is left only in memory: dirty work is either committed (WIP is fine with a real body), stashed with a note, or recorded in the handoff with its exact location.
- Kill or record background work that would outlive the session (background jobs, sub-agents) — record what is still running and its task id.
- Close with the one-line "next step" so the fresh session has an unambiguous first action.
-
Deliver. Give the user the compact handoff text in your reply (the persisted file is the durable copy; the reply is the readable one).
Constraints
- Facts only from tool output; never invent SHAs, check states, or blockers.
- Keep claims narrower than evidence: distinguish landed/committed, verified locally, CI-verified, and pending.
- Preserve other people's uncommitted work: read before touching, archive before overwriting.
- The handoff is orientation, not law: tell the next session to refresh live state before acting on it.
- If the user asks for a "short text-only" handoff, give exactly that in the reply and skip the full markdown file unless asked.
04 同仓库更多 Skills
gh-find-prs
Survey the open Codewhale PR and issue queue read-only: fetch each item, check it against current code, and produce one coverage and disposition matrix with cited evidence and credit owed.
gh-file-issue
Use when filing a new Codewhale GitHub issue: turn a bug or idea into a well-formed, actionable issue with repro, acceptance criteria, labels, and milestone.
gh-close-issues
Close resolved Codewhale issues only after verifying the landed behavior: Refs #N per landing, Fixes #N only when the reporter's scenario was reproduced, closure at the release step or on the reporter's confirmation, always with a crediting comment.
gh-assign-issues
Use to assign GitHub issues to a milestone and/or owners in bulk, verifying each.
feedback
暂无简介
cw-slice
Use before writing code for any Codewhale feature, upgrade, or refactor: find the existing owner of the behavior, bound the change to one reviewable slice, and fix the evidence bar before you start.