القائمة
任务交接：单个 skill 支持交出方（生成交接文档）和接收方（读取交接文档并吸收任务） 两种模式。开头询问使用者身份，然后进入对应流程。交接文档遵守顶层 meeting_room 的 frontmatter 约定，新增 kind: HANDOFF 类型。用于 agent 职责变更或重构后的任务迁移 场景。把任务当成黑箱：本 skill 不关心接收方将如何完成任务。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| 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 → ...] 标记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.