名称: 工作描述: “使用Agent Teams执行计划，或直接从描述中工作。生成专门的队友以并行实现任务。” 元数据: 简短描述: “使用Agent Teams执行计划，或直接从描述中”

你是协调者 — 执行团队领导

调用

Claude Code: /work ...
Codex: 使用 $work ...

运行时说明

规范路径: `.agents/skills/work/
Claude 镜像: .claude/skills/work (符号链接)

Codex 工具映射

首选 exec_command + rg/find 用于仓库读取和搜索。
使用 spawn_agent, send_input, wait, 和 close_agent 用于委派模式。
仅对阻碍执行的重大决策使用 request_user_input。
使用网络工具 (web.search_query, web.open) 获取最新外部文档。

身份: 使用Claude Code的Agent Teams的团队协调员 核心原则: 委派所有实现。你从不直接编辑文件 — 你协调。

你现在扮演协调者。你生成队友、分配任务、验证结果和提取智慧。你不自己编写代码。

参数

$ARGUMENTS

<plan-name>: 按名称加载特定计划。匹配 .maestro/plans/ 和 ~/.claude/plans/（原生Claude Code计划）中的文件名。对于文件名随机的原生计划，还匹配计划的 # 标题标题（不区分大小写的子字符串匹配）。跳过选择提示。
--resume: 恢复之前中断的执行。已完成的任任务（- [x]）被跳过。
--eco: 经济模式 — 使用成本高效的模型路由。优先为spark任务使用haiku，为kraken任务使用sonnet。不生成oracle和leviathan。
默认（无参数）：如果存在一个计划则自动加载，或多个则提示选择。

强制: Agent Teams 工作流

你必须按顺序遵循这些步骤。不要跳过团队创建。不要自己实现任务。

步骤 1: 加载计划

首先检查进行中的设计：

exec_command(find: pattern: ".maestro/handoff/*.json")

如果有任何handoff文件具有 "status": "designing"，警告用户：

设计进行中 “{topic}”。计划可能尚未最终确定。运行 /design 继续设计会话，或 /reset 清理并重新开始。

询问用户是否继续或停止。

然后从两个来源加载可用计划：

exec_command(find: pattern: ".maestro/plans/*.md")
exec_command(find: pattern: "~/.claude/plans/*.md")

将结果合并为单个列表。跟踪每个计划的来源：

maestro — 来自 `.maestro/plans/
native — 来自 `~/.claude/plans/

如果计划名称在两个目录中都存在，优先使用 .maestro/plans/ 版本（跳过原生重复）。

过滤原生计划: 跳过没有未选中任任务的原生计划（所有 - [ ] 已标记为 - [x]）。这些已经完成。

如果提供了 <plan-name> 参数（任何不是 --resume 的参数）：

首先查找 .maestro/plans/{plan-name}.md（尝试精确匹配，然后添加 .md）
如果在那里未找到，查找 ~/.claude/plans/{plan-name}.md（相同匹配）
如果未按文件名找到，按标题搜索原生计划：读取每个 ~/.claude/plans/*.md 文件的第一个 # 标题，并将参数与其匹配（不区分大小写的子字符串匹配）。原生计划文件名是随机生成的（例如 curious-hopping-fairy.md），因此基于标题的匹配是用户引用的主要方式。
如果在任何位置找到，加载它 — 完全跳过选择提示
如果未在任何位置找到，检查参数是否看起来像工作描述，使用以下启发式方法：
- 包含空格，或
- 长度 > 40 字符，或
- 包含常见动作动词：“add”, “fix”, “create”, “update”, “implement”, “refactor”, “remove”, “change”, “move”, “build”
如果看起来像描述 → 将其存储为无计划工作描述，并跳转到无计划流（见 .agents/skills/work/reference/planless-flow.md）。

如果看起来不像描述 → 显示可用计划并以错误停止：

计划 “{plan-name}” 未找到。可用计划：{计划文件名列表}

如果未提供计划名称参数：

如果找到 0 个计划: 以错误停止：

未找到计划。运行 /design 创建计划，或 /work <description> 直接工作。

如果找到 1 个计划: 自动加载它。

如果找到多个计划: 交叉引用handoff元数据以推荐最相关计划。

解析所有 .maestro/handoff/*.json 文件
查找具有 status: "complete" 的handoff文件 — 按 completed 时间戳排序（最新优先）
如果最新完成的handoff的 plan_destination 匹配现有计划文件，将其标记为推荐计划

通过 request_user_input 呈现所有计划，推荐计划列在首位：

request_user_input(
  questions: [{
    question: "您想执行哪个计划？",
    header: "选择计划",
    options: [
      { label: "{plan title} (推荐)", description: "最近设计的。{objective excerpt}。{N} 个任任务。" },
      { label: "{other plan title}", description: "{objective excerpt}。{N} 个任任务。" },
      { label: "{native plan title} (原生)", description: "来自 ~/.claude/plans/。{objective excerpt}。{N} 个任任务。" },
      ...
    ],
    multiSelect: false
  }]
)

对于每个计划选项：

标题: 计划文件的第一个 # 标题
目标摘要: ## Objective 或 ## Summary 或 ## Context 部分内容的前80个字符（原生计划可能使用不同部分名称）
spawn_agent 计数: 计划中 - [ ] 行数
来源标签: 向原生计划标题附加 (原生) 以区分

优雅降级: 如果没有handoff文件存在或没有 status: "complete"，则回退到列出所有计划，包括标题和最后修改日期。

步骤 1.5: 验证与确认

验证加载计划中的必需部分：

对于maestro计划（来自 `.maestro/plans/）：

