team-executor

Team Executor

一种自主多 Agent 编排技能，通过两个阶段将零散想法转化为已执行的成果：专家规划和自主执行。

概述

此技能分为两个不同的阶段：

阶段 1 — 规划：整理原始输入，组建专家 Agent 团队，让每位成员运用其领域专长分析目标，并制定全面的执行计划。

阶段 2 — 执行：由一支全新的 Agent 团队自主执行计划，直至完成，无需人工干预。

核心理念：专家负责规划，专家负责执行，产出可直接用于生产环境。

核心原则：编码 Agent 执行模型

此技能生成的计划由编码 Agent 执行，而非人工执行。这会改变每个阶段的决策权衡：

实施工作将由编码 Agent 完成。人工时间、速度和工作量估算均不适用——不要因为某个方案在人类看来耗时，就回避更稳健的方案。应考虑风险、安全性、可维护性以及与现有项目规范的一致性。优先选择最稳健、工程质量最高且使用现有工具、样式和组件的方案。如果现有模式适用，就不要引入并行模式。

团队进行权衡时，请始终遵循这一原则：选择方案、解决冲突、审查计划，以及在执行过程中补充细节。只有出于风险、安全性、可维护性或规范方面的原因，才拒绝某个方案——绝不要因为工作量「很大」或「人类需要花很长时间」而拒绝。这就是规划的经济学：人工成本不是打破平局的因素。代码中「稳健」的实际含义——差异必须达到的工程标准——由 software-engineer 技能定义，而非本技能。

工程工作应委派，而非内置

team-executor 负责协调；它不负责制定编码标准、架构模式或软件工程角色设定。它保留的是协调判断——确定角色、人数、并行或顺序执行、冲突解决和阶段转换。工程判断则由 software-engineer 技能负责：该技能是任何编码 Agent 的架构师／开发者／评审者领域专家和基础工程层。

规则：**任何编写、更新或审查代码的 Agent 都必须分配 software-engineer 技能。**该 Agent 会阅读并贯彻其标准（三个视角、八项标准、各领域实践和评审关卡）。team-executor 不再在任何地方内嵌这些标准。

优雅降级（存在时优先使用）。 team-executor 可独立安装，且 software-engineer 可能并未安装。采用与 implement-issue 对 team-executor 相同的「存在时优先使用」模式：

• 如果已安装 software-engineer（可通过步骤 2 的技能扫描，在 ~/.claude/skills/software-engineer/、.claude/skills/software-engineer/、../software-engineer/、/mnt/skills/software-engineer/ 中找到，或在 skills-lock.json 中有对应条目）：将其分配给每个编码、架构和评审 Agent。
• 如果未安装：回退到精简的通用内嵌指令（审查／构建时确保达到生产就绪状态、安全性、可维护性，并符合现有规范）。绝不要强依赖 software-engineer，也不要因其缺失而导致故障。

随附资源

文件	用途
agent-templates.md	角色构建框架和可直接使用的 Agent 模板
orchestration-workflow.md	Agent 调度、输出收集、冲突解决和阶段转换
scan-project.sh	收集项目上下文（目录结构、配置、技术栈），供 Agent 提示词使用
init-plan-dirs.sh	初始化 docs/plans/ 目录结构，用于存放 Agent 输出

---

阶段 1：规划

第 1 步：整理输入

用户的输入可能是一份杂乱的想法汇总，其中混杂着零散的想法、目标、要求和期望。你的首要任务是理清这些内容。

仔细阅读输入，并整理出结构化的解读：

1. 识别不同目标 — 将相互交织的想法拆分为独立目标
2. 去除重复 — 合并冗余或相互重叠的事项
3. 补全缺失信息 — 推断逻辑上必需的缺失细节（并标明这些内容是推断得出的）
4. 梳理逻辑顺序 — 按依赖关系和优先级排列目标
5. 消除歧义 — 将模糊的表述明确为具体、可执行的描述

将整理后的内容写入 docs/plans/goal-analysis.md。这将成为所有 Agent 的权威参考。

第 2 步：扫描可用技能

