一键导入
handoff
Create a curated session summary for continuation, for another agent to pick up.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Create a curated session summary for continuation, for another agent to pick up.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | handoff |
| description | Create a curated session summary for continuation, for another agent to pick up. |
| argument-hint | What will the next session be used for? |
| disable-model-invocation | true |
Create a detailed handoff summary of the conversation for continuing work in a new session.
A handoff requires a purpose — what the next agent should do. If no purpose is clear, ask the user before proceeding.
The handoff file includes an <analysis> section (written to the file, not chat; EVERYTHING handoff specific goes into the file; the entire analysis goes ONLY into the file - do not summarize in chat beforehand) where you:
The handoff should include:
Create a descriptive slug using keywords separated by dashes, lowercase. More detail is better.
Good examples:
workflow-design-handoff-pickup-commands-wikilinksgemini-pdf-extraction-prompt-testing-latex-handlingstripe-webhook-eu-withdrawal-edge-casesBad examples (too vague):
gemini-integrationstripe-fix# <Readable Summary>
<analysis>
[Thought process, ensuring all points are covered]
</analysis>
<plan>
## 1. Primary Request and Intent
[Detailed description of all user requests and intents]
## 2. Key Technical Concepts
- [Concept 1]
- [Concept 2]
## 3. Files and Code Sections
### [File Name 1]
- **Why important**: [Summary]
- **Changes made**: [Summary]
- **Code snippet**:
```language
[Code]
[Solved problems and ongoing troubleshooting]
[Tasks requested but not done]
[What was being worked on before handoff]
[Required next step aligned with purpose]
Task/Knowledge:
External docs:
Key code files:
path/to/file.py — why this file matterspath/to/other.py — related contextBias toward MUST READ. You have context that shaped your thinking — the next agent doesn't. When in doubt, mark it MUST READ.
If relevant, include a "suggested skills" section in the document, which suggests skills that the agent should invoke.
Do not duplicate content already captured in other artifacts (specs, plans, ADRs, issues, commits, diffs). Reference them by path or URL instead.
## Final Step
Write the handoff to: `agent/handoffs/YYYY-MM-DD-<slug>.md`
Then give the user the prompt to continue from there in a fresh session:
Continue from agent/handoffs/YYYY-MM-DD-.md — read it in full first.
Work a feature's ticket DAG in parallel — one orchestrator fans independent frontier tickets out to parallel worker agents and integrates them on the feature branch until the feature ships. Use when a ticketed feature has independent frontier tickets, the user says "dispatch" or wants tickets worked in parallel, or when another skill routes parallel frontier work here.
Which mx skill or flow fits the current situation — a router over the mx workflow.
Run commands in tmux whenever they run long or need eyes on them — anything expected to take more than ~30–60s (training runs, ML experiments, builds, servers), anything worth observing mid-run (progress logs, monitoring output), and anything interactive (sudo prompts, REPLs, wizards), locally or on a remote host. Always reach for this instead of a fire-and-forget Bash call in those cases — the human can attach and step in at any time.
Break a plan, spec, or the current conversation into a set of tracer-bullet tickets, each declaring its blocking edges, published per the tracker conventions — ticket files with blocked-by edges, or native blocking links on a real tracker.
Review and update Claude Code's auto-approved command allowlist based on Bash commands that triggered permission prompts in recent sessions.
Turn the current conversation into a spec and publish it to the project issue tracker — no interview, just synthesis of what you've already discussed.