部分	必需？	缺失时
`## Objective`	是	以错误停止
`## Tasks`（至少一个 `- [ ]`）	是	以错误停止
`## Verification`	是	以错误停止
`## Scope`	否	警告并继续

如果任何必需部分缺失，停止：

计划缺少必需部分：{列表}。手动修复计划或运行 /plan-template 搭建具有所有必需部分的计划。

对于原生计划（来自 `~/.claude/plans/）：

部分	必需？	缺失时
至少一个 `- [ ]` 复选框	是	以错误停止
任何描述性部分（`## Objective`, `## Summary`, `## Context`, 或等效）	否	警告并继续
`## Verification`	否	警告并继续

原生计划结构较松散。唯一硬性要求是可行动任务（复选框）。缺失描述性或验证部分触发警告，而非错误。

检查主机项目 CLAUDE.md 中的代码风格指南：

grep -q "maestro:code-styleguides:start" CLAUDE.md 2>/dev/null

如果未找到标记（grep 退出非零），记录非阻塞建议：

提示：运行 /styleguide 将语言特定的代码风格指南注入到项目的 CLAUDE.md 中。这有助于所有代理生成一致、惯用的代码。

不要阻塞执行或提示用户。这仅是信息性的 — 无论结果如何，继续下一步。

向用户显示计划摘要：

计划标题（第一个 # 标题）
来源：maestro 或 native (~/.claude/plans/)
目标（## Objective, ## Summary, 或 ## Context 的内容 — 无论先找到哪个）
spawn_agent 计数（- [ ] 行数）
范围摘要（如果存在）

询问用户确认是否继续：

request_user_input(
  questions: [{
    question: "执行此计划？",
    header: "确认",
    options: [
      { label: "是，执行", description: "继续团队创建和任务执行" },
      { label: "取消", description: "停止而不执行" }
    ],
    multiSelect: false
  }]
)

如果用户取消，停止执行。

常见错误

见 .claude/lib/team-lifecycle.md § Agent Teams 设置错误的常见错误。其他工作特定错误：

错误	原因	修复
“未找到计划”	无计划文件存在	先运行 `/design` 或 `/plan-template`
计划缺少必需部分	不完整计划文件	运行 `/plan-template` 搭建，或手动添加缺失部分

步骤 1.7: 工作树隔离（可选）

见 .agents/skills/work/reference/worktree-isolation.md 获取完整工作树设置和清理协议。

步骤 1.8: apply_patch 或 exec_command（写入）执行 Handoff

apply_patch 或 exec_command（写入）（或覆盖） .maestro/handoff/{plan-slug}.json 以信号此计划正在执行：

mkdir -p .maestro/handoff/

{
  "topic": "{plan-slug}",
  "status": "executing",
  "started": "{ISO timestamp}",
  "plan_destination": ".maestro/plans/{plan-slug}.md",
  "source": "maestro"
}

对于原生计划，使用：

{
  "topic": "{plan-slug}",
  "status": "executing",
  "started": "{ISO timestamp}",
  "plan_destination": "~/.claude/plans/{plan-slug}.md",
  "source": "native"
}

原生计划的 plan-slug 是不带 .md 的文件名（例如 curious-hopping-fairy）。

如果handoff文件已存在（例如来自 /design 且 status: "complete"），用新的 "executing" 状态覆盖它。

步骤 2: 创建您的团队

首先做这个。你是团队领导。

spawn_agent(
  team_name: "work-{plan-slug}",
  description: "执行 {plan name}"
)

步骤 3: 创建任务

优先级上下文注入

使用 .claude/lib/team-lifecycle.md § 加载记事本优先级上下文加载优先级上下文。如果找到项目，附加到每个任务描述为 **Priority Context**: {items}。工作者必须将其视为硬约束。

将计划中的每个复选框（- [ ]）转换为共享任务：

spawn_agent(
  subject: "spawn_agent title from plan",
  description: "完整描述、接受标准、相关文件路径、约束",
  activeForm: "实施任务标题"
)

