Claude Code Agent Teams - 默认基于团队的开发，严格TDD（测试驱动开发）流程执行

Agent Teams 技能

加载：base.md + code-review.md + security.md + session-management.md

目的： 每个使用claude-bootstrap初始化的项目都以AI代理团队的形式运行。这是默认的工作流程，不是可选的。团队执行严格的TDD流程，不能跳过任何步骤。

需要： CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 环境变量。

核心原则

每个功能都遵循由任务依赖性强制执行的不可变流程：

┌─────────────────────────────────────────────────────────────────┐
│  STRICT FEATURE PIPELINE (IMMUTABLE)                            │
│  ──────────────────────────────────────────────────────────────  │
│                                                                  │
│  1. SPEC        编写功能规范                      │
│       ↓         (Feature Agent)                                  │
│  2. REVIEW      质量代理审核规范完整性          │
│       ↓         (Quality Agent)                                  │
│  3. TESTS       为所有验收标准编写失败的测试  │
│       ↓         (Feature Agent)                                  │
│  4. RED VERIFY  质量代理确认所有测试失败            │
│       ↓         (Quality Agent)                                  │
│  5. IMPLEMENT   编写最少的代码以通过测试                 │
│       ↓         (Feature Agent)                                  │
│  6. GREEN VERIFY 质量代理确认所有测试通过+覆盖率│
│       ↓         (Quality Agent)                                  │
│  7. VALIDATE    Lint + 类型检查 + 全套测试              │
│       ↓         (Feature Agent)                                  │
│  8. CODE REVIEW 多引擎审查，阻塞在Critical/High      │
│       ↓         (Code Review Agent)                              │
│  9. SECURITY    OWASP扫描，秘密检测，依赖审计  │
│       ↓         (Security Agent)                                 │
│  10. BRANCH+PR  创建功能分支，暂存文件，创建PR    │
│                 (Merger Agent)                                    │
│                                                                  │
│  任何步骤都不能跳过。任务依赖性强制排序。     │
│  质量代理验证RED/GREEN转换。                   │
│  代码审查+安全代理控制合并路径。              │
│  合并代理处理分支和PR创建。                 │
└─────────────────────────────────────────────────────────────────┘

默认代理名单

每个项目都会生成5个永久代理+N个功能代理：

┌─────────────────────────────────────────────────────────────────┐
│  DEFAULT TEAM ROSTER                                             │
│  ──────────────────────────────────────────────────────────────  │
│                                                                  │
│  永久代理（始终存在）                               │
│  ─────────────────────────────────                               │
│  团队领导       编排，任务分解，分配任务      │
│                  使用委托模式 - 从不写代码         │
│                                                                  │
│  质量代理      TDD验证（RED/GREEN阶段）            │
│                  覆盖率门控（>= 80%）                        │
│                  规范完整性审核                       │
│                                                                  │
│  安全代理      OWASP扫描，秘密检测              │
│                  依赖审计，.env验证，Critical/High阻塞│
│                                                                  │
│  代码审查代理   多引擎代码审查                     │
│                   Claude / Codex / Gemini / All                │
│                   Critical/High阻塞                      │
│                                                                  │
│  合并代理      创建功能分支                       │
│                  只暂存特定于功能文件              │
│                  通过gh CLI创建PR                          │
│                 从不合并 - 只创建PR                │
│                                                                  │
│  动态代理（每个功能一个）                                │
│  ────────────────────────────────                                │
│  功能代理      实现一个功能端到端              │
│  (x N功能)  遵循上述严格流程                  │
│                  使用Ralph循环进行实现             │
└─────────────────────────────────────────────────────────────────┘

代理	角色	计划模式	可以编辑代码
team-lead	编排，任务分解，分配任务	否（委托模式）	否
quality-agent	TDD验证，覆盖率门控	是	否（只读）
security-agent	OWASP扫描，秘密检测	是	否（只读）
review-agent	多引擎代码审查	是	否（只读）
merger-agent	分支创建，PR管理	否	否（仅限git）
feature-{name}	功能实现（每个功能一个）	否	是

团队领导职责

团队领导是协调者。它从不写代码。

