| name | promote-to-team |
| description | 把扁平工位升级为 team lead：重命名目录为 <name>_team/、补齐 roundtable/archive/ team_recipes/teammates/ 子结构、改 README 加 rule 12 和 lead 专属章节。 agent 可自主调用——当扁平 agent 预见任务将变复杂时主动向用户建议。
|
| disable-model-invocation | false |
| allowed-tools | Read Write Edit Glob Bash |
/promote-to-team — 扁平工位升级为 Team Lead
身份前置检查
先从对话 context 推断：如果你已经清楚自己是 扁平工位（目录无 _team 后缀、无 roundtable/），直接进入下一步。
无法推断时才落地检查：
-
Glob _agent_team_work_zone/*/README.md 和 _agent_team_work_zone/*_team/README.md
-
找到对应当前对话的工位
-
如果是 *_team/ 且含 roundtable/ → 当前已经是 team lead，立即停止并警告：
⚠️ 你当前已经是 team lead（工位在 <path>）。
/promote-to-team 仅对扁平工位有效。
若你需要管理现有 team，试试 /evaluate-team、/add-teammate、/remove-teammate。
-
如果是扁平工位 → 继续
Phase 1: 向用户确认升级
Agent 在对话中用自然语言说明升级原因，请用户确认：
我预见到当前任务会变复杂（<原因列表，例如：需要并行调研多个假设 / 需要多种专业技能 /
单人完成会显著消耗 context >），建议我从扁平工位升级为 team lead 来处理。
升级后：
- 我的工位目录会从 _agent_team_work_zone/<english_name>/ 重命名为 _agent_team_work_zone/<english_name>_team/
- 我会获得 roundtable/、archive/、team_recipes/、teammates/ 这些 team 特有的子目录
- 我的 README 会加上 rule 12 (team lead 保留 context) 和 team 管理相关章节
- 我的 notes.md / TODO.md / ACTIVE_JOBS.md / COMPLETED_JOBS.md 完整保留，不丢任何工作历史
- 升级后我会用 /spawn-team 组建 team 来完成手头的复杂任务
你同意升级吗？
等用户明确同意后再进入 Phase 2。如果用户拒绝，就保持扁平继续死扛，但要在 notes.md 里记录一下用户的决定（以便未来复盘）。
Phase 2: 重命名工位目录
⚠️ <english_name> 必须是单 token（无连字符、无下划线）——它将成为本 team 的 slug（工位名去 _team 即得）。日后 spawn 的 teammate 名为 <slug>-<role>，idle hook 靠 ${name%%-*}_team 反推工位；slug 若含连字符，hook 会切错。如当前扁平工位名带连字符，借本次重命名一并改为单 token。
使用 git mv（若在 git repo 中）或 mv：
git mv _agent_team_work_zone/<english_name> _agent_team_work_zone/<english_name>_team
mv _agent_team_work_zone/<english_name> _agent_team_work_zone/<english_name>_team
此时：
README.md、notes.md、TODO.md、ACTIVE_JOBS.md、COMPLETED_JOBS.md 都保留，只是换了父目录- 没有丢任何文件
Phase 3: 补齐 team 特有子结构
在新的 _agent_team_work_zone/<english_name>_team/ 下创建：
roundtable/
README.md ← 部门内部沟通规则（参考顶层 meeting_room README 模板 + 说明部门隔离）
archive/
.gitkeep
team_recipes/
README.md ← 说明 team_recipes 是 /spawn-team 产出的审计记录，可复用
teammates/
README.md ← 说明每 teammate 的工位结构 + Tier 2 存档用途
TEAMMATE_INFO.json ← Team 注册表（初始空 active_teammates，详见下方）
TEAMMATE_INFO.json 初始化
在 team 工位根目录创建空的注册表：
{
"schema_version": 1,
"team_name": "<english_name>_team",
"lead_name": "<English Name>",
"updated_at": "<ISO8601 当前时间>",
"active_teammates": [],
"offboarded_teammates": []
}
这是 Rule 13 规定的 team 注册表，后续 /spawn-team / /add-teammate / /reactivate-team 会读写它，/checkpoint 会更新 teammate 自己那条的 last_checkpoint_at。Schema 详见 docs/teammate_info_schema.md。
roundtable/README.md 内容
# <English Name> Team — 部门内部会议室（Roundtable）
> 本目录是 **<English Name> team 内部**的沟通空间。只有本 team 的 lead 和 teammate 能在此发文。
> 跨 team / 跨工位通讯请发到 `../../meeting_room/`。
## Frontmatter 规范
部门内部文件使用 `<team>/<role>` 小写斜杠格式：
\`\`\`yaml
---
kind: TRACKER_REPORT | TASK | DONE | ERR | STATUS
status: OPEN | IN_PROGRESS | RESOLVED
from: <english_name>_team/<role> # 例如 architect_team/tracker
to: <english_name>_team/lead # 或其他 teammate
date: YYYY-MM-DD HH:MM
priority: HIGH | MEDIUM | LOW
---
\`\`\`
## 归档
部门内部 RESOLVED 文件归档到 `../archive/`（而非顶层 archive）。
遵守守则 #8：**归档权唯一归 issuer（`from`）**；`to` 指向你的文件只能改 status，不可归档。
team_recipes/README.md 内容
# Team Recipes — 团队组建审计记录
本目录保存 `/spawn-team` 产出的 team 组建 prompt 和任务上下文，作为：
- 审计记录（这个 team 是什么时候、为什么、怎么组建的）
- 可复用素材（下次遇到类似任务时，可以先查这里找参考）
每个 recipe 是一份 markdown，命名格式：`<YYYYMMDD_HHMM>_<slug>.md`。
详见 `/spawn-team` skill 的 Phase 6b。
teammates/README.md 内容
# Teammates — 团队自定义角色存档（Tier 2）
本目录存放**跨任务复用**的团队自定义 teammate 定义。
对照三层存储策略：
| Tier | 位置 | 场景 |
|---|---|---|
| 1 (默认) | inline 在 spawn prompt + team_recipes/ 审计 | 一次性任务 |
| **2 (本目录)** | `teammates/<role>.md` | 团队内多次复用同一自定义角色 |
| 3 (罕见) | `.claude/agents/<team>_<role>.md` 带 team 前缀 | 希望 Claude Code 全局自动加载 |
默认走 Tier 1。只有当 lead 发现自己反复用同一个定制 teammate 时，才把它固化到 Tier 2。
Tier 3 极少使用——需要全局引用时再考虑，并且**必须**用 team 前缀防冲突。
Phase 4: 更新工位 README
编辑 _agent_team_work_zone/<english_name>_team/README.md：
4a. 在身份章节补注模式
把原来的
身份
- Architect
- 负责项目架构设计与实验性改造...
改为
身份
- Architect (Team Lead)
- 负责项目架构设计与实验性改造...
- 模式：team lead（工位在
architect_team/，有 roundtable/ 等 team 特有子结构）
4b. 在工作守则章节补入 rule 12
如果原 README 只有 11 条守则，必须加上第 12 条（从 _agent_team_work_zone/README.md 复制）：
12. Team lead 节省 context window
如果你是 team lead，你的 context window 专用于协调——组建团队、读 teammate summary、
向用户汇报、跨 team 路由。你不做具体的编码/配置/测试等动手工作，那些交给
/spawn-team 产出的 teammate。收到动手任务时先判断：能用几条消息搞定且不烧 context，
还是需要组建 team。超过 1-2 个文件或需要并行调研的任务一律倾向于组建 team。
原则：宁可提前组建 team，不要事后抢救。
4c. 新增 "Team Management" 章节
在工作守则之后加：
## Team Management
作为 team lead，我使用以下 skill 管理我的 team：
- `/spawn-team` — 为新的复杂任务组建 3~5 人 team（我自主调用，用户自然语言同意后）
- `/evaluate-team` — 定期评估现有 team：谁在忙、谁闲、缺不缺角色、有没有冗余
- `/add-teammate` — 向现有 team 增加一个 teammate
- `/remove-teammate` — 让某个 teammate 下岗（交接后归档产出）
对持续监视长任务，我用 Claude Code 内置的 `/schedule` 启动 tracker（基于 `resources/agents/tracker.md`）：
- training 任务默认 12 小时一次
- eval 任务默认 4 小时一次
- 报告自动写到我 team 的 `roundtable/`
## 部门内部通讯
我的 team 内部沟通走 `architect_team/roundtable/`（参见该目录 README）。
跨 team 和跨工位的通讯走顶层 `_agent_team_work_zone/meeting_room/`。
`/check-inbox` 会同时扫两处。
## Context 保留原则（重申 Rule 12）
- 手头任务能一两条消息搞定 → 自己处理
- 超过 1-2 个文件或需要并行工作 → 组建 team
- 已经感觉 context 紧张 → 立刻把剩余工作打包给 teammate，不要死扛
4d. 替换扁平工位的"何时升级"章节
扁平工位 README 里的"何时升级为 team lead"章节现在不再适用（你已经是 team lead 了），删掉或替换为一句简短说明：
## 何时升级为 team lead
已升级 — 当前为 team lead 模式，详见上方 "Team Management"。
Phase 5: 更新成员表
编辑 _agent_team_work_zone/README.md 中的成员表，把对应行的 工位目录 列从 <name>/ 改为 <name>_team/，把 模式 列从 flat 改为 team。
Phase 6: 汇报完成
✅ 升级完成
工位: _agent_team_work_zone/<english_name>/ → _agent_team_work_zone/<english_name>_team/
新增子目录:
- roundtable/ (部门内部沟通)
- archive/ (部门内部归档)
- team_recipes/ (团队组建审计)
- teammates/ (Tier 2 自定义角色)
README 更新:
- 身份章节标注 "Team Lead" 模式
- 新增 rule 12 (如果之前缺失)
- 新增 "Team Management" 章节
- 移除扁平工位的"何时升级"章节
保留不动:
- notes.md
- TODO.md / ACTIVE_JOBS.md / COMPLETED_JOBS.md
成员表已更新：<english_name> 的模式列从 flat 改为 team
下一步：
你可以直接用自然语言描述需要这个 team 处理的任务，我会主动调用 /spawn-team
组建团队。
注意事项
- 只在扁平工位触发：前置检查阻止 team lead 误调用
- 保留工作历史：notes / TODO / ACTIVE_JOBS / COMPLETED_JOBS 完整保留
- git mv 优先：如果在 git repo 中用
git mv 保证历史
- 用户明确同意后再执行：不要自作主张升级
- 13 条工作守则必须完整：检查 README 中是否真的有 rule 12；若原扁平工位 README 只有 11 条（旧版），务必补齐