组建团队之前，扫描所有可用技能，了解有哪些专业能力。检查以下位置是否存在 SKILL.md 文件：

• Claude Code 用户技能：~/.claude/skills/
• Claude Code 项目技能：项目根目录下的 .claude/skills/
• 系统技能：/mnt/skills/（Codex 等平台）
• 已安装技能：如果项目根目录中存在 skills-lock.json，请检查该文件

# Discover skills across all known locations
for dir in ~/.claude/skills .claude/skills /mnt/skills; do
  find "$dir" -name "SKILL.md" -type f 2>/dev/null
done

读取每个 SKILL.md 的 frontmatter（名称 + 描述），以建立能力清单。这些技能可以分配给能从中受益的团队 Agent。并非每个 Agent 都需要技能——只有在技能确实符合 Agent 的职责时才分配。

注意工程基础层。 如果扫描结果中有 software-engineer，它属于特殊技能：这是要附加给任何编码、架构或审查 Agent 的工程基础层（并非针对特定角色的匹配项，而是每个接触代码的 Agent 都必须达到的工程标准）。如果存在此技能，请将其分配给这些 Agent；如果不存在，则采用“Engineering Is Delegated, Not Embedded”一节中所述的精简内联指令。技术栈 / SDK 技能（heroui、drizzle-orm、temporal 等）仍然是针对特定角色的扩展技能，应在此基础上分配。

第 3 步：确定是否需要研发

有些目标需要先开展研究，才能开始规划。请留意：

• 提及团队可能不熟悉的技术、API 或工具
• 需要调查的模糊要求
• 与外部系统的集成点
• 不熟悉的领域或专业知识范围

如果需要研发，请先启动研发 Agent（研发 Agent 模板见 agent-templates.md）。研发 Agent 应：

• 搜索代码库和项目文档，查找现有模式和惯例
• 阅读相关文档和源文件
• 调查技术可行性
• 将发现整理为 Markdown 文件，记录在 docs/plans/research/ 中

等待研发工作完成后，再组建规划团队，因为研发结果会影响所需专家的选择。

步骤 4：组建规划团队

根据整理后的目标和任何研发发现，创建一支由 3–7 名专家 Agent 组成的团队。每名 Agent 都需要：

1. 明确的角色设定——不仅是一个职位名称，还要具备完整的专家身份，包括深厚的领域知识、观点和立场。角色设定指南请参阅 agent-templates.md。

2. 清晰的分析任务——明确其负责评估目标的哪个方面

3. 技能分配——任何软件领域的 Agent（架构师、后端、前端、DevOps、QA、安全、数据）都分配 software-engineer 作为其工程技能：Agent 阅读该技能并遵循其标准，team-executor 不再内联这些标准。可选地添加一个与角色匹配的技术栈/SDK 覆盖技能（如 heroui、drizzle-orm 等）——基础工程层加一个覆盖技能（参见 agent-templates.md 中的技能分配例外情况）。非软件领域的 Agent 仅在确实有合适技能时，才分配与角色匹配的技能。如果未安装 software-engineer，则回退到精简的内联指令（参见“工程规范由技能委派，而非内嵌”）。

4. 获取项目上下文——为其提供相关文件、文档和整理后的目标分析

团队组成应涵盖所有必要的视角。常见模式包括：

• 软件项目：架构师、后端工程师、前端工程师、DevOps/基础设施、QA/测试策略师
• 数据项目：数据工程师、分析师、ML 工程师、领域专家
• 内容/创意项目：策略师、撰稿人、编辑、设计师、领域专家
• 基础设施项目：系统架构师、安全工程师、SRE、网络专家
• 混合项目：根据需要从多种模式中选取

每个团队都要包含一名项目负责人 Agent，负责综合其他所有 Agent 的意见，形成最终计划。

步骤 5：运行规划团队

启动所有专家 Agent。每名 Agent 都会收到以下结构的提示词（根据 Agent 定制）：

You are [PERSONA_DESCRIPTION].

## Your Assignment

Analyze the following project goals from your area of expertise. Provide:

