| name | handoff |
| description | 任务交接：单个 skill 支持交出方（生成交接文档）和接收方（读取交接文档并吸收任务） 两种模式。开头询问使用者身份，然后进入对应流程。交接文档遵守顶层 meeting_room 的 frontmatter 约定，新增 kind: HANDOFF 类型。用于 agent 职责变更或重构后的任务迁移 场景。把任务当成黑箱：本 skill 不关心接收方将如何完成任务。
|
| argument-hint | [--give | --take] |
| disable-model-invocation | true |
| allowed-tools | Read Write Edit Glob Grep Bash |
任务交接 Handoff（双向单文件 skill）
把一个或多个待完成的任务从 agent A 转移到 agent B。单一 /handoff 命令同时支持交出方和接收方——开头询问使用者身份，然后进入对应分支。
典型场景：
- 职责变更：某个 agent 的职责范围变了，手上的任务需要交给其他 agent 继续
- 重构后迁移：老工作流中的 in-flight 任务需要交到新架构对应的 agent 手上
- 临时回避：交出方需要长期不在线，把任务暂时托付给他人
黑箱原则（贯穿全 skill）：本 skill 把每个 agent 当成不透明的黑盒。不关心接收方会用什么方法完成任务——直接动手、再次转手、组建协作小组、调用某个工具——都是接收方在自己的 session 里自主决定的事，与本 skill 无关。本 skill 的唯一职责是把任务的完整信息从 A 完整传到 B。
Step 0: 模式选择
$ARGUMENTS 可能包含 --give 或 --take 作为快捷方式。
- 若包含
--give → 直接进入【模式 A：交出方】
- 若包含
--take → 直接进入【模式 B：接收方】
- 若都没有 → 向用户提问：
请问你是：
(1) 交出任务的一方 — 你正在把一个或多个任务交给其他 agent
(2) 接收任务的一方 — 你要读取别人之前写的交接文档并接手任务
等用户明确回答后，进入对应模式。不要猜测——按守则 #11，模糊就问。
模式 A：交出方（生成交接文档）
A1. 身份确认（两级检查）
先尝试从对话 context 推断：你的英文角色名（例如 Secretary、SkillSmith、Architect）。如果你清楚自己是谁，直接用，跳到 A2。
只有 context 无法确定时才落地检查：
- Glob
_agent_team_work_zone/*/README.md 找到所有工位
- 读取 README 的"身份"章节，对照对话历史找到匹配的工位
- 若仍无法确定，立即停止并向用户提问
记为 <SELF>。
A2. 通过自然语言对话收集任务
向用户询问（或从对话 context 中提取已经知道的信息）：
我们要把哪些任务交出去？请告诉我：
1. 一共有几个任务？
2. 每个任务：
- 目标是什么？（做什么）
- 为什么存在？（why — 这条最容易丢，必须明确）
- 当前进度？（已完成 / 卡在哪里 / 未开始）
- 涉及哪些文件、路径、中间产物？
- 在 meeting_room 里有没有相关的 OPEN/IN_PROGRESS 文件？
3. 接收方是谁？（对方的英文角色名；如果还不确定，可以写 TBD，之后再更新）
4. 整体交接原因？
- responsibility_change（职责变更）
- post_refactor_migration（重构后迁移）
- other（自由描述）
5. 整体优先级？（HIGH / MEDIUM / LOW）
收集时的关键原则：
- why 必问：每个任务都要问出动机。任务的"做什么"容易写，"为什么"才是交接最容易丢失的部分
- 不要模板化：复杂任务的细节用自然语言对话收集，不要强求填表格
- 不假设接收方流程：不要问"接收方将如何做"——那是接收方的事
- 空任务清单友好提示：如果用户说"其实没什么要交接的"，就告诉他"那不需要 handoff，结束"
A3. 整理交接文档
按以下 7 个章节组织 markdown 文档：
# 任务交接：<SELF> → <接收方 or TBD>
## 1. 交接元数据
- 交出方：<SELF>
- 接收方：<接收方 or TBD>
- 日期：<YYYY-MM-DD HH:MM>
- 原因：<responsibility_change / post_refactor_migration / other>
- 任务数：<N>
- 整体优先级：<HIGH/MEDIUM/LOW>
## 2. 任务清单
### 任务 1：<简短标题>
- **目标**：<做什么>
- **Why**：<为什么这个任务存在 — 初始动机>
- **当前进度**：<已完成 X，卡在 Y，未开始 Z>
- **状态**：<未开始 / 进行中 / 部分完成 / 卡住>
- **相关文件**：
- `path/to/file1`
- `path/to/file2`
- **关键决策已做**：<如果有，写在这里；如果没有，写"无">
- **未决问题**：<等待接收方决定的事>
### 任务 2: ...
（同上结构）
## 3. 上下文快照
（任务本身之外，接收方需要知道的环境信息）
- 关键路径：<...>
- 常用命令：<...>
- 依赖与环境约定：<...>
- 外部资源链接：<...>
## 4. 已做的决策
（避免接收方重复讨论已经定过的事）
- 决策 1：<内容> — 原因 <...>
- 决策 2：<...>
## 5. 未决的问题
（等待接收方或用户决定的悬置问题）
- 问题 1：<...>
- 问题 2：<...>
## 6. 建议的下一步（非强制，接收方可自行判断）
- <step 1>
- <step 2>
> **本节是参考，不是命令**。接收方完全可以采用其他路径。
## 7. 相关文件引用
（meeting_room 里的相关 OPEN / IN_PROGRESS 文件路径，方便接收方顺藤摸瓜）
- `_agent_team_work_zone/meeting_room/<file_a>.md` — <一句话说明>
- `_agent_team_work_zone/meeting_room/<file_b>.md` — <一句话说明>
如果某些章节没有内容（例如没有"已做的决策"），保留章节标题并写"无"，不要省略章节——保持文档结构稳定让接收方知道在找什么。
A4. 写入 meeting_room
文件路径：_agent_team_work_zone/meeting_room/<SELF>_HANDOFF_<YYYYMMDD>_<HHMM>_<slug>.md
<slug> 是简短描述（用下划线连接，例如 auth_module_rewrite 或 failed_eval_followup）。
获取精确时间戳：用 Bash date '+%Y%m%d %H%M %Y-%m-%d %H:%M' 一次拿到文件名用的部分和 frontmatter 用的部分。
Frontmatter 必填：
---
kind: HANDOFF
status: OPEN
from: <SELF>
to: <接收方英文名 或 TBD>
date: YYYY-MM-DD HH:MM
priority: HIGH | MEDIUM | LOW
handoff_reason: responsibility_change | post_refactor_migration | other
task_count: <N>
---
kind: HANDOFF 是新增的类型前缀。其他类型 (TASK、ERR、STATUS、DONE、PROJECT_STATUS) 仍由原有 skill 处理。
A5. 同步更新交出方的工位文件
TODO.md：对每个交出去的任务，不要删除原条目——在条目末尾追加标记：
- [ ] 原任务描述 [HANDED OFF → <接收方 or TBD> at YYYY-MM-DD HH:MM, 详见 meeting_room/<filename>]
ACTIVE_JOBS.md：同样保留原条目，加 [HANDED OFF → ...] 标记。如果是长任务（例如 cron trigger），还要在备注中说明接收方是否需要继承运行权。
为什么不删除：保留交出记录是审计痕迹。将来可以追溯到"这个任务在 X 时交给了 Y"。
A6. 向用户汇报
✅ 交接文档已生成：
- 文件：_agent_team_work_zone/meeting_room/<filename>
- 交接 N 个任务给 <接收方>
- 交接原因：<reason>
- 优先级：<priority>
工位文件已同步：
- TODO.md：N 项加 [HANDED OFF] 标记
- ACTIVE_JOBS.md：M 项加 [HANDED OFF] 标记
下一步：
- 等接收方在他/她的 session 中运行 /handoff --take 来吸收任务
- 若 to 字段为 TBD，请尽快指定接收方（编辑 frontmatter 的 to 字段即可）
如果 to 是 TBD，额外提醒用户："交接文档已生成但没有指定接收方。等你确定了接收方，请告诉我，我会更新文件的 to 字段。"
模式 B：接收方（读取交接文档）
B1. 身份确认（两级检查）
同模式 A 的 A1 —— context 推断优先，落地检查兜底，无法确定立即提问。记为 <SELF>。
B2. 扫描 HANDOFF 文件
Glob: _agent_team_work_zone/meeting_room/*_HANDOFF_*.md
对每个匹配文件读取 frontmatter，过滤出：
kind: HANDOFFstatus: OPENto: <SELF>（单一收件人或列表中包含 <SELF>）
如果 to: TBD，跳过——TBD 还没分配，不应被任何人误吸收。
按 date 字段升序排序（最早交接的先处理）。
如果一份都没有：
没有等待你处理的交接文档。
（搜索范围：_agent_team_work_zone/meeting_room/ 中 to: <SELF> 且 status: OPEN 的 *_HANDOFF_* 文件）
然后结束 skill。
B3. 展示清单让用户选择
找到 N 份等待你处理的交接文档（按时间升序）：
1. <filename1> from: X, date: YYYY-MM-DD HH:MM, task_count: 3, priority: HIGH
原因：responsibility_change
2. <filename2> from: Y, date: YYYY-MM-DD HH:MM, task_count: 1, priority: MEDIUM
原因：post_refactor_migration
是否一次处理全部？还是只处理其中几份？请告知。
按用户的选择决定后续要处理哪些文件。
B4. 逐份读取并吸收
对选中的每份交接文档（按时间顺序），执行 B5 ~ B7。
B5. 完整读取交接文档
用 Read 读取整份 markdown，不要只看 frontmatter。理解：
- 任务清单（每个任务的 why、进度、相关文件）
- 上下文快照（路径、命令、约定）
- 已做的决策（不重复讨论）
- 未决的问题（哪些等你拿主意）
- 建议的下一步（参考，不强制）
- 相关文件引用（顺藤摸瓜的入口）
B6. 向用户确认接收
我准备从交接文档 <filename> 中吸收 N 个任务（来自 <前任>，原交接时间 <date>）：
任务摘要：
1. <任务 1 标题> — why: <一句话动机>
2. <任务 2 标题> — why: <...>
3. ...
确认接手吗？接手后我会：
- 把任务追加到我的 TODO.md（注明来源是 HANDOFF）
- 如有运行中的任务，加到 ACTIVE_JOBS.md
- 把交接文档 status 改为 IN_PROGRESS
等用户明确确认。
B7. 更新自己的工位文件 + 改交接文档 status
TODO.md：每个吸收的任务追加一条：
- [ ] [来自 HANDOFF, from <前任>, date: YYYY-MM-DD] <任务标题> — why: <动机> — 详见 meeting_room/<filename>
ACTIVE_JOBS.md：如果交接的是正在运行的任务（SLURM job、cron trigger 等），追加相关元数据。
notes.md：仅在交接文档里有长期复用价值的信息时（例如关键路径、命令约定）才追加。一次性信息不进 notes（守则 #10）。
修改交接文档：将 status 从 OPEN 改为 IN_PROGRESS。按守则 #8，to 字段是你（或包含你），有权修改。
B8. 向用户汇报
✅ 已吸收交接文档 <filename>：
- 接手 N 个任务，已追加到 TODO.md
- ACTIVE_JOBS.md 新增 K 个进行中任务
- notes.md 追加 M 条长期参考
- 交接文档 status: OPEN → IN_PROGRESS
我接下来准备做的事（基于交接文档的"建议下一步"+ 我自己的判断）：
- ...
- ...
如果有疑问或要调整优先级，请告诉我。
B9.（可选）任务全部消化后关闭交接文档
当你觉得交接文档里的内容都已经完全吸收（TODO 已经在推进、相关文件就位、关键决策已了解）时，可以：
- 在交接文档末尾追加一段"接收完成备注"（时间 + 接收人 + 摘要）
- 把
status 改为 RESOLVED
本 skill 不自动归档。接收方完成吸收后只需将 status 改为 RESOLVED；归档由 issuer（from）在下次 /check-inbox 步骤 9 时执行。
边界（与其他 skill 的关系）
- vs
/check-inbox：check-inbox 被动扫描所有指向你的消息（TASK / ERR / STATUS 等所有类型）。handoff 是主动针对"一份完整的交接清单需要吸收"的专门场景。如果你只是日常处理新任务，用 check-inbox 即可；HANDOFF 文件也会被 check-inbox 扫到，但要逐项吸收交接清单还是用 /handoff --take 更顺手。
- vs
/sync：sync 是恢复工作区状态和身份认知（成员变更、消息扫描、任务回顾）。handoff 是转移具体的待办任务。两者职能正交。
注意事项
- 黑箱原则：本 skill 不假设接收方将如何完成任务，也不在交接文档中嵌入实施细节。"接收方应该这样做"是越界
- why 必问：每个任务的"为什么存在"必须明确收集——这是最容易在交接中丢失的部分
- 不自动归档：本 skill 不归档完成的交接文件；接收方完成后只改
status: RESOLVED，归档由 issuer 在下次 /check-inbox 时执行
- TBD 支持：交出方可以先生成
to: TBD 的文档，等用户后续指定接收方再更新 to 字段。TBD 文件不会被任何接收方误吸收
- 保守拒绝假冒：如果交出方声称自己是 X 但身份核对失败 → 拒绝写入文件，按守则 #11 向用户提问
- 空清单：没有要交接的任务 → 友好告知"不需要 handoff"，不创建空文件
- 不要模板化复杂任务：本 skill 的大部分逻辑应该是"agent 通过自然语言对话与用户收集信息"——不要强求所有情况都套同一个表格
- 保留审计痕迹：交出方的 TODO/ACTIVE_JOBS 中的原条目永远不删除，只追加
[HANDED OFF → ...] 标记