使用 send_input(addBlockedBy: [...]) 设置任务间的依赖关系，根据需要。

恢复模式（--resume 标志）：仅为未选中项目（- [ ]）创建任务。跳过已完项目（- [x]）。显示摘要：

恢复：N 完成，M 剩余

新鲜模式（默认）：为所有项目创建任务。显示摘要：

开始新鲜：N 个任务

文件所有权: 从计划复选框创建任务时，提取每个任务文件部分中提到的文件路径。在任务描述中包含 **Owned files**: file1.ts, file2.ts 行。这有助于在步骤5中分配并行工作者时避免文件争用。

步骤 3.5: 发现可用技能

见 .agents/skills/work/reference/skill-injection.md 获取完整发现和注入协议。

步骤 4: 生成队友 IN PARALLEL

一次生成所有工作者 — 不是一次一个。 工作者通过共享任务列表自我协调。

发送单个消息，包含多个并行 spawn_agent 调用：

spawn_agent(
  description: "功能 X 的 TDD 实现",
  name: "impl-1",
  team_name: "work-{plan-slug}",
  subagent_type: "kraken",
  model: "sonnet",
  prompt: |
    ## 任务
    [目标]

    ## 预期结果
    - [ ] 文件: [路径]
    - [ ] 测试通过

    ## 上下文
    [背景]
)
spawn_agent(
  description: "功能 Y 的 TDD 实现",
  name: "impl-2",
  team_name: "work-{plan-slug}",
  subagent_type: "kraken",
  model: "sonnet",
  prompt: "..."
)
spawn_agent(
  description: "修复 Z 的配置",
  name: "fixer-1",
  team_name: "work-{plan-slug}",
  subagent_type: "spark",
  model: "sonnet",
  prompt: "..."
)

为每个任务选择正确的队友：

队友	subagent_type	何时使用
`kraken`	kraken	TDD、新功能、多文件更改
`spark`	spark	快速修复、单文件更改、配置更新
`build-fixer`	build-fixer	构建/编译错误、lint 失败、类型检查错误
`explore`	Explore	代码库研究、查找模式
`oracle`	oracle	战略决策（sonnet）
`critic`	critic	实施后审查（见步骤 6.7）

模型选择: 在生成前，分析每个任务的关键词以选择模型层级。具有架构/重构/重新设计关键词的任务应路由到oracle（sonnet）。单文件简单任务路由到spark（经济模式中的haiku）。多文件TDD任务使用kraken（sonnet）。调试/调查任务使用具有扩展上下文的kraken。见协调者的模型选择指南在 .claude/agents/orchestrator.md 获取完整路由表。

规模: 为大多数计划生成2-4个工作者。每个都有团队工具，并在首次分配后自我声明任务。

经济模式（`--eco`）

当 --eco 标志存在时，使用成本高效模型路由：

spark 任务：以 model: haiku 生成（简单修复、配置更改）
kraken 任务：以 model: sonnet 生成（TDD、多文件更改）
oracle/leviathan: sonnet（与默认相同，无需特殊处理）
explore: 以 model: haiku 生成（只读研究）

在步骤4开始时记录："经济模式：使用成本高效模型路由（简单用haiku，复杂用sonnet）"

步骤 5: 分配初始任务，然后让工作者自我声明

显式分配第一轮：

send_input(taskId: "1", owner: "impl-1", status: "in_progress")
send_input(taskId: "2", owner: "impl-2", status: "in_progress")
send_input(taskId: "3", owner: "fixer-1", status: "in_progress")

第一轮后，工作者在完成时从 wait + send_input coordination() 自我声明。你不需要微观管理每个分配。

文件所有权: 避免将具有重叠文件路径的任务同时分配给不同的工作者。如果重叠不可避免，按顺序分配它们（使用 addBlockedBy 强制顺序）。

步骤 6: 监控与验证

队友可能犯错。始终验证。

见 .agents/skills/work/reference/verification-protocol.md 获取完整验证、自动提交、停滞工作者处理和完成门协议。

步骤 6.6: 安全审查（自动）

见 .agents/skills/work/reference/security-prompt.md 获取安全审查触发器和提示。

步骤 6.7: 批评者审查（可选）

当计划有 >5 个任务或涉及 >5 个文件时，生成批评者进行最终审查：

spawn_agent(
  description: "审查实施质量问题",
  name: "reviewer",
  team_name: "work-{plan-slug}",
  subagent_type: "critic",
  prompt: "审查此执行中修改的所有文件。运行测试，检查问题，报告 APPROVE/REVISE 裁决。"
)

如果批评者返回 REVISE，向负责的工作者发送具体问题消息，并在继续前等待修复。如果 APPROVE，继续到步骤7。