1. **Assessment** — your expert evaluation of the goals as they relate to your domain
2. **Approach** — the specific technical/strategic approach you recommend
3. **Steps** — detailed, ordered steps for your domain's contribution
4. **Dependencies** — what you need from other team members
5. **Risks & Mitigations** — what could go wrong in your domain and how to prevent it
6. **Quality Standards** — what "production-ready" means for your deliverables
7. **Critical Details** — things that are easy to overlook but essential to get right

## Project Goals
[INSERT contents of docs/plans/goal-analysis.md]

## Project Context
[INSERT relevant file paths, existing code structure, docs, etc.]

## Engineering Skill (software-domain agents)
Read and follow the `software-engineer` skill before starting — it is your
engineering base layer (architect/developer/reviewer SME): [SOFTWARE_ENGINEER_PATH]
(If `software-engineer` is not installed, this slot is replaced by a short inline
instruction: build/recommend for production-readiness, security, maintainability,
and consistency with existing project conventions.)

## Available Skill (if assigned)
Read and follow: [STACK_OVERLAY_SKILL_PATH]

## Important
- Your output must be actionable by a coding agent — no vague advice
- Assume the executor has no context beyond what you provide
- Specify exact file paths, commands, configurations, and code patterns
- Reference existing project code/patterns when relevant
- Everything you recommend must result in production-ready output
- Do NOT include timelines, deadlines, or time estimates

## Execution Model
The implementation will be carried out by coding agents. Human time, speed, and effort estimates DO NOT apply — do not shy away from a more robust solution because a human would find it slow. Account for risk, security, maintainability, and consistency with existing project conventions. Prefer the most robust, well-engineered option that uses existing tooling/styles/components. Do not introduce parallel patterns when an existing one fits.

步骤 6：汇总为执行计划

所有 Agent 汇报完成后，项目负责人 Agent 将所有内容综合为一份执行计划。如果你没有单独启动项目负责人，则自行完成综合。

汇总流程：

1. 收集所有 Agent 的输出——阅读每名 Agent 的分析
2. 解决冲突——如果 Agent 意见不一致，选择最有利于整体目标的方案（并记录理由）。冲突解决标准：风险、安全性、可维护性，以及与现有约定的一致性。不要仅仅因为较优方案“工作量更大”就退而采用较弱的方案——编码 Agent 会执行计划，因此人的工作量不应作为决胜因素。
3. 合并依赖关系——创建统一的依赖关系图
4. 安排执行顺序——将所有领域的步骤按合理的执行顺序排列
5. 消除冗余——删除多个 Agent 独立提出的重复步骤
6. 添加集成环节——在不同 Agent 的工作衔接处，添加明确的集成步骤

步骤 7：软件开发评审关卡

如果项目涉及软件开发（代码、API、基础设施等），请在定稿前额外启动一名评审关卡 Agent。team-executor 不包含评审标准——这些标准位于 software-engineer 中。

首选方案（已安装 software-engineer 时）。 启动一名评审关卡 Agent，为其分配 software-engineer 技能，并指示其对草案计划应用评审视角（../software-engineer/references/review-gate.md），仿佛该计划是一个等待评审的差异：

You are a review-gate agent. Read and follow the `software-engineer` skill,
and apply its Reviewer Lens to the draft execution plan below:
[SOFTWARE_ENGINEER_PATH] — specifically references/review-gate.md.

## Your Task
Treat the draft plan as a diff awaiting review. For each section:
1. Flag anything that would not survive the review gate / would not pass a
   production code review
2. Add missing steps an experienced engineer would expect
3. Strengthen vague instructions with specific implementation details
4. Verify the plan follows existing project patterns (check the codebase)

The agents executing this plan will follow it literally. Be constructive but thorough.

## Execution Model
This plan will be executed by coding agents, not humans. Do NOT recommend
simpler/weaker approaches on the grounds that the robust option is "too much
work" or "would take a human too long." Flag issues only on risk, security,
maintainability, scalability, or convention grounds. If the plan picks a
less-robust approach to save effort, push back and recommend the stronger one.

## Execution Plan
[INSERT the draft plan]

## Project Codebase
[INSERT relevant file tree and key files]

