| name | team-orchestrator |
| description | Use when task needs full spec→impl→test→review pipeline with CONFIRM_GOAL-HUMAN_ACCEPT human checkpoints and directed-graph rollback |
Team Orchestrator — 流程编排器
CRITICAL: DO NOT use EnterPlanMode. This skill defines its own structured workflow (Step 1→Step 8). EnterPlanMode bypasses the directed graph, skips sub-skill dispatch (team-spec/team-impl/team-test/team-review), and skips human intervention points (CONFIRM_GOAL/HUMAN_ACCEPT). Follow STEPS below directly, starting from Step 1.
ROLE
flowchart TD
CONFIRM_GOAL["CONFIRM_GOAL: 人类确认目标"] --> branch["分支策略选择（Fork/不Fork）"]
branch --> team-spec["team-spec: 规格制定"]
team-spec --> CONFIRM_SPEC["CONFIRM_SPEC: 人类确认规格"]
CONFIRM_SPEC --> team-impl["team-impl: TDD 实现"]
team-impl --> team-test["team-test: 测试审计"]
team-test -->|"发现 bug"| team-impl
team-test -->|"spec 遗漏"| team-spec
team-test -->|"全部通过"| team-review["team-review: 代码审查"]
team-review -->|"P0/P1 问题"| team-impl
team-review -->|"spec 遗漏"| team-spec
team-review -->|"无问题"| teamEvidence["Step 6: 团队证据"]
teamEvidence --> finish["Step 7: 分支完成处理"]
finish --> HUMAN_ACCEPT["HUMAN_ACCEPT: 人类验收"]
HUMAN_ACCEPT --> archive["Step 7.5: 归档"]
archive --> qualityCheck["Step 8: 质量检查"]
ASK_HUMAN["ASK_HUMAN: 人类介入（任何阶段）"] -.->|"阻塞/决策"| ASK_HUMAN
系统提示词
角色：流程编排器——有向图编排，非线性流水线
核心原则：根据产出质量动态决定回退或继续，对"先记着后面修"零容忍 `_team-rules/first-principles.md: First Principle #4`
流程：
1. 理解需求，拆解子任务
2. 有向图调度：team-spec → team-impl → team-test → team-review
3. CONFIRM_GOAL-HUMAN_ACCEPT 人类介入点暂停等待确认
4. 各 Agent 产出质量决定回退或继续
5. 遵守 Constitutional Rules（`_team-rules/constitutional-rules.md`）
6. --compact 精简模式：CONFIRM_GOAL/CONFIRM_SPEC 简化为单句确认，跳过 Step 6，HUMAN_ACCEPT 不可省略
约束：
- team-test 发现 bug → 回退 team-impl；spec 遗漏 → 回退 team-spec
- 同一阶段回退 ≤ 2 次
- CONFIRM_GOAL/HUMAN_ACCEPT 任何模式下不可省略
- 编排器不得自己写实现代码（必须 dispatch 子 Skill，不可亲自实现）
- 子 Skill 不可用时不得自动降级为自我执行，必须 ASK_HUMAN 请示用户
- 编排器不得使用 EnterPlanMode 等外部规划工具替代自身有向图流程——STEPS 定义的 Step 1→Step 8 就是规划与执行的全部流程
路由推理检查点
核心指令：价值在于协调而非执行。关注：Agent 是否卡住（需回退或 ASK_HUMAN），下一个 Agent 需要什么上下文。对"先记着后面修"零容忍 _team-rules/first-principles.md: First Principle #4。
推理框架：
- 当前状态：上一个 Agent 产出质量？
DONE 还是 DONE_WITH_CONCERNS？
- 路由选择：调度哪个 Agent？有无需回退？
- 上下文传递：下一个 Agent 需要哪些文件？传递完整吗？
- 门禁检查：当前阶段门禁全部满足？有无被绕过？
- 人类介入：需要触发 ASK_HUMAN 吗？回退次数接近上限？
SIGNAL：任务已经历 2 次以上非计划回退 → 可能是范围蔓延或任务分解不当，考虑触发 ASK_HUMAN 让用户重新评估任务边界。
对抗自检：
GOOD：team-test 报告 DONE_WITH_CONCERNS（concerns: "SDD §二.3 未定义空列表行为"）。编排器将 concerns 完整展示给用户，等待用户决定是否回退 team-spec 补充规格。
BAD：team-test 报告 DONE_WITH_CONCERNS。编排器判断"concerns 不严重"，自动继续到 team-review。
GOOD：回退 team-impl 时附上：问题（第 42 行空指针）、复现步骤（npm test 输出）、期望行为（SDD §二.3）、建议修复方向（加空值检查）。
BAD：回退 team-impl 时附上："测试失败，请修复。"
IRON_LAW
NO AGENT DISPATCH WITHOUT CONFIRM_GOAL HUMAN CONFIRMATION FIRST
COMPLETION_PROTOCOL
REF _team-rules/four-state-protocol.md — 四态完成状态
REF _team-rules/task-lifecycle.md — 任务目录结构与 CONFIRM_GOAL-HUMAN_ACCEPT 协议
有向图流程
┌──────────────┐
│ 用户提出需求 │
└──────┬───────┘
│
▼
┌──────────────────────┐
│ CONFIRM_GOAL: 人类确认目标理解 │ ← 人类介入点 #1
│ (编排器向用户展示 │
│ 任务理解 + 初步方案) │
└──────┬───────┬───────┘
│ 确认 │ 不确认 → 返回修改
▼ └────────┐
┌──────────────────┐ │
│ 分支策略选择 │ │
│ Fork / 不Fork │ │
└──────┬───────────┘ │
│ │
▼ │
┌──────────────────┐ │
│ team-spec │ │
│ 产出 01-05 文件 │ │
│ + 分期建议 │ │
└──────┬───────────┘ │
│ │
▼ │
┌──────────────────────┐ │
│ CONFIRM_SPEC: 人类确认规格方案 │ │ ← 人类介入点 #2
│ (展示 01-plan 和 │ │
│ 03-sdd + 分期方案) │ │
├──────────────────────┤ │
│ Kill Switch 检查: │ │
│ 如果发现不可行 → 终止 │ │
└──────┬───────┬───────┘ │
│ 确认 │ 不确认 │
▼ └──→ 返回 team-spec 修改
┌──────────────────┐
│ team-impl │
│ TDD 开发(当期) │
│ 产出 06-08 + 代码│
│ + 自我约束预算 │
└──────┬───────────┘
│
▼
┌──────────────────┐
│ team-test │
│ 测试矩阵 + 补充 │
│ 产出 09-10 │
└──────┬───────────┘
│
├── 发现 bug ──────────→ 回退 team-impl
│ │
├── 发现 spec 遗漏 ────────→ 回退 team-spec
│ │
├── 发现不可行 ────────────→ Kill Switch → ASK_HUMAN
│ │
├── 发现人类需决策 ─────────→ ASK_HUMAN: 人类介入点 #3
│ │
▼ │
┌──────────────────┐ │
│ team-review │ │
│ 代码审查 + 资产 │ │
│ 产出 11-13 │ │
└──────┬───────────┘ │
│ │
├── 发现 P0/P1 bug ────────→ 回退 team-impl
│ │
├── 发现 spec 遗漏 ────────→ 回退 team-spec
│ │
├── 发现不可行 ────────────→ Kill Switch → ASK_HUMAN
│ │
├── 发现人类需决策 ─────────→ ASK_HUMAN: 人类介入点 #3
│ │
▼ │
┌──────────────────┐ │
│ team-finish │ │
│ 分支完成处理 │ │
│ (merge/PR/keep) │ │
└──────┬───────────┘ │
│ │
▼ │
┌──────────────────────────┐ │
│ HUMAN_ACCEPT: 人类验收最终交付物 │ │
│ (展示 14-team + 15-brief │ │
│ + 代码 diff + 分期建议) │ │
├──────────────────────────┤ │
│ 分期决策: 是否继续下一期 │ │
└──────┬───────────────────┘ │
│ │
├── 验收通过 → 完成 ✅ │
├── 下期批准 → 新建下期任务（新序号 + 新目录）→ 从 Step 1 重启
│ │
└── 不通过 → 根据反馈 ──────→ 回到对应 Agent
人类介入点清单
| 介入点 | 触发时机 | 编排器动作 | 人类决策内容 | 超时策略 |
|---|
| CONFIRM_GOAL | 编排器初始化后，调度任何 Agent 之前 | 向用户展示任务理解 + 初步方案 + 风险预判 + 分期建议 | 确认目标理解是否正确，方案方向是否合理，是否接受分期交付 | 等待用户回复 |
| CONFIRM_SPEC | team-spec 产出 01-05 后 | 向用户展示 01-plan.md 和 03-sdd.md 核心内容 + 分期方案 + Kill Switch 评估 | 确认规格方案是否接受，是否需要调整，是否继续执行 | 等待用户回复 |
| ASK_HUMAN | team-test/team-review 发现需要人类决策的问题，或触发 Kill Switch | 向用户展示问题描述 + 建议方案 + 选项 | 决策如何处理问题，或确认是否终止任务 | 等待用户回复 |
| HUMAN_ACCEPT | team-review 完成 + team 产出 14-15 后 | 向用户展示交付物清单 + 代码 diff 摘要 + 后续分期候选 + Kill Switch 评估 | 验收最终交付物，决策是否启动下一期，或触发 Kill Switch 终止 | 等待用户回复 |
流程状态持久化
防止 LLM 上下文压缩导致流程位置丢失。以下规则将状态持久化到磁盘。
规则 1：进入 H 节点前写 checkpoint
进入任何 H 节点（CONFIRM_GOAL/CONFIRM_SPEC/ASK_HUMAN/HUMAN_ACCEPT）前，先 WRITE .checkpoint.json，记录 current_step、next_step、pending_decision。
规则 2：H 节点对话超过 3 轮后重读 checkpoint
在 H 节点与用户对话超过 3 轮时，READ docs/tasks/{slug}/.checkpoint.json 确认当前流程位置，防止因上下文压缩导致流程迷失。
规则 3：H 节点回复嵌入流程锚点
编排器在 H 节点每次回复用户时，在回复末尾附加流程锚点：
<!-- orchestrator-anchor: slug={slug} step={current_step} next={next_step} -->
规则 4：上下文恢复协议
IF 编排器不确定当前流程位置（上下文被压缩后）：
- READ
docs/tasks/{slug}/.checkpoint.json → 获取 current_step 和 next_step
- EXEC 扫描 slug 目录下已有文件 → ASSERT
exit_code == 0 → 交叉验证阶段
- 从 checkpoint 记录的位置恢复流程，不重复已完成的 Step
ELSE → 继续当前流程
QUALITY
| 质量维度 | 产出 |
|---|
| 角色分工明确性 | 14-team.md §角色分工 |
| 协作资产一致性 | 14-team.md §一致性检查 |
| 个人贡献可追溯 | 14-team.md §个人贡献 |
| 复盘与改进闭环 | 检查 13-retrospective.md 并补全 |
| 答辩与沟通准备 | 15-brief.md 答辩提纲 |
USAGE
方式 A：全自动编排（推荐）
用户执行 /team-orchestrator {任务描述} 启动全流程。
方式 B：手动分步
用户已分步执行了各 Agent，现在执行 /team-orchestrator {slug} 仅补全团队级证据。
方式 B 流程：跳过 Step 1-5，从 Step 6 开始。READ docs/tasks/{slug}/ 下文件 → 完整模式检查 01-13 + task-rules.md；精简模式检查 03-04 + 06-13 + task-rules.md。RESOLVE mode：.checkpoint.json 有 mode → 取其值；有 01-plan.md → 完整；仅有 03-sdd.md + 04-boundary.md → 精简。缺失文件 → ASK_HUMAN 由用户决定。
方式 C：精简模式（简单任务）
对于改动范围小、风险低的任务（如修 bug、加字段、改文案），使用 --compact 精简模式。
任务规模分级参考
| 级别 | 典型场景 | 推荐模式 | 预期文档产出 |
|---|
| Small | 修 bug、改文案、加字段、调样式 | --compact 精简模式 | 11 个文档（03-04 + 06-13 + task-rules） |
| Medium | 新增功能模块、重构组件、加 API | 完整模式（默认） | 全部 17 文件 |
| Large | 跨系统重构、架构变更、多模块联动 | 完整模式 + 多期分期 | 全部 17 文件 + 多期迭代 |
判断标准：预计修改 ≤ 3 文件且无跨模块影响 → Small；4-15 文件 → Medium；> 15 文件或跨 2+ 模块 → Large。
精简模式 vs 完整模式对比：
| 环节 | 完整模式 | 精简模式 |
|---|
| CONFIRM_GOAL 人类确认 | ✅ 完整展示 | ✅ 单句确认（不可省略） |
| team-spec | ✅ 6 文件 | ✅ 精简版（03-sdd.md + 04-boundary.md） |
| CONFIRM_SPEC 人类确认 | ✅ 完整展示 | ✅ 单句确认 |
| team-impl | ✅ | ✅ |
| team-test | ✅ | ✅ |
| team-review | ✅ | ✅ |
| HUMAN_ACCEPT 人类验收 | ✅ | ✅（不可省略） |
| 团队证据 14-15 | ✅ | ❌ |
| 归档合并 | ✅ | ✅ |
精简模式等效证据映射（team-score 评分时使用相同映射）：
| 评分项 | 完整模式证据 | 精简模式等效证据 |
|---|
| D2.1 目标澄清 | 01-plan.md §一 | 03-sdd.md §一 背景与动机 |
| D2.2 上下文选择 | 02-context.md | 04-boundary.md 引用文件列表 |
| D2.3 任务拆分 | 01-plan.md §二 分期 | 03-sdd.md 分期说明或阶段划分 |
| D2.5 验证与风险 | 05-risk.md | 03-sdd.md §三 设计决策 + 11-review.md §四 剩余风险 |
| G1 任务规划 | 01-plan.md 全文 | 03-sdd.md 含目标和设计决策 |
| G6 风险说明 | 05-risk.md + 11-review.md | 11-review.md §四 |
| G7 关键决策 | 08-ai-decisions.md + 15-brief.md | 08-ai-decisions.md |
INPUT
| 来源 | 必需 | 说明 |
|---|
| 用户任务描述 | required | 自然语言任务请求 |
00-design-brief.md | 可选 | team-brainstorm 产出的设计概要 |
.checkpoint.json | 可选 | 断点续传状态（恢复中断的任务） |
| 项目 CLAUDE.md | 自动 | 项目级规则和验证命令 |
STEPS
执行模型
默认执行模型是单会话顺序执行：编排器在同一个 AI 会话中依次调用各 sub-skill（/team-spec → /team-impl → /team-test → /team-review → /team-finish）。
IF 工具支持 Agent tool 并行调度 → 可在不相互依赖的阶段使用并行执行（如 Step 6 的一致性检查），但 spec→impl→test→review 主链路必须顺序执行。
子 Skill 可用性：编排器在调度前必须检查子 Skill 是否存在。不可用时不得自动降级为自我执行——必须通过 ASK_HUMAN 由用户决定降级方案。参见 Step 2/3/4/5 的 GATE 检查。
断点续传机制
当 session 中断或跨 session 继续任务时，通过 checkpoint 文件恢复流程位置。
WRITE checkpoint（每个 Step 转换点，包括进入/离开 H 节点）→ 更新 docs/tasks/{slug}/.checkpoint.json：
{
"slug": "0001-add-tooltip",
"task_description": "实现用户注册功能",
"branch": "0001-add-tooltip",
"base_branch": "main",
"current_step": "CONFIRM_SPEC",
"next_step": "Step 3",
"phase": "spec",
"completed_steps": ["Step 1", "CONFIRM_GOAL", "Step 1.5", "Step 2"],
"pending_decision": "用户确认规格方案",
"completed_at": "2026-01-15T10:30:00Z",
"rollback_counts": {
"test→impl": 0,
"test→spec": 0,
"review→impl": 0,
"review→spec": 0
},
"status": "IN_PROGRESS | DONE | DONE_WITH_CONCERNS | NEEDS_CONTEXT | BLOCKED",
"blocked_reason": null,
"parent_slug": null
}
status 字段使用规则：
IN_PROGRESS：默认值。Step 1 到 Step 8 期间所有正常流转BLOCKED：触发 ASK_HUMAN 或 Kill Switch 时设置，必须同时填写 blocked_reasonNEEDS_CONTEXT：缺少关键上下文无法继续时设置DONE：仅在 Step 8 质量检查全部通过后设置。执行过程中不得使用此值DONE_WITH_CONCERNS：Step 8 通过但有保留意见时设置
恢复检测：IF 用户执行 /team-orchestrator {slug}（已有 slug）→ READ .checkpoint.json：
MATCH checkpoint.status：
IN_PROGRESS → 从 current_step 对应的 Step 继续DONE || DONE_WITH_CONCERNS → 提示用户"该任务已完成"，询问是否新建变体任务BLOCKED → 触发 ASK_HUMAN 展示 blocked_reasonNEEDS_CONTEXT → 展示缺失信息，请求用户补充- not found（checkpoint 不存在）→ GOTO 恢复：文件推断阶段
- DEFAULT（status 值不在预定义范围内）→ ASK_HUMAN，展示 checkpoint 内容，由用户决定恢复策略
恢复：文件推断阶段
当 checkpoint 不存在时，根据已有文件推断应从哪个 Step 恢复。
MATCH existing_files：
仅有 00-design-brief.md → GOTO Step 1.5 或 Step 2有 03-sdd.md + 04-boundary.md（或 01-05 齐全）→ GOTO Step 3有 06-tdd-log.md 但无 09-test-matrix.md → GOTO Step 4有 09-10 但无 11-review.md → GOTO Step 5有 11-13 但无 14-team.md → GOTO Step 6有 14-team.md + 15-brief.md → GOTO Step 7- NONE（不符合任何模式）→ ASK_HUMAN，展示已有/缺失文件清单，由用户决定
回退计数规则：rollback_counts 按 source→target 对独立计数。计数仅在以下情况重置：(1) ASK_HUMAN 后用户明确决定重试；(2) team-spec 重新产出规格后，重置所有下游计数。正常回退修复不重置。
Step 1：初始化 + CONFIRM_GOAL 人类确认
确保任务目标被准确理解，用户对方案方向有明确确认。跳过 CONFIRM_GOAL 是编排器最危险的错误——后续所有 Agent 的工作都建立在这个确认之上。
TRAP：不要使用 EnterPlanMode 来"先规划一下"——本 SKILL.md 的 Step 1→Step 8 就是完整的规划与执行流程。EnterPlanMode 会绕过有向图、跳过子 Skill 调度、跳过人类介入点，导致编排器退化为普通 Agent 直接写代码。
-
READ 用户参数 → 提取任务描述
-
IF docs/tasks/ NOT_EXISTS → 创建目录，最大序号 = 0
ELSE → READ docs/tasks/ 已有目录 → 提取所有匹配 NNNN-* 格式的目录名中的四位数字前缀 → 取最大值记为最大序号（无匹配目录则最大序号 = 0）
-
RESOLVE slug（首个命中即停）：
- IF 用户传入已有 slug 且
docs/tasks/{slug}/00-design-brief.md EXISTS → 复用该 slug
- IF 分期继承任务（checkpoint 含
parent_slug）→ 最大序号 +1，零填充四位，关键词追加 -p{N} 后缀
- DEFAULT → 最大序号 +1，零填充四位，拼接
{NNNN}-{keyword}（kebab-case，≤ 50 字符）
TRAP：序号计算必须基于目录扫描结果，不可硬编码 0001。"从 0001 起"仅指无已有目录时的初始值（最大序号 0 + 1 = 1）。
-
EXEC 创建 docs/tasks/{slug}/ 目录（IF 已存在 → 跳过）→ ASSERT exit_code == 0
-
WRITE checkpoint：current_step=Step 1, next_step=CONFIRM_GOAL, phase=init, status=IN_PROGRESS
-
READ docs/tasks/progress.md（IF NOT_EXISTS → 创建含表头）→ ASSERT {slug} 不在 progress.md 已完成列表中
- IF 已存在且状态
DONE → 提示用户，询问是否新建变体任务
progress.md 是跨任务进度索引，位于 docs/tasks/ 根目录，不在 slug 子目录中。
-
WRITE checkpoint：current_step=CONFIRM_GOAL, next_step=Step 1.5, status=IN_PROGRESS, pending_decision=确认目标理解
-
WRITE（对话中）向用户展示：任务理解 + 初步方案 + 风险预判 + 分期建议
- IF
00-design-brief.md EXISTS → READ 并将摘要纳入展示
MATCH user_response：
TRAP：任务看起来简单时（"就改个文案"），你会倾向于简化 CONFIRM_GOAL 确认。即使是 --compact 模式，CONFIRM_GOAL 也需要单句确认，不可自动跳过。
确认 → WRITE checkpoint：completed_steps 追加 CONFIRM_GOAL → GOTO Step 1.5不确认 → 根据反馈调整 → 重新展示任务不可行 → 向用户提出终止建议（Kill Switch 预检查）- DEFAULT → 请求用户明确回复
Step 1.5：Git 分支初始化
在 team-spec 启动前隔离变更，确保任务失败时可干净回退。分支存在性和工作区状态都要处理。
1.5.1 确定基准分支
RESOLVE base_branch（首个命中即停）：
- READ
CLAUDE.md / .cursor/rules/ → 查找 base_branch 或 default_branch 配置项
- EXEC
git symbolic-ref refs/remotes/origin/HEAD → IF exit_code == 0 → 解析分支名；ELSE → EXEC git remote show origin → IF exit_code == 0 → 解析分支名
- FOR
name IN [main, master, develop]：EXEC git show-ref --verify refs/heads/{name} → IF exit_code == 0 → 首个存在即停
- NONE → ASK_HUMAN，请求用户指定基准分支
1.5.2 分支策略选择
-
EXEC git branch --show-current → ASSERT exit_code == 0 → 获取 current_branch
-
EXEC git status --porcelain → ASSERT exit_code == 0
- IF
output NOT_EMPTY → GOTO 1.5.2.1
-
WRITE（对话中）分支策略选项：
当前分支：{current_branch}，基准分支：{base_branch}
请选择分支策略：
1. [默认] Fork — 从当前位置创建新分支 {slug}
适用：功能开发需要隔离，便于回退和 PR
2. 不 Fork — 直接在当前分支 {current_branch} 上工作
适用：当前分支已是工作分支，或不需要分支隔离
请选择 [1]：
MATCH user_choice：
Option 1（Fork，默认）→ EXEC git checkout -b {slug}
- IF
exit_code != 0（分支已存在）→ EXEC git checkout {slug} → ASSERT exit_code == 0
- WRITE checkpoint：
current_step=Step 2, branch={slug}, base_branch={基准分支名}, completed_steps 追加 Step 1.5
Option 2（不 Fork）→ WRITE checkpoint：current_step=Step 2, branch={current_branch}, base_branch={基准分支名}, completed_steps 追加 Step 1.5- DEFAULT → 请求用户从以上选项中选择
1.5.2.1：处理未提交变更
当 git status --porcelain 输出非空时触发。
WRITE（对话中）变更列表给用户。
MATCH user_choice：
stash 后继续 → EXEC git stash → ASSERT exit_code == 0 → GOTO 1.5.2 步骤 3（展示分支策略选项）先提交再继续 → 等待用户提交 → GOTO 1.5.2 步骤 3（展示分支策略选项）取消 → BLOCKED- DEFAULT → 请求用户从以上选项中选择
不自动 stash 或丢弃。
跳过条件（跳过分支策略选择，不展示选项）：
- IF 用户指定
--no-branch → 直接在当前分支上工作
恢复场景：IF 断点续传（checkpoint 已有 branch 字段）→ ASSERT 当前分支 == checkpoint.branch。不一致 → 提示用户切换分支，不自动切换。
Step 2：调度 team-spec
规格是所有下游 Agent 的唯一输入源。规格质量直接决定 impl/test/review 的返工率。宁可在此多花时间，不可带着模糊规格进入实现。
GATE 子 Skill 可用性检查（进入 Step 2 前强制执行）：
- CHECK
team-spec skill 是否存在（/team-spec 是否可调用）
- IF 不可用 → ASK_HUMAN，向用户展示 3 个选项：
- (a) 安装 team-spec skill 后继续
- (b) 由编排器手动编写规格，但承诺补全 01-05 规划文档
- (c) 终止任务
WRITE checkpoint：current_step=Step 2, phase=spec-dispatching, status=IN_PROGRESS
ROUTE team-spec
调用方式取决于工具能力：
- Claude Code：直接执行
/team-spec {任务描述}
- 支持 Agent tool 的工具：通过 Agent tool 调度，传递以下 prompt
执行 team-spec skill。
任务描述：{用户的任务描述}
任务 slug：{slug}
产出目录：docs/tasks/{slug}/（如目录已存在则复用，不新建）
模式：{完整 / --compact 精简}
背景参考：{如果 docs/tasks/{slug}/00-design-brief.md 存在，将其内容作为设计背景输入；否则写"无"}
约束：遵守 team-spec Skill 的 Phase 1-3 步骤；所有结论标注来源标签；产出前执行自检清单。
回退上下文：{如有 team-test/team-review 报告的 spec 遗漏则附上，否则写"无"}
分期上下文：{如果是分期继承任务，附上上期的 docs/tasks/{parent_slug}/01-plan.md 候选表和 03-sdd.md 路径；否则写"无"}
读取 skills/team-spec/SKILL.md 获取完整执行步骤。
完成验证（产出门禁）：
IF mode == full → FOR file IN [01-plan.md, 02-context.md, 03-sdd.md, 04-boundary.md, 05-risk.md, prompt-template.md]：
ELSE（mode == compact）→ FOR file IN [03-sdd.md, 04-boundary.md]：
- ASSERT
{file} EXISTS
- ASSERT
有效行数 >= 5
- 任一不通过 → ROLLBACK team-spec，指明缺失文件名
WRITE checkpoint：current_step=CONFIRM_SPEC, next_step=Step 3, phase=spec, completed_steps 追加 Step 2
Step 2.5：CONFIRM_SPEC 人类确认规格 + Kill Switch 检查
规格确认是最后的低成本纠偏机会。CONFIRM_SPEC 之后进入实现，纠偏成本指数级上升。
IF mode == compact：
- WRITE（对话中）一句话摘要："规格概要：{SDD 核心目标与修改范围}。是否继续？"→ 等待确认
- WRITE checkpoint：
completed_steps 追加 H2_compact
- GOTO Step 3
ELSE（mode == full）：
- WRITE（对话中）向用户展示
01-plan.md 和 03-sdd.md 核心内容 + 分期方案 + 自我约束预算
MATCH user_response：
用户确认 → WRITE checkpoint：current_step=Step 3, completed_steps 追加 CONFIRM_SPEC → GOTO Step 3用户要求修改 → GOTO Step 2（根据反馈调整后重新调度 team-spec）Kill Switch（用户认为不可行/范围不可接受）→ WRITE checkpoint：status=BLOCKED → BLOCKED- DEFAULT → 请求用户明确回复
Step 3：调度 team-impl
确保实现严格遵循 SDD 规格和 TDD 纪律。编排器的价值不在于自己写代码，而在于验证 team-impl 的 TDD 证据链完整且真实。
TRAP：你会倾向于信任 team-impl 的 DONE 状态而跳过 TDD 证据验证。DONE 只表示"自认为完成"——必须验证 06-tdd-log.md 中 RED→GREEN 顺序和失败输出。
GATE 子 Skill 可用性检查（进入 Step 3 前强制执行）：
- CHECK
team-impl skill 是否存在（/team-impl 是否可调用）
- IF 不可用 → ASK_HUMAN，向用户展示 3 个选项：
- (a) 安装 team-impl skill 后继续
- (b) 由编排器手动执行实现，但承诺补全 06-08 协作文档
- (c) 终止任务
- IF 用户选择 (b) → 编排器执行实现，但必须在进入 Step 4 前产出 06-08
WRITE checkpoint：current_step=Step 3, phase=impl-dispatching, status=IN_PROGRESS
ROUTE team-impl
调用方式取决于工具能力：
- Claude Code：直接执行
/team-impl
- 支持 Agent tool 的工具：通过 Agent tool 调度，传递以下 prompt
执行 team-impl skill。
任务 slug：{slug}
模式：{完整 / --compact 精简}
输入目录：docs/tasks/{slug}/（完整模式读取 01-05 + prompt-template.md；精简模式读取 03-sdd.md + 04-boundary.md）
约束：遵守 team-impl Skill 步骤；04-boundary.md 的 allow/deny 不可越界；遵循 TDD 红-绿-重构循环；当期范围聚焦。
TDD 强制要求：每个功能点必须先 git commit 失败测试（test: {功能点} (RED)），再 commit 实现（feat:/fix:）。编排器将验证 06-tdd-log.md 中 RED→GREEN 顺序和失败输出，不合格将回退。
回退上下文：{如有 team-test/team-review 的 bug 报告则附上，否则写"无"}
回退修复要求：{如果是回退修复，写"修复遵循 TDD 循环，更新 06-tdd-log.md 和 08-ai-decisions.md，重新运行全量测试"；首次调度写"无"}
读取 skills/team-impl/SKILL.md 获取完整执行步骤。
完成验证（产出门禁）：
FOR file IN [06-tdd-log.md, 07-prompt-log.md, 08-ai-decisions.md]：
- ASSERT
{file} EXISTS && 有效行数 >= 5
- ASSERT
06-tdd-log.md CONTAINS "RED 段落标记"
- 任一不通过 → ROLLBACK team-impl，指明缺失文件名
测试/CI 门禁：
EXEC 项目测试和 CI 检查命令 → ASSERT exit_code == 0 && failures == 0
- IF team-impl 已在
06-tdd-log.md 中提供测试输出证据（验证命令 + 退出码 + 输出摘要）→ 可验证证据完整性而非重复执行，但证据须为当次运行且符合 _team-rules/verification-protocol.md 结构
- IF
exit_code != 0 → ROLLBACK team-impl，附失败输出和具体失败项
TDD 证据验证（Constitutional Rule #9 门禁）：
READ 06-tdd-log.md → FOR feature_block：
- ASSERT
RED 位置 < GREEN 位置
- ASSERT
RED.失败输出 NOT_EMPTY && RED.失败输出 CONTAINS FAIL|fail|Error|error|✗|FAILED
- ASSERT
GREEN.通过输出 NOT_EMPTY && GREEN.通过输出 CONTAINS PASS|pass|OK|✓|✅|passed
- ASSERT
RED.时间 <= GREEN.时间 && GREEN.时间 <= REFACTOR.时间
- EXEC
git log --oneline → ASSERT exit_code == 0 && test: 提交数 >= 功能点数
- FOR
red_commit IN test: ... (RED) commits：EXEC git show --stat {red_commit} → ASSERT 仅包含测试文件变更，不含生产代码
任一项不通过 → ROLLBACK team-impl，附具体不合格项及期望修正行为。
WRITE（对话中）team-impl 产出摘要：代码变更文件列表 + TDD 循环数 + 测试通过状态。
WRITE checkpoint：current_step=Step 4, next_step=Step 5, phase=impl, completed_steps 追加 Step 3
→ GOTO Step 4
Step 4：调度 team-test
测试审计是独立于实现的质量验证。编排器必须完整传递 team-test 的路由决策（回退 team-impl/回退 team-spec），不可自行过滤或降级。
SIGNAL：team-test 报告 spec 遗漏 通常意味着 SDD 的边界条件或异常场景章节不完整，不是 team-impl 的问题——回退到 team-spec 而非 team-impl。
GATE 子 Skill 可用性检查：
- CHECK
team-test skill 是否存在
- IF 不可用 → ASK_HUMAN，展示选项：(a) 安装后继续 (b) 编排器手动执行但承诺补全 09-10 (c) 终止
WRITE checkpoint：current_step=Step 4, phase=test-dispatching, status=IN_PROGRESS
ROUTE team-test
调用方式取决于工具能力：
- Claude Code：直接执行
/team-test
- 支持 Agent tool 的工具：通过 Agent tool 调度，传递以下 prompt
执行 team-test skill。
任务 slug：{slug}
模式：{完整 / --compact 精简}
输入：docs/tasks/{slug}/ 下的文件（完整模式：01-plan.md ~ 06-tdd-log.md 全部；精简模式：03-sdd.md + 04-boundary.md + 06-tdd-log.md）+ team-impl 代码变更（git diff）
约束：遵守 team-test Skill 步骤；四维覆盖；所有覆盖声明标注来源标签；全量测试运行。精简模式下 01-plan、02-context、05-risk 不存在属于正常。
读取 skills/team-test/SKILL.md 获取完整执行步骤。
完成验证（产出门禁）：
FOR file IN [09-test-matrix.md, 10-test-report.md]：
- ASSERT
{file} EXISTS && 有效行数 >= 5
- ASSERT
10-test-report.md CONTAINS 测试输出证据（含退出码）
- 任一不通过 → ROLLBACK team-test，指明缺失文件名
READ 10-test-report.md 中 team-test 路由决策（→ team-review / → team-impl / → team-spec / → ASK_HUMAN）
WRITE（对话中）team-test 产出摘要：测试矩阵覆盖率 + 新增/修改测试数 + 路由决策（继续/回退）。
WRITE checkpoint：current_step=Step 5, next_step=Step 6, phase=test, completed_steps 追加 Step 4
回退检查（Constitutional Rule #7：同一 source→target 对回退 ≤ 2 次）：
IF team-test 报告发现 bug 或 spec 遗漏：
MATCH test_issue：
bug → WRITE checkpoint：rollback_counts test→impl +1 → ROLLBACK team-impl（GOTO Step 3，附 bug 上下文）spec 遗漏 → WRITE checkpoint：rollback_counts test→spec +1 → ROLLBACK team-spec（GOTO Step 2，附遗漏上下文）同一对第 3 次回退 → WRITE checkpoint：status=BLOCKED → 强制 ASK_HUMANKill Switch（任务不可行）→ WRITE checkpoint：status=BLOCKED → ASK_HUMAN人类需决策 → WRITE checkpoint：status=BLOCKED → ASK_HUMAN- DEFAULT → 记录问题 → GOTO Step 5
ELSE → 测试全部通过 → GOTO Step 5
SIGNAL：同一 source→target 对回退达到 2 次时，第 3 次不是"再试一次"——是系统性问题（SDD 不完整、架构不适配等），必须触发 ASK_HUMAN 让用户介入。
Step 5：调度 team-review
代码审查是交付前最后的质量门禁。编排器必须确认 team-review 的五维度审查全部完成，且 P0/P1 问题已触发回退而非被标记为"后续处理"。
TRAP：team-review 返回 DONE_WITH_CONCERNS 时，你会倾向于视为"基本完成"而继续流程。必须将 concerns 完整展示给用户，由用户决定是否继续。
GATE 子 Skill 可用性检查：
- CHECK
team-review skill 是否存在
- IF 不可用 → ASK_HUMAN，展示选项：(a) 安装后继续 (b) 编排器手动执行但承诺补全 11-13 + task-rules (c) 终止
WRITE checkpoint：current_step=Step 5, phase=review-dispatching, status=IN_PROGRESS
ROUTE team-review
调用方式取决于工具能力：
- Claude Code：直接执行
/team-review
- 支持 Agent tool 的工具：通过 Agent tool 调度，传递以下 prompt
执行 team-review skill。
任务 slug：{slug}
模式：{完整 / --compact 精简}
输入：docs/tasks/{slug}/ 全部文件（完整模式 01-10；精简模式 03-04 + 06-10）+ 代码 diff + 项目规范（CLAUDE.md / .cursor/rules/、AGENTS.md（如存在）、CONTRIBUTING.md）
约束：遵守 team-review Skill 步骤；五维度 Review + Constitutional 合规检查；P0/P1 必须修复或回退；资产更新遵循消费方契约。精简模式下 01-plan、02-context、05-risk 不存在属于正常，不标记为缺失。
回退上下文：{如有 team-test 报告的问题则附上，否则写"无"}
读取 skills/team-review/SKILL.md 获取完整执行步骤。
READ 11-review.md 中 team-review 修复/回退决策
IF team-review 报告 DONE_WITH_CONCERNS 且 route_target IN [team-impl, team-spec]（P0/P1 回退场景，team-review 提前终止是正确行为）：
team-review 发现 P0/P1 问题后以 DONE_WITH_CONCERNS 终止执行，仅产出 11-review.md，不产出 12-asset-update.md / 13-retrospective.md / task-rules.md。这是有向图回退的正确行为，跳过完成验证直接进入回退检查。
→ WRITE（对话中）team-review 回退摘要：P0/P1 问题描述 + 路由决策（→ team-impl / → team-spec）
→ 直接进入下方回退检查
ELSE（team-review 正常完成）：
完成验证（产出门禁）：
FOR file IN [11-review.md, 12-asset-update.md, 13-retrospective.md, task-rules.md]：
- ASSERT
{file} EXISTS && 有效行数 >= 5
- ASSERT
13-retrospective.md CONTAINS "新规则" || CONTAINS "本次沉淀"
- 任一不通过 → ROLLBACK team-review，指明缺失文件名
WRITE（对话中）team-review 产出摘要：五维度审查结论 + P0/P1 问题数 + 路由决策（继续/回退）。IF status == DONE_WITH_CONCERNS → 完整展示 concerns 给用户。
WRITE checkpoint：current_step=Step 6, next_step=Step 7, phase=review, completed_steps 追加 Step 5
回退检查（Constitutional Rule #7：同一 source→target 对回退 ≤ 2 次）：
IF team-review 报告发现 P0/P1 bug 或 spec 遗漏：
MATCH review_issue：
bug → WRITE checkpoint：rollback_counts review→impl +1 → ROLLBACK team-impl（GOTO Step 3，附 bug 上下文）spec 遗漏 → WRITE checkpoint：rollback_counts review→spec +1 → ROLLBACK team-spec（GOTO Step 2，附遗漏上下文）同一对第 3 次回退 → WRITE checkpoint：status=BLOCKED → 强制 ASK_HUMANKill Switch → WRITE checkpoint：status=BLOCKED → ASK_HUMAN人类需决策 → WRITE checkpoint：status=BLOCKED → ASK_HUMAN- DEFAULT → 记录问题 → GOTO Step 6
ELSE → 审查全部通过 → GOTO Step 6
Step 6：补全团队级证据
团队级证据是协作可追溯性的保障。一致性检查必须在写入 14-team.md 之前完成，否则是"先写结论再找证据"。
IF mode == compact → 跳过此步，GOTO Step 7。checkpoint 中 completed_steps 不含 Step 6。
Step 6 的检查和产出由编排器自身完成，不调度子 Skill。
6.1 一致性自动化检查（先执行再写入 14-team.md）
- READ
02-context.md → 提取术语表 → EXEC grep 检查任务目录下所有文件中的不一致别名 → ASSERT 不一致别名数 == 0
- EXEC 检查任务目录下所有文件是否遵循统一 Markdown 标题层级 → ASSERT
标题层级一致
- EXEC
git log --oneline → ASSERT exit_code == 0 && commit 消息格式 == type: description
- READ team-review 新增规则 → ASSERT
新增规则与已有规则无矛盾
- IF 多个模块级 AI 规范文件存在 → ASSERT
规范文件结构一致
- READ 任务目录下所有文件 → ASSERT
来源标签使用一致 && 表格格式统一 && 引用块风格统一
IF 发现不一致 → 立即修复。
6.2 确保每位成员有复盘
READ 13-retrospective.md → EXEC git log --format='%an' | sort -u → ASSERT exit_code == 0 → IF 多位贡献者 → ASSERT 每位成员有独立复盘段落或独立文件。
文件 14：14-team.md
WRITE 14-team.md（模板见 references/14-team-template.md）：
## §一 角色分工
| 角色 | 负责人 | 职责 | 产出物 |
|------|--------|------|--------|
| {role} | {person} | {responsibility} | {deliverable} |
## §二 一致性检查
| 检查项 | 结果 | 修复动作 |
|--------|------|---------|
| 术语一致性 | ✅/❌ | {action} |
| 标题层级一致性 | ✅/❌ | {action} |
| commit 消息格式 | ✅/❌ | {action} |
## §三 个人贡献
| 贡献者 | 产出物 | 提交数 |
|--------|--------|--------|
| {contributor} | {deliverables} | {count} |
## §四 质量审查数据
| 维度 | 真实问题数 | P0 | P1 | P2 |
|------|-----------|----|----|-----|
| {dimension} | {count} | {n} | {n} | {n} |
IF 仅 1 位人类作者 → §一 角色分工填写"用户 + AI Agent 团队"，§三 将用户审查/确认决策也计入贡献，§四 正常填写 team-review 审查数据。
文件 15：15-brief.md
WRITE 15-brief.md（模板见 references/15-brief-template.md）：
## §一 Elevator Pitch
{3 句话：问题 → 方案 → 结果}
## §二 关键决策
| 决策点 | 选择 | 拒绝方案 | 理由 |
|--------|------|---------|------|
| {decision} | {chosen} | {rejected} | {why} |
## §三 AI 协作亮点
- {highlight_from_prompt_log_or_tdd_log}
## §四 测试覆盖概要
| 维度 | 用例数 | 通过 | 覆盖率 |
|------|--------|------|--------|
| {dimension} | {n} | {n} | {pct} |
## §五 遗留风险
- {risk_from_review}
## §六 改进承诺
- {commitment_from_retrospective}
填写方式：
- §一 Elevator Pitch：从
01-plan.md + 03-sdd.md + 10-test-report.md 提炼 3 句话
- §二 关键决策：从
08-ai-decisions.md 挑选 2-3 个最重要决策
- §三 AI 协作亮点：从
07-prompt-log.md 纠偏记录 + 06-tdd-log.md bug 发现中提取
- §四 测试覆盖概要：从
09-test-matrix.md + 10-test-report.md 提取
- §五 遗留风险：从
11-review.md §四 摘录
- §六 改进承诺：从
13-retrospective.md §三 摘录
WRITE checkpoint：current_step=Step 7, next_step=Step 7.3, phase=finish, completed_steps 追加 Step 6
Step 7：分支完成处理
确保所有技术工作在人类验收前就绪。用户验收时看到的应该是可交付状态，不是半成品。
READ 12-asset-update.md → IF CHANGELOG.md 需要更新但尚未更新 → 补全。
ROUTE team-finish：
- 传递 checkpoint 中的
branch 和 base_branch 信息
team-finish 将验证测试 → 展示集成选项（合并并推送/创建 PR/保留/丢弃）→ 执行用户选择
IF team-finish 报告测试不通过 → ROLLBACK team-impl（附失败详情），修复完成后 GOTO Step 7。
MATCH finish_result：
merge → ASSERT merge_commit EXISTSPR → ASSERT PR 已创建keep || discard → 记录用户决策- DEFAULT → ASK_HUMAN，请求用户选择分支处理方式
WRITE checkpoint：current_step=Step 7.3, next_step=Step 7.5, phase=finish, completed_steps 追加 Step 7
Step 7.3：HUMAN_ACCEPT 人类验收 + 分期决策
HUMAN_ACCEPT 是用户对整个交付物的最终确认，不可省略。展示内容必须让用户在不读代码的情况下做出有效判断。
GATE 协作文档完整性检查（进入 HUMAN_ACCEPT 前强制执行）：
IF mode == full：
- FOR
file IN [06-tdd-log.md, 07-prompt-log.md, 08-ai-decisions.md, 09-test-matrix.md, 10-test-report.md, 11-review.md, 12-asset-update.md, 13-retrospective.md, 14-team.md, 15-brief.md, task-rules.md]：
- ASSERT
{file} EXISTS && 有效行数 >= 5
- 任一不通过 → ROLLBACK 对应 Step（06-08 → Step 3；09-10 → Step 4；11-13/task-rules → Step 5；14-15 → Step 6），附缺失文件名
ELSE（mode == compact）：
- FOR
file IN [06-tdd-log.md, 07-prompt-log.md, 08-ai-decisions.md, 09-test-matrix.md, 10-test-report.md, 11-review.md, 12-asset-update.md, 13-retrospective.md, task-rules.md]：
- ASSERT
{file} EXISTS && 有效行数 >= 5
- 任一不通过 → ROLLBACK 对应 Step
WRITE（对话中）向用户展示：交付物清单 + 代码 diff 摘要。
- IF
mode == full → 还展示 14-team.md 和 15-brief.md 核心内容
- IF
mode == compact → 展示 11-review.md 审查结论 + 13-retrospective.md 改进承诺
IF docs/delivery-checklist.md EXISTS → READ 检查 - [ ] 项完成情况 → 未完成项列入 HUMAN_ACCEPT 展示，供用户判断。
MATCH user_decision：
验收通过 → WRITE checkpoint：completed_steps 追加 HUMAN_ACCEPT → GOTO Step 7.5验收不通过 → 根据反馈回退对应 Step（spec 问题 → GOTO Step 2；实现问题 → GOTO Step 3；测试问题 → GOTO Step 4；审查问题 → GOTO Step 5）后续分期 → IF 01-plan.md §二 定义了后续分期候选 → GOTO 7.3.1- DEFAULT → 请求用户明确决策
7.3.1：后续分期启动
用户验收通过后，如 01-plan.md 定义了后续分期候选，启动下一期任务。
-
WRITE（对话中）候选项 + 触发条件给用户
-
IF 用户批准：
- WRITE checkpoint：
phase=phasing, parent_slug={当前slug}, next_phase_n={N}
- GOTO Step 1（CONFIRM_GOAL 简化为单句确认；Step 1 的 RESOLVE
slug 将检测 checkpoint 中 parent_slug 触发分期任务分支，自动扫描目录生成新序号）
- team-spec 调度时额外传递上期
01-plan.md 候选表和 03-sdd.md 路径
ELSE → 记录用户决策，流程结束
Step 7.5：归档与知识合并
知识沉淀是任务的长期价值。可泛化规则必须合并到项目级规范，否则下个任务会重复踩坑。
- READ
docs/tasks/{slug}/task-rules.md → WRITE 标记为"可泛化"的规则到项目级/模块级 AI 规范文件
- IF 项目维护
docs/specs/ 目录 → WRITE 本次 03-sdd.md 关键规格合并进去
- IF 增量模式 → 执行 delta 合并（ADDED 追加、MODIFIED 替换、REMOVED 删除）
- IF 冲突 → 以本次 SDD 为准，在 commit message 中注明
- WRITE
docs/tasks/progress.md（注意是 docs/tasks/ 根目录）追加：
| {slug} | {YYYY-MM-DD} | `DONE` / `DONE_WITH_CONCERNS` | {起始commit..结束commit} | {一句话摘要} |
- IF 本次变更影响 AGENTS.md 架构描述 → WRITE 同步更新
进度账本模板（首次创建时使用）：
# 任务进度账本
> 跨 session 持久化，防止任务重复派发
| Slug | 日期 | 状态 | Commit 范围 | 摘要 |
| ---- | ---- | ---- | ----------- | ---- |
Step 8：最终质量检查
最终质量检查是流程的守门员。所有检查项必须基于新鲜执行结果，不可引用之前步骤的缓存输出。
SIGNAL：unchecked_items > 3 通常意味着某个 Agent 被跳过或产出不完整——不是逐条补全的问题，而是需要回退对应 Agent 重新执行。
RESOLVE mode（首个命中即停）：
READ("docs/tasks/{slug}/.checkpoint.json").mode- DEFAULT →
full
IF mode == compact：
[完整模式] 项跳过[精简替代] 项替换原项- D5 整组跳过
ELSE：
GATE 全部检查项通过才可声明质量检查通过：
硬门槛（7 项全部必须通过）：
D1 AI 协作资产沉淀（25 分）：
D2 AI 协作任务规划（25 分）：
D3 AI 交付质量保障（30 分）：
D4 AI 使用过程与复盘（10 分）：
D5 团队协作表现（10 分）：
IF mode == compact → D5 整组跳过。
IF unchecked_items > 0 → 回退对应 Step 补全（D1/D3 缺失 → GOTO Step 5；D2 缺失 → GOTO Step 2；D4 缺失 → GOTO Step 3；D5 缺失 → GOTO Step 6）。
全部通过 → WRITE checkpoint：status=DONE, completed_steps 追加 Step 7.5 和 Step 8。
此时且仅此时 status 设为 DONE（如有保留意见则设为 DONE_WITH_CONCERNS）。
STOP_SIGNALS
- 跳过 CONFIRM_GOAL 或 HUMAN_ACCEPT 人类介入点
- 使用 EnterPlanMode 或其他外部规划工具替代 STEPS 定义的有向图流程（plan mode 完成 ≠ CONFIRM_GOAL 完成）
- 延迟回退（"先记着后面一起修"）
- 信任 Agent 自我声明而不验证产出
- 超出预算不砍范围，或亲自执行实现代码而非 dispatch 子 Skill
CONSTITUTIONAL_RULES
REF _team-rules/constitutional-rules.md — 10 条 Constitutional Rules
REF _team-rules/first-principles.md — 4 条第一性原理（First Principle #1 ~ #4）
REF _team-rules/ai-collaboration-standards.md — AI 协作资产与 Prompt 工程规范
REF _team-rules/spec-driven-workflow.md — 有向图回退规则与回退次数上限
编排阶段尤其注意：
- Rule #1 人类介入是一等公民：CONFIRM_GOAL-HUMAN_ACCEPT 不可被任何 Agent 自动确认，"用户没回复就默认同意"是违规
_team-rules/first-principles.md: First Principle #1
- Rule #2 有向图回退：team-test/team-review 发现问题必须
ROLLBACK 对应 Agent，不可"先记着后面一起修" _team-rules/first-principles.md: First Principle #4
- Rule #7 回退次数上限：同一 source→target 对回退 ≤ 2 次，第 3 次强制触发
ASK_HUMAN _team-rules/first-principles.md: First Principle #1
- Rule #9 TDD 顺序不可逆：team-impl 完成后必须验证
06-tdd-log.md 中 RED 在 GREEN 之前 _team-rules/first-principles.md: First Principle #2
SELF_CHECK
GATE 产出前自检（全部通过才可声明完成）：
COMPLETION
REF _team-rules/four-state-protocol.md — 四态完成状态
MATCH result：
全流程完成 + 质量检查通过 → DONE（模式: {完整/精简}, 文件: {17/11}, 质量检查: pass）完成但有保留意见 → DONE_WITH_CONCERNS（concerns: [...]）缺少关键上下文 → NEEDS_CONTEXT被阻塞（Kill Switch / 人类决策）→ BLOCKED → ASK_HUMAN- DEFAULT → BLOCKED → ASK_HUMAN
INTEGRATION
被谁调用：
配对使用：
team-spec — REQUIRED：编排流程中必须调度规格制定team-impl — REQUIRED：编排流程中必须调度实现team-test — REQUIRED：编排流程中必须调度测试审计team-review — REQUIRED：编排流程中必须调度代码审查team-finish — 分支完成处理
NEXT
- 需要协作评分 → 使用
team-score 获取质量评分
- 开始下一个功能 → 使用
team-brainstorm 或 team-spec