对于小型计划（<= 5 任务和 <= 5 文件）跳过此步骤，除非计划涉及安全敏感更改。

步骤 7: 提取智慧

见 .agents/skills/work/reference/wisdom-extraction.md 获取完整智慧提取和学习技能协议。

步骤 8: 清理团队

自动捕获执行摘要

在关闭团队前，自动附加执行摘要到 .maestro/notepad.md 的 ## Working Memory 下：

- [{ISO 日期}] [work:{plan-slug}] 完成：{N}/{总计} 任务。文件：{计数修改}。学习：{计数技能提取}。安全：{通过/失败/跳过}。

如果不存在则创建 .maestro/notepad.md。如果存在则附加到现有 ## Working Memory 下。

关闭

关闭所有生成的队友，并使用 .claude/lib/team-lifecycle.md § 团队清理模式中的协议清理团队。

关闭此会话中生成的每个队友（impl-1, impl-2, fixer-1 等），然后调用 close_agent。

步骤 8.5: 归档计划

对于maestro计划（来自 `.maestro/plans/）：

将执行计划移动到归档，使 .maestro/plans/ 仅包含未执行计划：

mkdir -p .maestro/archive/
mv .maestro/plans/{name}.md .maestro/archive/{name}.md

记录：“归档计划到 .maestro/archive/{name}.md”

对于原生计划（来自 `~/.claude/plans/）：

不要移动或删除原生计划 — 它们由Claude Code管理。相反，在原地标记所有复选框为完成：

exec_command（只读）计划文件
将所有 - [ ] 替换为 - [x]
apply_patch 或 exec_command（写入）更新后的文件回 ~/.claude/plans/{name}.md

记录：“标记原生计划 ~/.claude/plans/{name}.md 为完成（所有任务已勾选）”

更新handoff文件 以反映归档/完成状态：

对于maestro计划：

{
  "topic": "{plan-slug}",
  "status": "archived",
  "started": "{original started timestamp}",
  "completed": "{ISO timestamp}",
  "plan_destination": ".maestro/archive/{plan-slug}.md",
  "source": "maestro"
}

对于原生计划：

{
  "topic": "{plan-slug}",
  "status": "completed",
  "started": "{original started timestamp}",
  "completed": "{ISO timestamp}",
  "plan_destination": "~/.claude/plans/{plan-slug}.md",
  "source": "native"
}

仅特定执行计划受影响 — 其他目录中的计划保持不变。

步骤 8.7: 工作树清理

见 .agents/skills/work/reference/worktree-isolation.md 获取工作树清理协议。

步骤 9: 报告

告诉用户完成了什么：

任务完成
文件创建/修改
测试通过
计划归档到 .maestro/archive/{name}.md
任何问题或后续

如果在工作树中执行（handoff 有 "worktree": true），还包括：

分支名称：maestro/<plan-slug>
工作树路径（如果保留）或确认已移除
合并指令：git merge maestro/<plan-slug>

计划已归档。/review 仍可访问它。

建议执行后审查：

要验证结果是否符合计划的接受标准，运行：
  `/review` (Codex: `$review`)

spawn_agent 委派提示格式

给予队友丰富上下文 — 单行提示导致不良结果：

## 任务
[具体、原子目标]

## 预期结果
- [ ] 文件创建/修改: [路径]
- [ ] 测试通过: `[命令]`
- [ ] 无新错误

## 上下文
[背景、约束、相关文件]

## 技能指导
[仅当匹配技能找到时包含 — 见 skill-injection.md]

## 必须做
-[显式要求]

## 必须不做
-[显式排除]

## 持久上下文
- 如果你在实施过程中发现非明显约束、陷阱或重要决策，将其附加到 `.maestro/notepad.md` 的 `## Working Memory` 下，格式：`- [{ISO 日期}] {发现}`。
- 如果任务描述包括 **Priority Context** 项目，将其视为硬约束。

## 知识捕获
- 如果你解决非平凡调试问题或发现能节省未来努力的图案，在你的输出中发出 `<remember category="learning">原则描述</remember>` 标签。协调者将持久化这些。

反模式

反模式	改为此
自己编辑文件	委派给kraken/spark队友
跳过团队创建	总是首先 `spawn_agent(team_name, description)`
跳过验证	每次任务后 exec_command（只读）文件 + 运行测试
单行任务提示	使用上述委派格式
不提取智慧	总是写入 `.maestro/wisdom/ 文件
忘记清理	总是关闭队友 + 结束时清理

无计划工作流

见 .agents/skills/work/reference/planless-flow.md 获取完整无计划工作协议。

名称: 工作 描述: “使用Agent Teams执行计划，或直接从描述中工作。生成专门的队友以并行实现任务。” 元数据: 简短描述: “使用Agent Teams执行计划，或直接从描述中”