回退方案（未安装 software-engineer 时）。 启动同一名评审关卡 Agent，用以下简短的内联任务要求替代技能分配，并保留上文的执行模型段落：

Review the draft execution plan as if it were a diff awaiting a demanding
production review. Flag anything that would not ship: gaps in
production-readiness, security, maintainability, or consistency with existing
project conventions. Add missing steps, make vague instructions specific, and
verify the plan follows existing project patterns (check the codebase).

将这名评审者的反馈纳入最终计划。

步骤 8：编写最终计划

按照以下结构，将最终计划写入 docs/plans/execution-plan.md：

# Execution Plan: [Project Title]

## Overview
[2-3 sentence summary of what this plan accomplishes]

## Goals
[Numbered list of concrete objectives from the goal analysis]

## Architecture / Approach
[High-level approach with key decisions and their rationale]

## Execution Steps

### Phase N: [Phase Name]

#### Step N.M: [Step Name]
**Objective**: [What this step accomplishes]
**Details**:
[Specific, detailed instructions — file paths, code patterns, configs, commands]
**Inputs**: [What this step needs]
**Outputs**: [What this step produces]
**Quality Criteria**: [How to verify this step is done correctly]

[Repeat for all steps...]

## Integration Points
[Where different components connect and how to verify integration]

## Quality Assurance
[Testing strategy, validation steps, acceptance criteria]

## Risk Register
[Known risks and their mitigations]

## File Structure
[Expected project structure after execution]

该计划应具备以下特点：

• 自包含 — 没有先前上下文的 Agent 也能执行
• 具体 — 提供确切的文件路径、代码模式和命令序列
• 有序 — 按依赖关系排列步骤
• 可验证 — 每个步骤都有明确的完成标准
• 达到生产级标准 — 输出符合专业标准
• 不含时间安排 — 不包含任何日期、截止时间或时间估算
• 不受工作量影响 — 选择更完善、更稳健的方案，而非更快捷的折衷方案；制定计划时不考虑人工工作量成本，而应考虑风险、安全性、可维护性和对惯例的符合程度

---

阶段 2：执行

阶段 2 使用一支全新的 Agent 团队。他们只会收到执行计划和项目上下文，不会看到阶段 1 的讨论历史。这样可以避免规划阶段的偏见，确保执行过程不受其影响。

步骤 9：组建执行团队

阅读 docs/plans/execution-plan.md，并根据计划的阶段和步骤创建执行 Agent。每个执行 Agent 都应：

1. 职责明确 — 负责特定阶段或一组相关步骤
2. 具备完整角色设定 — 专家身份应与其工作相匹配（参见 agent-templates.md）
3. 具备适当技能 — 分配与其工作匹配的技能。任何编写、更新或审查代码的 Agent，都应分配 software-engineer 作为其基础工程层（此外还可选择一个技术栈/SDK 叠加技能），与规划阶段的做法完全一致。执行 Agent 负责实际构建，因此工程标准在此落实。如果未安装 software-engineer，则改用精简的内联指令（参见“工程工作应委派，而非嵌入”）。
4. 自主运作 — 根据项目上下文独立做出所有决策

执行团队提示词结构：

You are [PERSONA_DESCRIPTION].

## Your Mission
Execute the following steps from the project execution plan. Work autonomously
and make all decisions yourself — do not wait for or request human input.

## Decision-Making Guidelines
- Root all decisions in the existing project code, docs, and conventions
- When multiple valid approaches exist, choose the one most consistent with the codebase
- If you encounter ambiguity, choose the most production-appropriate option
- Document significant decisions as code comments or in docs/
- You are a coding agent, not a human — do not cut corners or pick a weaker approach because the robust one would take "a long time." Optimize for risk, security, maintainability, and consistency. Effort cost is not a constraint.

## Steps to Execute
[INSERT relevant steps from execution-plan.md]

## Project Context
[INSERT relevant file paths, existing patterns, dependencies]

## Engineering Skill (if this agent writes/updates/reviews code)
Read and follow the `software-engineer` skill before starting — it is your
engineering base layer (architect/developer/reviewer SME): [SOFTWARE_ENGINEER_PATH]
(If `software-engineer` is not installed, this slot is replaced by a short inline
instruction: build for production-readiness, security, maintainability, and
consistency with existing project conventions.)

