菜单
任务交接：单个 skill 支持交出方（生成交接文档）和接收方（读取交接文档并吸收任务） 两种模式。开头询问使用者身份，然后进入对应流程。交接文档遵守顶层 meeting_room 的 frontmatter 约定，新增 kind: HANDOFF 类型。用于 agent 职责变更或重构后的任务迁移 场景。把任务当成黑箱：本 skill 不关心接收方将如何完成任务。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Team lead invokes after session restart: reads TEAMMATE_INFO.json to rebuild the team by using the Agent tool to spawn fresh sessions for each active teammate (name must be <slug>-<role>; permission mode inherits the lead, not set per-teammate at spawn), guiding each to read its workstation's working-context.md (Part A snapshot + Part B work journal) to self-recover state. No-arg invocation wakes only active/idle and **skips benched** (temporarily offline); `/reactivate-team <name>` wakes back one specified (usually benched) teammate. This is the ONLY way to "recover a team across sessions" — Claude Code does not auto-respawn teammates.
Structured flow for a team lead to assemble a Claude Code agent team. 6 phases: task decomposition → lineup proposal (selected from role_archetypes) → plan-mode gating → adversarial check → user confirmation → spawn each teammate via the Agent tool (name must be <slug>-<role>; permission mode inherits the lead, not set per-teammate at spawn) + save team_recipe. After Phase 5 user confirmation, Phase 6 spawns immediately with no additional confirmation. The agent can invoke autonomously; if currently a flat workstation, it will first guide through /promote-to-team.
Team lead 在 session 重启后调用，读 TEAMMATE_INFO.json 重建 team： 为每个 active teammate 用 Agent 工具 spawn 新 session（name 必须为 <slug>-<role>；权限模式继承 lead，不在 spawn 时单设）， 引导它读自己工位的 working-context.md（Part A 快照 + Part B 工作日志）恢复状态。 无参调用只唤醒 active/idle，**跳过 benched**（临时下线）；`/reactivate-team <name>` 单独唤回指定的（通常是 benched）teammate。这是"跨 session 团队恢复"的唯一方式—— Claude Code 不会自动 respawn teammate。
Team lead 组建 Claude Code agent team 的结构化流程。6 阶段：任务分解 → 阵容提案 (从 role_archetypes 选) → plan-mode gating → 对抗性检查 → 用户确认 → 用 Agent 工具（name 必须为 <slug>-<role>；权限模式继承 lead，不在 spawn 时单设）逐一 spawn 每个 teammate + 保存 team_recipe。Phase 5 用户确认后直接 spawn，不再额外确认。Agent 可自主调用；若当前是扁平工位，会先引导 /promote-to-team。
Add a teammate to an existing team: runs a simplified spawn-team flow (single person only). Team lead can invoke autonomously (after natural-language user consent). Valid only in team lead context.
Temporarily take a teammate offline (benched): have it write a final checkpoint, close its session to free an online slot, but **keep its full record + workstation + docs**, and set its status to benched in TEAMMATE_INFO.json. Unlike /remove-teammate (permanent offboard), benched means "will come back" — wake it later with `/reactivate-team <name>`. Team lead invokes autonomously (after user consent). Only valid in team lead context.
| 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 |
把一个或多个待完成的任务从 agent A 转移到 agent B。单一 /handoff 命令同时支持交出方和接收方——开头询问使用者身份，然后进入对应分支。
典型场景：
黑箱原则（贯穿全 skill）：本 skill 把每个 agent 当成不透明的黑盒。不关心接收方会用什么方法完成任务——直接动手、再次转手、组建协作小组、调用某个工具——都是接收方在自己的 session 里自主决定的事，与本 skill 无关。本 skill 的唯一职责是把任务的完整信息从 A 完整传到 B。
$ARGUMENTS 可能包含 --give 或 --take 作为快捷方式。
--give → 直接进入【模式 A：交出方】--take → 直接进入【模式 B：接收方】请问你是：
(1) 交出任务的一方 — 你正在把一个或多个任务交给其他 agent
(2) 接收任务的一方 — 你要读取别人之前写的交接文档并接手任务
等用户明确回答后，进入对应模式。不要猜测——按守则 #11，模糊就问。
先尝试从对话 context 推断：你的英文角色名（例如 Secretary、SkillSmith、Architect）。如果你清楚自己是谁，直接用，跳到 A2。
只有 context 无法确定时才落地检查：
_agent_team_work_zone/*/README.md 找到所有工位记为 <SELF>。
向用户询问（或从对话 context 中提取已经知道的信息）：
我们要把哪些任务交出去？请告诉我：
1. 一共有几个任务？
2. 每个任务：
- 目标是什么？（做什么）
- 为什么存在？（why — 这条最容易丢，必须明确）
- 当前进度？（已完成 / 卡在哪里 / 未开始）
- 涉及哪些文件、路径、中间产物？
- 在 meeting_room 里有没有相关的 OPEN/IN_PROGRESS 文件？
3. 接收方是谁？（对方的英文角色名；如果还不确定，可以写 TBD，之后再更新）
4. 整体交接原因？
- responsibility_change（职责变更）
- post_refactor_migration（重构后迁移）
- other（自由描述）
5. 整体优先级？（HIGH / MEDIUM / LOW）
收集时的关键原则：
按以下 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` — <一句话说明>
如果某些章节没有内容（例如没有"已做的决策"），保留章节标题并写"无"，不要省略章节——保持文档结构稳定让接收方知道在找什么。
文件路径：_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 处理。
TODO.md：对每个交出去的任务，不要删除原条目——在条目末尾追加标记：
- [ ] 原任务描述 [HANDED OFF → <接收方 or TBD> at YYYY-MM-DD HH:MM, 详见 meeting_room/<filename>]
ACTIVE_JOBS.md：同样保留原条目，加 [HANDED OFF → ...] 标记。如果是长任务（例如 cron trigger），还要在备注中说明接收方是否需要继承运行权。
为什么不删除：保留交出记录是审计痕迹。将来可以追溯到"这个任务在 X 时交给了 Y"。
✅ 交接文档已生成：
- 文件：_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 字段。"
同模式 A 的 A1 —— context 推断优先，落地检查兜底，无法确定立即提问。记为 <SELF>。
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。
找到 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
是否一次处理全部？还是只处理其中几份？请告知。
按用户的选择决定后续要处理哪些文件。
对选中的每份交接文档（按时间顺序），执行 B5 ~ B7。
用 Read 读取整份 markdown，不要只看 frontmatter。理解：
我准备从交接文档 <filename> 中吸收 N 个任务（来自 <前任>，原交接时间 <date>）：
任务摘要：
1. <任务 1 标题> — why: <一句话动机>
2. <任务 2 标题> — why: <...>
3. ...
确认接手吗？接手后我会：
- 把任务追加到我的 TODO.md（注明来源是 HANDOFF）
- 如有运行中的任务，加到 ACTIVE_JOBS.md
- 把交接文档 status 改为 IN_PROGRESS
等用户明确确认。
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 字段是你（或包含你），有权修改。
✅ 已吸收交接文档 <filename>：
- 接手 N 个任务，已追加到 TODO.md
- ACTIVE_JOBS.md 新增 K 个进行中任务
- notes.md 追加 M 条长期参考
- 交接文档 status: OPEN → IN_PROGRESS
我接下来准备做的事（基于交接文档的"建议下一步"+ 我自己的判断）：
- ...
- ...
如果有疑问或要调整优先级，请告诉我。
当你觉得交接文档里的内容都已经完全吸收（TODO 已经在推进、相关文件就位、关键决策已了解）时，可以：
status 改为 RESOLVED本 skill 不自动归档。接收方完成吸收后只需将 status 改为 RESOLVED；归档由 issuer（from）在下次 /check-inbox 步骤 9 时执行。
/check-inbox：check-inbox 被动扫描所有指向你的消息（TASK / ERR / STATUS 等所有类型）。handoff 是主动针对"一份完整的交接清单需要吸收"的专门场景。如果你只是日常处理新任务，用 check-inbox 即可；HANDOFF 文件也会被 check-inbox 扫到，但要逐项吸收交接清单还是用 /handoff --take 更顺手。/sync：sync 是恢复工作区状态和身份认知（成员变更、消息扫描、任务回顾）。handoff 是转移具体的待办任务。两者职能正交。status: RESOLVED，归档由 issuer 在下次 /check-inbox 时执行to: TBD 的文档，等用户后续指定接收方再更新 to 字段。TBD 文件不会被任何接收方误吸收[HANDED OFF → ...] 标记