菜单
检查顶层 meeting_room（所有 agent）+ 自己 team 的 roundtable（仅 team lead）中 指向自己的任务，按时间顺序处理：读取内容、更新工位文件、执行任务、更新状态。 同时作为 issuer 扫描自己发出的已完成文档并归档（步骤 9）。 严格遵守工作守则第 8 条（含 cc 字段语义）。归档权威实现；/archive-resolved 已 deprecated。
用 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 | check-inbox |
| description | 检查顶层 meeting_room（所有 agent）+ 自己 team 的 roundtable（仅 team lead）中 指向自己的任务，按时间顺序处理：读取内容、更新工位文件、执行任务、更新状态。 同时作为 issuer 扫描自己发出的已完成文档并归档（步骤 9）。 严格遵守工作守则第 8 条（含 cc 字段语义）。归档权威实现；/archive-resolved 已 deprecated。 |
| disable-model-invocation | true |
| allowed-tools | Read Glob Grep Bash Edit Write |
扫描 _agent_team_work_zone/meeting_room/（所有 agent）以及 _agent_team_work_zone/<your_team>/roundtable/（仅 team lead），找出所有指向当前 agent的任务，按时间顺序逐一处理。
重要 — 工作守则第 8 条（Meeting room / Roundtable 权限）：
- 归档权唯一归 issuer（
from）：只有from是你的文件你才能归档to字段明确指向你的文件：你有权修改status，但不可归档（由 issuer 归档）to: ALL的状态报告属于发布者，其他 agent 只读不改、不归档- 自己提交的报告 (
from是你) 可自行管理（包括在步骤 9 归档）cc字段：若你在cc（不在to），该文件只供你知晓——只读、不改 status、不归档- 违反此规则可能导致其他 agent 的工作状态丢失
先尝试从对话 context 推断：如果你清楚自己的角色和工位，跳到下一步。记为 <SELF>（英文名），并记下自己是 flat 还是 team_lead 以及对应的 <workstation> 路径。
只有 context 无法确定时，才执行落地检查：
_agent_team_work_zone/*/README.md 和 _agent_team_work_zone/*_team/README.md_team 结尾且含 roundtable/ → team_lead 模式flat 模式使用 Glob 列出 _agent_team_work_zone/meeting_room/*.md（排除 README.md）。
使用 Glob 列出 _agent_team_work_zone/<SELF>_team/roundtable/*.md（排除 README.md）。
对每个文件读取 frontmatter 提取 status、from、to、cc（若有）、kind（若有）、date、priority。
对每个文件判断归属：
| status | to 字段 | cc 字段 | 归属 |
|---|---|---|---|
| OPEN 或 IN_PROGRESS | <SELF> 或列表含 <SELF> | - | ✅ 收件箱 — 需要我处理 |
| OPEN 或 IN_PROGRESS | ALL | - | 📢 广播 — 作为信息参考，不主动执行 |
| OPEN 或 IN_PROGRESS | 其他 | <SELF> | 👁️ 抄送 — 只读，不改 status、不归档 |
| 任意 | 其他 agent（不含 <SELF>） | 不含 <SELF> | ❌ 无关，跳过 |
| RESOLVED | from=<SELF> | 任意 | ➡️ 进入步骤 9（issuer 归档队列） |
| RESOLVED | from=他人 | 任意 | 📋 已完成，等 issuer 归档——只读，不归档 |
团队版特殊：对 roundtable 文件，from 和 to 是 <team>/<role> 格式（例如 architect_team/tracker）；其中 architect_team/lead 等价于 <SELF> 当 <SELF> 是该 team 的 lead 时。
对"收件箱" + "抄送"文件按 date 字段升序排序（最早的先处理）。
时间顺序很重要：后发的任务可能依赖前面任务的结果。
按时间顺序对每个文件使用 Read 读取完整内容，理解任务要求：
对 IN_PROGRESS 老任务，额外搜索一次 meeting_room、roundtable 和 archive 中是否有相关的后续报告，判断老任务是否可以进入下一步。
在开始执行前，向用户输出一份"待处理清单"，请用户确认：
当前 agent: <SELF> (模式: flat/team_lead)
📬 收件箱 — 按时间顺序 (共 N 项):
🆕 新任务 (OPEN):
1. [TOP][HIGH] file1.md (from: X, date: 2026-04-11 10:00) — 标题/目的
2. [TEAM][MED] roundtable/file2.md (from: architect_team/tracker, kind: TRACKER_REPORT, date: 2026-04-11 14:30) — 摘要
⏳ 老任务 (IN_PROGRESS):
3. [TOP][HIGH] file3.md (from: Z, date: 2026-04-10 09:15) — 已完成 X，待处理 Y
👁️ 抄送给我 (只读):
4. [TOP] file4.md (from: W, to: V, cc: <SELF>, date: 2026-04-11 08:00) — 摘要
📢 广播 (to: ALL):
5. [TOP][LOW] file5.md (from: Secretary, date: 2026-04-11 08:00) — 项目公告
📁 我发出的已完成文档 (将在步骤 9 归档):
- [TOP] fileA.md (to: X, status: RESOLVED) — 将归档
- [TOP] fileB.md (to: [A,B,C], Completion Checklist: all done) — 将归档
是否按此顺序处理? 若需调整，请告知。
标记说明：
[TOP]= 顶层 meeting_room；[TEAM]= 自己 team 的 roundtable
用户确认后，在执行任务前先同步工位跟踪文件：
TODO.md：将新任务作为待办项追加（若尚未存在）ACTIVE_JOBS.md：对已开始执行的长任务登记notes.md：如任务涉及的路径/命令/配置有长期复用价值，追加（守则 #10）对每个待处理任务（抄送项跳过——只读）：
status 从 OPEN 更新为 IN_PROGRESS（仅当 to 明确指向 <SELF> 时）status 更新为 RESOLVED/check-inbox 步骤 9 时归档）扫描 _agent_team_work_zone/meeting_room/（以及 _agent_team_work_zone/<SELF>_team/roundtable/，若为 team lead）中 from: <SELF> 的文件，过滤出已完成的：
完成判定（两者任一满足即触发归档）：
status: RESOLVED- [x]，无剩余 - [ ]）Roundtable 已完成文档的归档协调（仅 team lead）：lead 扫自己的 roundtable 时，若发现 issuer（from）是当前 active teammate、已完成（status: RESOLVED 或 checklist 全勾）、但尚未归档的文档——lead 不直接归档（归档权属 issuer），而是有权立刻 SendMessage 通知该 issuer teammate 去归档，并给出确切路径："你在 roundtable 的 <path> 已 RESOLVED，请归档（mv 到 <SELF>_team/archive/）"。teammate 是 issuer、有归档权；lead 已给确切路径，它无需自己扫 roundtable（teammate 的 /check-inbox 本就不扫 roundtable，所以靠它自己永远发现不了——必须 lead 来推）。
为什么由 lead 发起：用户通常只和 team lead 对话、在 lead 的 session 里调
/check-inbox，所以 lead 是唯一会扫到 roundtable、发现"已完成却没归档"堆积的人；但归档动作仍由 issuer 执行，issuer-only 的权责不变。 issuer 已遣散时：若该 active teammate 其实已 offboard（不在active_teammates）→ 落到下面的「缺席兜底」：lead 核实状况后视情况 (a) 自行归档，或 (b) 把该文档的责任/所有权转移给某个在岗 agent，由其后续处理。
缺席兜底（仅 team lead）：额外列出 from 字段所指 agent 已不在 TEAMMATE_INFO.json 的 active_teammates 中的 RESOLVED 文件（issuer 已 offboard），标注"（缺席兜底，需确认）"，由 team lead 核实后手动归档或转移所有权。扁平工位无 TEAMMATE_INFO.json，缺席兜底扫描静默跳过。
可归档列表示例：
📁 作为 issuer — 可归档 (共 N 个):
[TOP]
- fileA.md (to: X, status: RESOLVED) — X 已完成
- fileB.md (to: [A,B,C], checklist: all done) — 所有人已完成
[TEAM] <SELF>_team/roundtable/
- fileC.md (from: <SELF>, status: RESOLVED) — 我发的，直接归档
📨 通知 issuer 归档 (active teammate 发到 roundtable 的已完成文档，归档权属它们):
- roundtable/fileE.md (from: drafter — active, RESOLVED) → SendMessage drafter 去归档
[缺席兜底 / 转移所有权]
- roundtable/fileD.md (from: OldAgent — 已不在注册表) → lead 核实后自行归档或转移所有权
确认：归档"可归档"N 个 + 通知 M 个 issuer 归档？
用户确认后执行移动（原位置决定归档位置）：
mv _agent_team_work_zone/meeting_room/<文件名> _agent_team_work_zone/archive/
mv _agent_team_work_zone/<SELF>_team/roundtable/<文件名> _agent_team_work_zone/<SELF>_team/archive/
若本次扫描无可归档文件，静默跳过（不输出空列表）。
收件箱处理完成 (执行人: <SELF>, 时间: YYYY-MM-DD HH:MM):
✅ 已完成 (status → RESOLVED):
- [TOP] file1.md — 结果摘要（归档由 issuer 执行）
- [TEAM] roundtable/file2.md — 结果摘要（归档由 issuer 执行）
📁 已归档（作为 issuer）:
- [TOP] fileA.md — to: X, 已完成
- [TEAM] roundtable/fileC.md — from: <SELF>, 已完成
📨 已通知 issuer 归档（active teammate 的 roundtable 已完成文档）:
- roundtable/fileE.md → 已 SendMessage drafter 去归档
🔄 进行中 (status: IN_PROGRESS):
- file3.md — 已推进至 X，下一步 Y
⏸️ 已暂停 (阻塞):
- file_stuck.md — 阻塞原因: ...，已提交 ERR
👁️ 已阅（抄送，未执行）:
- file4.md
📢 广播已阅:
- file5.md
工位文件更新: TODO.md (+N), ACTIVE_JOBS.md (+K)
date 升序处理to: ALL / cc 含 <SELF> 的文件绝不改 status、绝不归档（违者参见守则 #8）