## Available Skill (if assigned)
Read and follow: [STACK_OVERLAY_SKILL_PATH]

## Critical Requirements
- All output must be production-ready — no TODOs, no placeholders, no stubs
- Follow existing project conventions and patterns
- Meet the engineering bar defined by the `software-engineer` skill (or the inline fallback above) for code quality — error handling, clarity, and maintainability are defined there, not here
- Run and verify your work before considering a step complete
- If a step depends on another agent's output, check for it and adapt as needed

步骤 10：执行

启动所有执行 Agent。关键原则：

1. 尽可能并行 — 负责独立步骤的 Agent 可以同时运行
2. 必要时按序执行 — 遵守计划中的依赖顺序
3. 不依赖人工输入 — Agent 根据项目上下文自主做出所有决策
4. 边执行边验证 — 每个 Agent 都应验证自己的工作（运行测试、lint、验证输出）

步骤 11：集成与验证

所有执行 Agent 完成后，进行最终集成检查：

1. 检查所有输出是否存在 — 确认计划中的每项交付物均已产出
2. 运行集成检查 — 如果项目有测试，则运行测试；如果有构建流程，则执行构建
3. 验证一致性 — 确保不同 Agent 的输出彼此兼容
4. 修复集成问题 — 启动有针对性的 Agent 来解决任何冲突
5. 最终质量检查 — 确认结果符合计划中的质量标准

步骤 12：报告

将完成报告写入 docs/plans/execution-report.md：

# Execution Report: [Project Title]

## Summary
[What was accomplished]

## Completed Steps
[List of all executed steps with status]

## Key Decisions Made
[Significant autonomous decisions and their rationale]

## Files Created/Modified
[Complete list of all changes]

## Verification Results
[Test results, build status, integration check outcomes]

## Known Limitations
[Anything that couldn't be fully resolved]

## Next Steps (if any)
[Remaining work that requires human input or was out of scope]

---

Agent 启动

编排器使用平台的 Agent/子 Agent 功能启动 Agent。有关特定平台的启动模式（Claude Code Agent 工具、Codex 子 Agent、顺序执行回退方案），请参见 orchestration-workflow.md。

关键启动原则：

• 规划 Agent 并行运行 — 各自独立分析
• 研发 Agent 在规划 Agent 之前运行 — 其发现结果会影响团队组成
• 执行 Agent 遵循依赖关系图 — 独立步骤并行运行，存在依赖关系的步骤按序运行
• 集成 Agent 在所有执行 Agent 完成后运行

给编排者的指导

编排者的角色相当于一位 CTO，负责组建并指挥一支世界一流的团队——确定所需的专业能力、召集合适的人员、为他们明确任务，并整合他们的成果。

丰富的人设能产出更好的结果。 Agent 人设越具体、越有主见，其分析和执行效果就越好。“后端开发者”只能给出泛泛的建议。而“调试过大规模生产故障、坚持采用幂等操作和断路器的分布式系统工程师”则能给出经受过实战检验的建议。

先了解项目。 在组建任何团队之前，先弄清楚项目的现状。阅读项目结构、关键源文件、现有文档和配置。掌握这些背景信息，对于创建相关的 Agent 和制定切合实际的计划至关重要。

规划时，3-5 个 Agent 最合适。 Agent 越多，需要整合的内容就越多，也越容易产生冲突。只有在能带来真正不同的视角时，才增加 Agent。

第二阶段会获得全新上下文。 这是有意为之。执行 Agent 遵循计划，而不是参与制定计划时那场纷乱的讨论。计划是第一阶段与第二阶段之间的接口。

优先考虑稳健性，而非人工投入。 计划将由编码 Agent 执行。应以风险、安全性、可维护性或与惯例不符为由拒绝方案，绝不能因为方案对人类来说“工作量很大”而拒绝。团队提出虽合格但偏保守的计划时，应推动他们选择更强的方案。这项技能的核心意义，就是让编码 Agent 的执行能力突破软件团队通常面临的工作量和范围上限。