读取_project_specs/features/*.md以识别所有功能
将每个功能分解为10任务依赖链（见下文）
每个功能生成一个功能代理
分配初始任务（规范编写）给功能代理
持续监控任务列表以获取进度和阻塞
处理阻塞任务和重新分配
协调跨功能依赖
当所有PR创建完成时，向所有代理发送shutdown_request
完成后清理团队

委托模式是强制性的。 团队领导只使用：

TeamCreate, TaskCreate, TaskUpdate, TaskList, TaskGet
SendMessage（消息，广播，shutdown_request）
读取，Glob，Grep（用于监控）

功能代理工作流程（强制性）

每个功能代理必须遵循这个确切的顺序。任务依赖性强制排序 - 功能代理不能在步骤N完成和验证之前开始步骤N+1。

第1步：编写规范

创建_project_specs/features/{feature-name}.md
包括：描述，验收标准，测试案例表，依赖
遵循base.md技能中的原子TODO格式
标记任务完成 -> 质量代理审核

第2步：编写测试（RED阶段）

根据规范的测试案例表编写测试文件
测试必须覆盖所有验收标准
导入尚不存在的模块（它们将失败）
标记任务完成 -> 质量代理验证测试存在且失败

第3步：等待RED验证

质量代理运行测试并验证所有新测试失败
如果任何测试在没有实现的情况下通过 -> 重写测试
质量代理标记验证完成 -> 解锁实现

第4步：实现（GREEN阶段）

编写最少的代码以使所有测试通过
遵循base.md中的简单规则（20行/函数，200行/文件，3个参数）
使用Ralph循环（/ralph-loop）进行迭代实现
实现后运行测试 - 所有测试必须通过
标记任务完成 -> 质量代理验证测试通过

第5步：等待GREEN验证

质量代理运行完整测试套件并检查覆盖率
覆盖率必须 >= 80%
如果测试失败或覆盖率不足 -> 修复并重新请求
质量代理标记验证完成 -> 解锁验证

第6步：验证

运行linter（ESLint / Ruff）
运行类型检查器（TypeScript / mypy）
运行完整测试套件和覆盖率
修复任何问题
标记任务完成 -> 解锁代码审查

第7步：等待代码审查

代码审查代理对更改的文件运行/code-review
如果Critical或High问题 -> 修复并重新请求审查
代码审查代理标记完成 -> 解锁安全扫描

第8步：等待安全扫描

安全代理运行安全检查
如果Critical或High问题 -> 修复并重新请求扫描
安全代理标记完成 -> 解锁合并

第9步：等待分支+PR

合并代理创建功能分支，暂存文件，创建PR
功能完成时PR已创建

任务依赖链模型

对于每个功能“X”，团队领导创建这些10个任务，严格排序：

┌────────────────────────────────────────────────────────────────┐
│  TASK CHAIN FOR FEATURE "X"                                     │
│                                                                  │
│  Task 1:  X-spec                                                │
│           owner: feature-X                                       │
│           blockedBy: (none)                                      │
│           ↓                                                      │
│  Task 2:  X-spec-review                                         │
│           owner: quality-agent                                   │
│           blockedBy: X-spec                                      │
│           ↓                                                      │
│  Task 3:  X-tests                                               │
│           owner: feature-X                                       │
│           blockedBy: X-spec-review                               │
│           ↓                                                      │
│  Task 4:  X-tests-fail-verify                                   │
│           owner: quality-agent                                   │
│           blockedBy: X-tests                                     │
│           ↓                                                      │
│  Task 5:  X-implement                                           │
│           owner: feature-X                                       │
│           blockedBy: X-tests-fail-verify                         │
│           ↓                                                      │
│  Task 6:  X-tests-pass-verify                                   │
│           owner: quality-agent                                   │
│           blockedBy: X-implement                                 │
│           ↓                                                      │
│  Task 7:  X-validate                                            │
│           owner: feature-X                                       │
│           blockedBy: X-tests-pass-verify                         │
│           ↓                                                      │
│  Task 8:  X-code-review                                         │
│           owner: review-agent                                    │
│           blockedBy: X-validate                                  │
│           ↓                                                      │
│  Task 9:  X-security-scan                                       │
│           owner: security-agent                                  │
│           blockedBy: X-code-review                               │
│           ↓                                                      │
│  Task 10: X-branch-pr                                           │
│           owner: merger-agent                                    │
│           blockedBy: X-security-scan                             │
└────────────────────────────────────────────────────────────────┘

并行功能执行

多个功能并行运行它们的链。共享代理处理任务时它们解锁：

Feature: auth         Feature: dashboard      Feature: payments
  auth-spec             dash-spec               pay-spec
  auth-spec-review      dash-spec-review        pay-spec-review
  auth-tests            dash-tests              pay-tests
  auth-fail-verify      dash-fail-verify        pay-fail-verify
  auth-implement        dash-implement          pay-implement
  auth-pass-verify      dash-pass-verify        pay-pass-verify
  auth-validate         dash-validate           pay-validate
  auth-code-review      dash-code-review        pay-code-review
  auth-security         dash-security           pay-security
  auth-branch-pr        dash-branch-pr          pay-branch-pr
       |                     |                       |
       v                     v                       v
   [All chains run simultaneously]
   [Quality Agent handles all verify tasks as they unblock]
   [Review Agent handles all review tasks as they unblock]
   [Security Agent handles all scan tasks as they unblock]
   [Merger Agent handles all branch-pr tasks as they unblock]

代理间通信

直接消息（针对目标工作）

Feature Agent -> Quality Agent:  "Tests written for auth, ready for RED verify"
Quality Agent -> Feature Agent:  "All 7 tests fail as expected. Proceed to implement"
Feature Agent -> Review Agent:   "Implementation complete, ready for code review"
Review Agent  -> Feature Agent:  "2 High issues found: [details]. Fix before proceeding"
Security Agent -> Merger Agent:  "Security scan passed for auth feature"
Merger Agent  -> Team Lead:      "PR #42 created for auth feature"

任务列表（状态的真实来源）

所有代理在完成工作后检查任务列表
质量代理自动认领验证任务
审查代理自动认领代码审查任务
安全代理自动认领安全扫描任务
合并代理自动认领分支PR任务

广播（罕见 - 仅阻塞问题）

团队领导 -> 所有人：“Blocking dependency found between auth and dashboard”
安全代理 -> 所有人：“Critical vulnerability in shared dependency”

功能代理生成

团队领导为每个功能生成一个功能代理：

读取_project_specs/features/*.md
对于每个功能规范，生成一个功能代理：
- 名称：feature-{feature-name}
- 使用.claude/agents/feature.md定义
- 生成提示包括功能名称和规范位置
为该功能创建完整的10任务依赖链
将规范编写任务分配给功能代理

示例

如果项目有3个功能：auth，dashboard，payments

生成：feature-auth，feature-dashboard，feature-payments
总共创建30个任务（每个功能10个）
每个功能代理从他们的规范任务开始
所有3个并行工作

分支和PR策略

每个功能一个分支。每个功能一个PR。

Branch naming:  feature/{feature-name}
PR title:       feat({feature-name}): {short description}
PR body:        Generated from spec + test results + review + security results

合并代理：

git checkout main && git pull origin main
git checkout -b feature/{feature-name}
只暂存此功能更改的文件（从不git add -A）
提交具有描述性消息，包括验证结果
git push -u origin feature/{feature-name}
gh pr create带有完整模板，包括：
- 来自功能规范的摘要
- 来自质量验证的测试结果
- 来自审查代理的审查摘要
- 来自安全代理的安全扫描结果
- 所有流程步骤完成的清单

质量门控

工作流程执行（通过任务依赖性）

任务依赖性使其结构上不可能跳过步骤
功能代理在质量代理完成"tests-fail-verify"之前不能看到"implement"
这是主要的执行机制

跨代理验证（信任但验证）

质量代理独立运行测试（不信任功能代理的报告）
安全代理独立扫描（不信任审查代理）
合并代理在分支之前验证所有前驱任务是否完成

阻塞规则

质量代理：如果测试没有失败（RED）或没有通过（GREEN）或覆盖率<80%则阻塞
代码审查代理：在Critical或High严重性问题上阻塞
安全代理：在Critical或High严重性发现上阻塞
合并代理：如果任何前驱任务不完整则拒绝分支

与现有技能的集成

现有技能	代理团队如何使用它
base.md	TDD工作流程，原子TODO，简单规则 - 所有代理遵循
code-review.md	审查代理根据此技能执行 `/code-review`
security.md	安全代理遵循此技能中的OWASP模式
session-management.md	每个代理维护自己的会话状态
iterative-development.md	功能代理使用Ralph循环进行实现
project-tooling.md	合并代理使用`gh` CLI进行分支和PR
team-coordination.md	由代理团队取代自动化协调

环境设置

必需设置

// settings.json或环境
{
  "env": {
    "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
  }
}

项目结构（由/initialize-project创建）

.claude/
  agents/            # 代理定义（来自agent-teams技能）
    team-lead.md
    quality.md
    security.md
    code-review.md
    merger.md
    feature.md
  skills/
    agent-teams/     # 这个技能
      SKILL.md
      agents/        # 代理定义模板
    base/
    code-review/
    security/
    ...

生成团队

自动（通过/initialize-project）

项目设置完成后，第6阶段询问功能并自动生成团队。

手动（通过/spawn-team）

对于现有项目：运行 /spawn-team 从现有功能规范生成团队。

限制

实验性功能 - 代理团队需要实验性环境变量
没有嵌套团队 - 团队成员不能生成子团队
每个会话一个团队 - 在开始新团队之前清理
没有会话恢复 - 如果会话死亡，重新运行/spawn-team（任务持久）
文件冲突 - 共享文件的功能必须由团队领导序列化
令牌成本 - 每个代理是单独的Claude实例（5 + N实例）