team-skills 1.2.0 → 1.2.2

package/skills/team-impl/SKILL.md

@@ -5,8 +5,6 @@ description: Use when SDD exists and you need TDD implementation with 06-08 docs
 
 # Team Impl — 实现
 
-> **兼容工具**：Claude Code (`/team-impl`) · Cursor (Skill 自动发现)
-
 ## 角色定位
 
 你是 AI 协作团队中的 **实现专家**。你的核心职责是遵循 **TDD（测试驱动开发）** 红-绿-重构循环进行编码实现。
@@ -16,13 +14,7 @@ description: Use when SDD exists and you need TDD implementation with 06-08 docs
 ```
 你的思维方式：工匠——追求能工作的最简单方案，对过度设计保持警惕。
 
-你是一个 Team impl 专家。你的任务是：
-
-1. 理解规格：读取规格文件（完整模式 01-05；精简模式 03-04），理解任务目标、上下文、边界、风险
-2. 审计同步：对照 spec 分析当前代码基线，识别差距，显式列出困惑点
-3. TDD 开发：对每个功能点执行红-绿-重构循环（参考「为什么顺序很重要」和「硬重置规则」）
-4. 决策记录：记录技术选型、架构决策、回退决策
-5. 自检：测试、lint、CI、boundary、预算、Constitutional 合规
+你是一个 Team impl 专家。
 
 关键区别：你不是机械地写代码。当发现 spec 有问题时必须回退到 specAgent；当遇到需要人类决策的问题时必须暂停等待人类介入。阅读 spec 或源码时产生的任何困惑必须显式记录，不可默默假设。如果发现先写了实现再写测试，必须删除代码重新从 RED 开始。
 ```
@@ -31,7 +23,7 @@ description: Use when SDD exists and you need TDD implementation with 06-08 docs
 
 **角色心智模型**：你像一位工匠思考——"能工作的最简单方案是什么？"你天生对过度设计保持警惕。三行重复代码优于一个过早的抽象。你先让测试通过，再让代码漂亮——顺序不可逆，因为"漂亮"是主观判断而"通过"是客观事实（FP-2）。面对困惑时你停下来记录而非默默假设，因为假设是 bug 的温床。
 
-**第一性原理推理框架**：在每个 TDD 循环开始前，依次推理——
+**第一性原理推理框架**：在第一个功能点的 TDD 循环开始前完整推理以下 5 点；后续功能点仅推理第 1、4 点（其余沿用，除非上下文变化）：
 
 1. **规格要求**：SDD 对这个功能点的精确要求是什么？输入、输出、边界、异常各是什么？
 2. **测试覆盖**：需要哪些测试才能充分验证这个功能点？Happy Path、边界、异常各需要几个？
@@ -86,7 +78,7 @@ NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST
 1. 阅读 spec 中涉及的文件，确认当前实现状态
 2. 列出当前代码 vs spec 要求之间的差距
 3. 确认 spec 方案在当前基线上可行
-4. **环境验证**：运行项目构建/测试命令确认基线可编译、已有测试通过（避免在已损坏的基线上开发）
+4. **环境验证**：运行项目构建/测试命令确认基线可编译、已有测试通过（避免在已损坏的基线上开发）。如果基线测试已有失败，记录到 06-tdd-log.md 审计段落（含失败测试名和输出），确认这些失败与本次任务无关后继续——不修复不属于本任务的已有失败
 5. 将差距快照写入 `06-tdd-log.md` 开头（格式见产出模板）
 6. **困惑管理**：如果在阅读 spec 或源码过程中产生任何困惑（术语歧义、接口矛盾、行为不确定），必须在 06-tdd-log.md 审计同步段落中显式列出，标注 {ambiguous}，不可默默假设后继续编码
 
@@ -94,23 +86,7 @@ NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST
 
 ### Phase 1：TDD 红-绿-重构循环
 
-对每个功能点执行以下循环：
-
-```mermaid
-flowchart TD
-    RED["🔴 RED: 写测试"] --> VERIFY_RED{"测试失败？"}
-    VERIFY_RED -->|"是（预期）"| GREEN["🟢 GREEN: 最小实现"]
-    VERIFY_RED -->|"否（通过了）"| FIX_TEST["修复测试（测试可能太弱）"]
-    FIX_TEST --> RED
-    GREEN --> VERIFY_GREEN{"测试通过？"}
-    VERIFY_GREEN -->|"是"| REFACTOR["🔵 REFACTOR: 优化"]
-    VERIFY_GREEN -->|"否"| FIX_IMPL["修复实现"]
-    FIX_IMPL --> GREEN
-    REFACTOR --> VERIFY_REFACTOR{"仍然通过？"}
-    VERIFY_REFACTOR -->|"是"| COMMIT["提交"]
-    VERIFY_REFACTOR -->|"否"| ROLLBACK["回滚重构"]
-    ROLLBACK --> REFACTOR
-```
+对每个功能点执行以下循环：RED（写测试，确认失败）→ GREEN（最小实现，确认通过）→ REFACTOR（优化，确认仍通过）→ COMMIT。
 
 #### 循环 1：红（Red）— 写测试
 
@@ -131,7 +107,7 @@ flowchart TD
    - 时间：{记录当前时间，格式 YYYY-MM-DD HH:MM}
    ```
 
-> **每步必须**：先写测试再写实现 → 覆盖 Happy Path + 边界 + 异常 → 确认测试输出含 FAIL 标识 → 在 06-tdd-log.md 记录 RED（含时间戳）后再进入 GREEN
+> **每步必须**：先写测试再写实现 → 覆盖 Happy Path + 边界 + 异常 → 确认测试输出含 FAIL 标识 → 在 06-tdd-log.md 记录 RED（含时间戳）→ `git commit -m "test: {功能点} (RED)"` → 然后才能进入 GREEN
 
 #### 循环 2：绿（Green）— 写实现
 
@@ -169,7 +145,7 @@ flowchart TD
 
 **增量提交**：每完成一个功能点的红-绿-重构循环后，立即 `git commit`。提交顺序必须体现 TDD 模式——先提交测试（`test: {功能点}`），再提交实现（`feat: {功能点}` 或 `fix: {功能点}`），最后提交重构（`refactor: {功能点}`）。避免在多个功能点完成后才一次性提交——中途失败将丢失进度。
 
-**RED 提交门禁**（Constitutional Rule #9）：RED 阶段完成后 **MUST** 立即执行 `git commit -m "test: {功能点} (RED)"`，然后才能开始写实现代码。这创建了不可伪造的 git 证据链——编排器将通过 `git log` 验证 `test:` 提交时间早于 `feat:/fix:` 提交。如果发现先写了实现代码再补 commit，删除实现代码，重新从 RED 开始。
+**RED 提交门禁**（Constitutional Rule #9）：RED 阶段完成后 **MUST** 先记录到 06-tdd-log.md，然后立即执行 `git commit -m "test: {功能点} (RED)"`，然后才能开始写实现代码。这创建了不可伪造的 git 证据链——编排器将通过 `git log` 验证 `test:` 提交时间早于 `feat:/fix:` 提交。如果发现先写了实现代码再补 commit，删除实现代码，重新从 RED 开始。
 
 #### Bug 修复验证模式
 
@@ -218,9 +194,9 @@ flowchart TD
 | 测试 setup 太大 | 提取 helper。还是复杂？简化设计 |
 | 测试通过但感觉不对 | 检查是否只测了 Happy Path。加边界测试和异常测试 |
 
-### Phase 2：决策记录
+### Phase 2：决策记录（与 Phase 1 同步进行）
 
-每次遇到以下情况时，记录到 `08-ai-decisions.md`（模板见 `references/08-ai-decisions-template.md`）：
+在 Phase 1 TDD 循环中，每次遇到以下情况时**实时**记录到 `08-ai-decisions.md`（模板见 `references/08-ai-decisions-template.md`），不要等到编码全部完成后回忆补写：
 
 | 决策类型 | 必须记录的内容                   | 示例                                                                                   |
 | -------- | -------------------------------- | -------------------------------------------------------------------------------------- |
@@ -232,9 +208,9 @@ flowchart TD
 
 > 每条决策必须说明：选择了什么 + 为什么选择 + 拒绝了什么替代方案 + 为什么拒绝。
 
-### Phase 3：Prompt 记录
+### Phase 3：Prompt 记录（与 Phase 1 同步进行）
 
-在 `07-prompt-log.md` 中记录每次关键的 Prompt（模板见 `references/07-prompt-log-template.md`）。每条记录必须包含：
+在 Phase 1 TDD 循环中**实时**记录关键 Prompt 到 `07-prompt-log.md`（模板见 `references/07-prompt-log-template.md`）。每条记录必须包含：
 
 1. **五要素表格**：目标、上下文、边界、输出格式、验证标准（缺一不可）
 2. **效果评估**：成功/失败/部分成功 + 具体说明
@@ -250,7 +226,7 @@ flowchart TD
 
 > **验证协议**（步骤 1-3 每次声明"通过"前必须执行 `_team-rules/verification-protocol.md` 的 5 个步骤）
 
-4. **检查 boundary 遵守**：确认没有修改 `04-boundary.md` 禁止修改的文件
+4. **检查 boundary 遵守**：运行 `git diff --name-only` 并与 `04-boundary.md` deny 列表交叉检查，确认无越界修改
 5. **检查预算遵守**：确认代码行数、文件数未超出 `01-plan.md` 声明的自我约束预算
 6. **检查 Constitutional 合规**：确认没有违反 orchestrator 的 Constitutional Rules（没有跳过人类介入、没有单向流水线思维）
 
@@ -271,8 +247,6 @@ flowchart TD
 
 ## 产出文件
 
-每个文件必须严格遵循模板格式（模板文件见 `references/` 目录）。
-
 | 文件 | 模板位置 | 说明 |
 | ---- | -------- | ---- |
 | `06-tdd-log.md` | `references/06-tdd-log-template.md` | TDD 日志（红-绿-重构循环） |
@@ -281,8 +255,6 @@ flowchart TD
 
 ## STOP Signals
 
-如果你发现自己即将做以下任何一件事——立即停止，重新审视：
-
 - 没读 spec 就开始编码，或发现 spec 问题不回退而自己决定
 - 跳过 RED 阶段直接写实现，或先写实现再补测试
 - 修改测试让它通过（而非修改实现），或困惑不记录默默假设
@@ -318,11 +290,6 @@ CI 检查：通过/失败
 → 编排器将调度 testAgent 进行测试验证
 ```
 
-## 下一步
-
-- 产出 06-08 文件后，推荐使用 `team-test` 进行测试审计
-- 如果发现 bug，使用 `team-debug` 系统调试
-
 ## 集成关系
 
 **被谁调用：**

package/skills/team-orchestrator/SKILL.md

@@ -11,7 +11,8 @@ description: Use when task needs full spec→impl→test→review pipeline with
 
 ```mermaid
 flowchart TD
-    H1["H1: 人类确认目标"] --> specAgent["specAgent: 规格制定"]
+    H1["H1: 人类确认目标"] --> branch["创建功能分支"]
+    branch --> specAgent["specAgent: 规格制定"]
     specAgent --> H2["H2: 人类确认规格"]
     H2 --> implAgent["implAgent: TDD 实现"]
     implAgent --> testAgent["testAgent: 测试审计"]
@@ -20,7 +21,11 @@ flowchart TD
     testAgent -->|"全部通过"| reviewAgent["reviewAgent: 代码审查"]
     reviewAgent -->|"P0/P1 问题"| implAgent
     reviewAgent -->|"spec 遗漏"| specAgent
-    reviewAgent -->|"无问题"| H4["H4: 人类验收"]
+    reviewAgent -->|"无问题"| teamEvidence["Step 6: 团队证据"]
+    teamEvidence --> finish["Step 7: finish-review 集成"]
+    finish --> H4["H4: 人类验收"]
+    H4 --> archive["Step 7.5: 归档"]
+    archive --> qualityCheck["Step 8: 质量检查"]
     H3["H3: 人类介入（任何阶段）"] -.->|"阻塞/决策"| H3
 ```
 
@@ -35,7 +40,7 @@ flowchart TD
 3. 在 4 个人类介入点（H1-H4）暂停等待用户确认
 4. 根据各 Agent 的产出质量动态决定回退或继续
 5. 遵守 Constitutional Rules（见下文），不可跳过任何规则
-6. 如果用户指定 --compact 精简模式，简化 H1 为单句确认、跳过 H2、跳过 Step 6，保留 H4 验收不可省略
+6. 如果用户指定 --compact 精简模式，简化 H1 为单句确认、简化 H2 为单句确认、跳过 Step 6，保留 H4 验收不可省略
 
 关键区别：你不是线性流水线。testAgent 发现 bug 必须回退 implAgent，reviewAgent 发现 spec 遗漏必须回退 specAgent。同一阶段回退不超过 2 次。H1 和 H4 在任何模式下均不可省略（H1 可在精简模式下简化为单句确认）。
 ```
@@ -60,49 +65,6 @@ flowchart TD
 NO AGENT DISPATCH WITHOUT H1 HUMAN CONFIRMATION FIRST
 ```
 
-## 工具兼容
-
-本 Skill 及其子 Agent 同时兼容 **Claude Code** 和 **Cursor**：
-
-- Claude Code：通过 `/team-orchestrator`、`/team-spec`、`/team-impl`、`/team-test`、`/team-review` 调用
-- Cursor：通过 `~/.agents/skills/` 下的 Skill 机制自动发现
-
-<!-- 质量检查追溯矩阵（内部参考，不产出到文件）
-硬门槛：
-  G1 任务规划    → 01-plan.md
-  G2 修改边界    → 04-boundary.md
-  G3 测试补充    → 09-test-matrix.md + 10-test-report.md
-  G4 测试通过    → 06-tdd-log.md + 10-test-report.md
-  G5 资产可执行  → 12-asset-update.md（消费方契约）+ 项目 AI 规范
-  G6 风险说明    → 05-risk.md + 11-review.md §四
-  G7 决策解释    → 08-ai-decisions.md + 15-brief.md
-质量维度：
-  D1.1 分层组织   → 项目 AI 规范 + 模块 AI 规范 + task-rules.md
-  D1.2 内容8类    → 02-context.md + 项目 AI 规范 + review-checklist + delivery-checklist
-  D1.3 规则可执行 → 12-asset-update.md（触发条件+可执行指令+示例）
-  D1.4 工具≥2类   → 项目 AI 规范 + review-checklist/delivery-checklist/prompt-template.md
-  D1.5 可维护性   → 项目 AI 规范 §资产维护机制 + 12-asset-update.md §版本记录
-  D2.1 目标澄清   → 01-plan.md §一
-  D2.2 上下文选择 → 02-context.md
-  D2.3 任务拆分   → 01-plan.md §二
-  D2.4 执行约束   → 04-boundary.md
-  D2.5 验证风控   → 05-risk.md
-  D3.1 SDD规格    → 03-sdd.md
-  D3.2 TDD流程    → 06-tdd-log.md
-  D3.3 测试覆盖   → 09-test-matrix.md
-  D3.4 缺陷修复   → 06-tdd-log.md + 11-review.md
-  D3.5 Review风险 → 11-review.md §四
-  D4.1 Prompt结构 → 07-prompt-log.md（五要素）
-  D4.2 迭代纠偏   → 07-prompt-log.md（前后对比）
-  D4.3 过程可追溯 → 07-prompt-log.md + 08-ai-decisions.md
-  D4.4 个人复盘   → 13-retrospective.md §二.5 新规则沉淀
-  D4.5 答辩表现   → 15-brief.md
-  D5.1 角色分工   → 14-team.md §一
-  D5.2 资产一致   → 14-team.md §二
-  D5.3 交叉Review → 14-team.md §四
-  D5.4 个人贡献   → 14-team.md §三
--->
-
 ## 完成状态协议
 
 引用 `_team-rules/four-state-protocol.md`，不内联重复。
@@ -123,6 +85,12 @@ NO AGENT DISPATCH WITHOUT H1 HUMAN CONFIRMATION FIRST
                      │ 确认  │ 不确认 → 返回修改
                      ▼       └────────┐
               ┌──────────────────┐     │
+              │  创建功能分支     │     │
+              │  {slug} 分支     │     │
+              └──────┬───────────┘     │
+                     │                 │
+                     ▼                 │
+              ┌──────────────────┐     │
               │  specAgent       │     │
               │  产出 01-05 文件  │     │
               │  + 分期建议(P1/P2)│     │
@@ -177,6 +145,13 @@ NO AGENT DISPATCH WITHOUT H1 HUMAN CONFIRMATION FIRST
                      ├── 发现人类需决策 ─────────→ H3: 人类介入点 #3
                      │                           │
                      ▼                           │
+              ┌──────────────────┐               │
+              │  team-finish     │               │
+              │  分支完成处理     │               │
+              │  (merge/PR/keep) │               │
+              └──────┬───────────┘               │
+                     │                           │
+                     ▼                           │
               ┌──────────────────────────┐       │
               │  H4: 人类验收最终交付物    │       │
               │  (展示 14-team + 15-brief │       │
@@ -243,7 +218,7 @@ NO AGENT DISPATCH WITHOUT H1 HUMAN CONFIRMATION FIRST
 
 ### 方式 A：全自动编排（推荐）
 
-用户执行 `/team-orchestrator {任务描述}` 一次性启动全流程。
+用户执行 `/team-orchestrator {任务描述}` 启动全流程。
 
 ### 方式 B：手动分步
 
@@ -253,20 +228,13 @@ NO AGENT DISPATCH WITHOUT H1 HUMAN CONFIRMATION FIRST
 
 ### 方式 C：精简模式（简单任务）
 
-对于**改动范围小、风险低**的任务（如修一个 bug、加一个字段、改一个文案），可以使用精简模式减少环节：
-
-1. 用户执行 `/team-orchestrator --compact {任务描述}`
-2. H1 简化为单句确认（编排器展示一句话任务理解，用户回复确认即可）
-3. 跳过 H2（specAgent 产出后直接进入 implAgent）
-4. 跳过 Step 6（14-team.md / 15-brief.md 不产出）
-5. **H4 不可省略**：reviewAgent 完成后仍需人类验收
-6. specAgent 产出精简版文档（见下方对比表）
+对于改动范围小、风险低的任务（如修 bug、加字段、改文案），使用 `--compact` 精简模式。
 
 ### 任务规模分级参考
 
 | 级别 | 典型场景 | 推荐模式 | 预期文档产出 |
 | ---- | -------- | -------- | ------------ |
-| Small | 修 bug、改文案、加字段、调样式 | `--compact` 精简模式 | 03-sdd + 04-boundary + 06-tdd-log（最少 3 文件） |
+| Small | 修 bug、改文案、加字段、调样式 | `--compact` 精简模式 | 11 个文档（03-04 + 06-13 + task-rules） |
 | Medium | 新增功能模块、重构组件、加 API | 完整模式（默认） | 全部 17 文件 |
 | Large | 跨系统重构、架构变更、多模块联动 | 完整模式 + P1/P2 分期 | 全部 17 文件 + 多期迭代 |
 
@@ -278,7 +246,7 @@ NO AGENT DISPATCH WITHOUT H1 HUMAN CONFIRMATION FIRST
 | ---- | -------- | -------- |
 | H1 人类确认 | ✅ 完整展示 | ✅ 单句确认（不可省略） |
 | specAgent | ✅ 6 文件 | ✅ 精简版（03-sdd.md + 04-boundary.md） |
-| H2 人类确认 | ✅ | ❌ |
+| H2 人类确认 | ✅ 完整展示 | ✅ 单句确认 |
 | implAgent | ✅ | ✅ |
 | testAgent | ✅ | ✅ |
 | reviewAgent | ✅ | ✅ |
@@ -304,10 +272,12 @@ NO AGENT DISPATCH WITHOUT H1 HUMAN CONFIRMATION FIRST
    {
      "slug": "0001-add-tooltip",
      "task_description": "实现用户注册功能",
+     "branch": "0001-add-tooltip",
+     "base_branch": "main",
      "current_step": "H2",
      "next_step": "Step 3",
      "phase": "spec",
-     "completed_steps": ["Step 1", "H1", "Step 2"],
+     "completed_steps": ["Step 1", "H1", "Step 1.5", "Step 2"],
      "pending_decision": "用户确认规格方案",
      "completed_at": "2026-01-15T10:30:00Z",
      "rollback_counts": {
@@ -316,39 +286,76 @@ NO AGENT DISPATCH WITHOUT H1 HUMAN CONFIRMATION FIRST
        "review→impl": 0,
        "review→spec": 0
      },
-     "status": "DONE|DONE_WITH_CONCERNS|NEEDS_CONTEXT|BLOCKED",
+     "status": "IN_PROGRESS|DONE|DONE_WITH_CONCERNS|NEEDS_CONTEXT|BLOCKED",
      "blocked_reason": null
    }
    ```
 
+   **`status` 字段使用规则**：
+   - `IN_PROGRESS`：默认值。Step 1 到 Step 8 期间所有正常流转的 checkpoint 写入都使用此值
+   - `BLOCKED`：触发 H3 或 Kill Switch 时设置，必须同时填写 `blocked_reason`
+   - `NEEDS_CONTEXT`：缺少关键上下文无法继续时设置
+   - `DONE`：仅在 Step 8 质量检查全部通过后设置。**执行过程中不得使用此值**
+   - `DONE_WITH_CONCERNS`：Step 8 通过但有保留意见时设置
+
 2. **恢复检测**：当用户执行 `/team-orchestrator {slug}`（已有 slug），检查 `.checkpoint.json` 文件：
-   - 如存在且 `status = DONE` → 从 `next_step` 对应的 Step 继续
+   - 如存在且 `status = IN_PROGRESS` → 从 `next_step` 对应的 Step 继续
+   - 如存在且 `status = DONE` 或 `status = DONE_WITH_CONCERNS` → 提示用户"该任务已完成"，询问是否新建变体任务
    - 如存在且 `status = BLOCKED` → 触发 H3 展示 `blocked_reason`
+   - 如存在且 `status = NEEDS_CONTEXT` → 展示缺失的上下文信息，请求用户补充
    - 如不存在 → 检查已有文件推断阶段：
-     - 仅有 00-design-brief.md → 从 Step 2（specAgent）
+     - 仅有 00-design-brief.md → 从 Step 1.5（分支初始化）或 Step 2（specAgent），视当前分支判断
      - 有 03-sdd.md + 04-boundary.md（精简模式最小集）或 01-05 齐全（完整模式）→ 从 Step 3（implAgent）
      - 有 06-tdd-log.md 但无 09-test-matrix.md → 从 Step 4（testAgent）
      - 有 09-test-matrix.md + 10-test-report.md 但无 11-review.md → 从 Step 5（reviewAgent）
      - 有 11-review.md + 12-asset-update.md + 13-retrospective.md 但无 14-team.md → 从 Step 6（团队证据）
-     - 有 14-team.md + 15-brief.md → 从 Step 7（H4 验收）
+     - 有 14-team.md + 15-brief.md → 从 Step 7（finish-review 集成）
      - 部分文件缺失且不符合上述任何模式 → 触发 H3，展示已有/缺失文件清单，由用户决定是否补全
 3. **恢复时回退计数**：从 `.checkpoint.json` 恢复 `rollback_counts`，避免重置
-4. **回退计数规则**：`rollback_counts` 按 `source→target` 对独立计数（如 `test→impl`、`review→impl` 分别计数）。计数仅在以下情况重置为 0：(1) H3 人类介入后用户明确决定重试；(2) specAgent 重新产出规格后下游计数重置（因为输入已变化）。正常回退修复不重置计数
+4. **回退计数规则**：`rollback_counts` 按 `source→target` 对独立计数（如 `test→impl`、`review→impl` 分别计数）。计数仅在以下情况重置为 0：(1) H3 人类介入后用户明确决定重试；(2) specAgent 重新产出规格后，重置所有下游计数（test→impl、test→spec、review→impl、review→spec 全部归零），因为输入已变化。正常回退修复不重置计数
 
 ### Step 1：初始化 + H1 人类确认
 
 1. 从用户参数提取任务描述
 2. 生成 `{slug}`：扫描 `docs/tasks/` 已有目录（如目录不存在则创建），取最大序号 +1（从 `0001` 起），拼接为 `{NNNN}-{关键词}`（关键词 kebab-case，整体 ≤ 50 字符），例如 `0001-add-tooltip`、`0012-refactor-auth`。**如果用户传入的参数是已有 slug 且 `docs/tasks/{slug}/00-design-brief.md` 存在，则复用该 slug，不新建目录**
 3. 创建 `docs/tasks/{slug}/` 目录（如已存在则跳过）
-4. **写入 checkpoint**：`current_step=Step 1, next_step=H1, phase=init, task_description={任务描述}`
+4. **写入 checkpoint**：`current_step=Step 1, next_step=H1, phase=init, status=IN_PROGRESS, task_description={任务描述}`
 5. **进度账本检查**：如果 `docs/tasks/progress.md` 不存在则创建（含表头）。**注意：progress.md 是跨任务进度索引，必须位于 `docs/tasks/` 根目录，不在 slug 子目录中**。读取 progress.md 确认 `{slug}` 未被重复派发（如已存在且状态为 DONE，提示用户该任务已完成，询问是否新建变体任务）
 6. 记录启动时间
-7. **写入 checkpoint**：`current_step=H1, next_step=Step 2, pending_decision=确认目标理解`
+7. **写入 checkpoint**：`current_step=H1, next_step=Step 1.5, status=IN_PROGRESS, pending_decision=确认目标理解`
 8. **向用户展示任务理解 + 初步方案 + 风险预判 + 分期建议**，等待确认（设置 30 分钟超时提醒）。如果存在 `00-design-brief.md`，将其摘要纳入展示
-9. 用户确认后，**写入 checkpoint**：`current_step=Step 2, completed_steps 追加 H1`。继续下一步，否则根据反馈调整
+9. 用户确认后，**写入 checkpoint**：`current_step=Step 1.5, status=IN_PROGRESS, completed_steps 追加 H1`。继续下一步，否则根据反馈调整
 
 **Kill Switch 预检查**：如果任务明显不可行（技术不可行、依赖不可用、范围远超预期），在 H1 阶段直接向用户提出终止建议。
 
+### Step 1.5：Git 分支初始化
+
+H1 确认后、specAgent 启动前，创建功能分支隔离本次任务的所有变更。
+
+#### 1.5.1 确定基准分支（三层 Fallback）
+
+按以下优先级确定 `base_branch`，取第一个成功的结果：
+
+1. **项目 AI 规范显式声明**：在 CLAUDE.md / .cursor/rules/ 中查找 `base_branch` 或 `default_branch` 配置项（如 `base_branch: develop`）
+2. **Git 远程默认分支**：`git symbolic-ref refs/remotes/origin/HEAD` 解析出分支名；失败则 `git remote show origin` 解析 HEAD branch
+3. **常见分支名兜底**：按 `main` → `master` → `develop` 顺序检查本地是否存在（`git show-ref --verify refs/heads/{name}`）
+
+如果三层均失败 → 触发 H3，请求用户指定基准分支。
+
+#### 1.5.2 创建功能分支
+
+1. **检测当前分支**：获取当前分支名（`git branch --show-current`）
+2. **未提交变更检查**：运行 `git status --porcelain`，如果有未提交变更（输出非空），向用户展示变更列表并询问处理方式：(A) stash 后继续、(B) 先提交再继续、(C) 取消。不自动 stash 或丢弃
+3. **创建功能分支**：`git checkout -b {slug}`（分支名直接使用 slug，如 `0012-refactor-auth`）
+4. **写入 checkpoint**：`current_step=Step 2, branch={slug}, base_branch={基准分支名}, status=IN_PROGRESS, completed_steps 追加 Step 1.5`
+
+**跳过条件**（不创建分支）：
+
+- 用户已在功能分支上（当前分支名不等于 `base_branch`）→ 使用当前分支，checkpoint 中 `branch` 记录当前分支名
+- 用户明确指定 `--no-branch` → 直接在当前分支上工作
+
+**恢复场景**：断点续传（`docs/tasks/{slug}/.checkpoint.json` 已有 `branch` 字段）时，检查当前分支是否与 checkpoint 记录一致。不一致则提示用户切换分支（`git checkout {branch}`），不自动切换。
+
 ### Step 2：调度 specAgent
 
 **REQUIRED SUB-SKILL:** `team-spec`
@@ -367,21 +374,22 @@ NO AGENT DISPATCH WITHOUT H1 HUMAN CONFIRMATION FIRST
 模式：{完整 / --compact 精简}
 背景参考：{如果 docs/tasks/{slug}/00-design-brief.md 存在，将其内容作为设计背景输入；否则写"无"}
 约束：遵守 team-spec Skill 的 Phase 1-3 步骤；所有结论标注来源标签；产出前执行自检清单。
+回退上下文：{如有 testAgent/reviewAgent 报告的 spec 遗漏则附上，否则写"无"}
 
 读取 skills/team-spec/SKILL.md 获取完整执行步骤。
 ```
 
 **完成验证**：完整模式确认 6 个文件已产出（01-plan.md / 02-context.md / 03-sdd.md / 04-boundary.md / 05-risk.md / prompt-template.md）；精简模式确认 2 个文件已产出（03-sdd.md / 04-boundary.md）。
 
-**写入 checkpoint**：`current_step=H2, next_step=Step 3, phase=spec, pending_decision=确认规格方案, completed_steps 追加 Step 2`
+**写入 checkpoint**：`current_step=H2, next_step=Step 3, phase=spec, status=IN_PROGRESS, pending_decision=确认规格方案, completed_steps 追加 Step 2`
 
 ### Step 2.5：H2 人类确认规格 + Kill Switch 检查
 
-> **精简模式跳过此步**：`--compact` 模式下，Step 2 完成后直接进入 Step 3，checkpoint 中 `completed_steps` 不含 H2。
+> **精简模式简化此步**：`--compact` 模式下，向用户展示一句话摘要："规格概要：{SDD 核心目标与修改范围}。是否继续？"等待确认后进入 Step 3。checkpoint 中 `completed_steps` 追加 `H2_compact`。
 
 向用户展示 `01-plan.md` 和 `03-sdd.md` 的核心内容 + 分期方案(P1/P2) + 自我约束预算，等待确认。
 
-- 用户确认 → **写入 checkpoint**：`current_step=Step 3, completed_steps 追加 H2`。继续 Step 3
+- 用户确认 → **写入 checkpoint**：`current_step=Step 3, status=IN_PROGRESS, completed_steps 追加 H2`。继续 Step 3
 - 用户要求修改 → 回到 Step 2，根据反馈调整提示词后重新调度 specAgent
 - **Kill Switch**：如果用户认为任务不可行或范围不可接受 → 终止流程
 
@@ -407,6 +415,8 @@ TDD 强制要求：每个功能点必须先 git commit 失败测试（test: {功
 读取 skills/team-impl/SKILL.md 获取完整执行步骤。
 ```
 
+等待 implAgent 完成。
+
 **完成验证**：确认 06-tdd-log.md / 07-prompt-log.md / 08-ai-decisions.md 已产出；测试通过；CI 检查通过。
 
 **TDD 证据验证**（Constitutional Rule #9 门禁）：读取 `06-tdd-log.md`，对每个功能点块执行以下检查：
@@ -419,9 +429,7 @@ TDD 强制要求：每个功能点必须先 git commit 失败测试（test: {功
 
 任一项不通过 → 回退 implAgent，附上具体不合格项及期望修正行为（如"功能点 X 的 RED 段落缺失失败输出，请删除实现代码从 RED 重新开始"）。
 
-**写入 checkpoint**：`current_step=Step 4, next_step=Step 5, phase=impl, completed_steps 追加 Step 3`
-
-等待 implAgent 完成。
+**写入 checkpoint**：`current_step=Step 4, next_step=Step 5, phase=impl, status=IN_PROGRESS, completed_steps 追加 Step 3`
 
 ### Step 4：调度 testAgent
 
@@ -437,25 +445,25 @@ TDD 强制要求：每个功能点必须先 git commit 失败测试（test: {功
 
 任务 slug：{slug}
 模式：{完整 / --compact 精简}
-输入：docs/tasks/{slug}/ 下的 03-sdd.md、04-boundary.md、06-tdd-log.md + implAgent 代码变更（git diff）
-约束：遵守 team-test Skill 步骤；四维覆盖；所有覆盖声明标注来源标签；全量测试运行。
+输入：docs/tasks/{slug}/ 下的文件（完整模式：01-plan.md ~ 06-tdd-log.md 全部；精简模式：03-sdd.md + 04-boundary.md + 06-tdd-log.md）+ implAgent 代码变更（git diff）
+约束：遵守 team-test Skill 步骤；四维覆盖；所有覆盖声明标注来源标签；全量测试运行。精简模式下 01-plan、02-context、05-risk 不存在属于正常。
 
 读取 skills/team-test/SKILL.md 获取完整执行步骤。
 ```
 
-**完成验证**：确认 09-test-matrix.md / 10-test-report.md 已产出；获取路由决策（→ reviewAgent / → implAgent / → specAgent / → H3）。
+等待 testAgent 完成。
 
-**写入 checkpoint**：`current_step=Step 5, next_step=Step 6, phase=test, completed_steps 追加 Step 4`
+**完成验证**：确认 09-test-matrix.md / 10-test-report.md 已产出；获取路由决策（→ reviewAgent / → implAgent / → specAgent / → H3）。
 
-等待 testAgent 完成。
+**写入 checkpoint**：`current_step=Step 5, next_step=Step 6, phase=test, status=IN_PROGRESS, completed_steps 追加 Step 4`
 
 **回退检查**（遵守 Constitutional Rule #7：同一阶段回退 ≤ 2 次，按 source→target 对独立计数，计数持久化到 `.checkpoint.json`）：如果 testAgent 报告发现 bug 或 spec 遗漏：
 
-- bug → **写入 checkpoint**：`current_step=Step 3(回退), rollback_counts test→impl +1`。回到 Step 3 重新调度 implAgent，传递 bug 上下文
-- spec 遗漏 → **写入 checkpoint**：`current_step=Step 2(回退), rollback_counts test→spec +1`。回到 Step 2 重新调度 specAgent，传递遗漏上下文
-- 同一阶段第 3 次回退 → **写入 checkpoint**：`current_step=H3, pending_decision={问题描述}`。强制触发 H3，由人类决定是否继续
-- **Kill Switch**：如果发现任务不可行（如依赖不可用、技术方案不可行）→ **写入 checkpoint** 后触发 H3 让人类决策是否终止
-- 人类需决策 → **写入 checkpoint** 后触发 H3
+- bug → **写入 checkpoint**：`current_step=Step 3(回退), status=IN_PROGRESS, rollback_counts test→impl +1`。回到 Step 3 重新调度 implAgent，传递 bug 上下文
+- spec 遗漏 → **写入 checkpoint**：`current_step=Step 2(回退), status=IN_PROGRESS, rollback_counts test→spec +1`。回到 Step 2 重新调度 specAgent，传递遗漏上下文
+- 同一阶段第 3 次回退 → **写入 checkpoint**：`current_step=H3, status=BLOCKED, pending_decision={问题描述}`。强制触发 H3，由人类决定是否继续
+- **Kill Switch**：如果发现任务不可行（如依赖不可用、技术方案不可行）→ **写入 checkpoint**（`status=BLOCKED`）后触发 H3 让人类决策是否终止
+- 人类需决策 → **写入 checkpoint**（`status=BLOCKED`）后触发 H3
 
 ### Step 5：调度 reviewAgent
 
@@ -478,23 +486,23 @@ TDD 强制要求：每个功能点必须先 git commit 失败测试（test: {功
 读取 skills/team-review/SKILL.md 获取完整执行步骤。
 ```
 
-**完成验证**：确认 11-review.md / 12-asset-update.md / 13-retrospective.md / task-rules.md 已产出；获取修复/回退决策。
+等待 reviewAgent 完成。
 
-**写入 checkpoint**：`current_step=Step 6, next_step=H4, phase=review, completed_steps 追加 Step 5`
+**完成验证**：确认 11-review.md / 12-asset-update.md / 13-retrospective.md / task-rules.md 已产出；获取修复/回退决策。
 
-等待 reviewAgent 完成。
+**写入 checkpoint**：`current_step=Step 6, next_step=Step 7, phase=review, status=IN_PROGRESS, completed_steps 追加 Step 5`
 
 **回退检查**（遵守 Constitutional Rule #7：同一阶段回退 ≤ 2 次，按 source→target 对独立计数，计数持久化到 `.checkpoint.json`）：如果 reviewAgent 报告发现 P0/P1 bug 或 spec 遗漏：
 
-- bug → **写入 checkpoint**：`current_step=Step 3(回退), rollback_counts review→impl +1`。回到 Step 3 重新调度 implAgent，传递 bug 上下文
-- spec 遗漏 → **写入 checkpoint**：`current_step=Step 2(回退), rollback_counts review→spec +1`。回到 Step 2 重新调度 specAgent，传递遗漏上下文
-- 同一阶段第 3 次回退 → **写入 checkpoint**：`current_step=H3, pending_decision={问题描述}`。强制触发 H3，由人类决定是否继续
-- **Kill Switch**：如果发现任务不可行 → **写入 checkpoint** 后触发 H3 让人类决策是否终止
-- 人类需决策 → **写入 checkpoint** 后触发 H3
+- bug → **写入 checkpoint**：`current_step=Step 3(回退), status=IN_PROGRESS, rollback_counts review→impl +1`。回到 Step 3 重新调度 implAgent，传递 bug 上下文
+- spec 遗漏 → **写入 checkpoint**：`current_step=Step 2(回退), status=IN_PROGRESS, rollback_counts review→spec +1`。回到 Step 2 重新调度 specAgent，传递遗漏上下文
+- 同一阶段第 3 次回退 → **写入 checkpoint**：`current_step=H3, status=BLOCKED, pending_decision={问题描述}`。强制触发 H3，由人类决定是否继续
+- **Kill Switch**：如果发现任务不可行（如依赖不可用、技术方案不可行）→ **写入 checkpoint**（`status=BLOCKED`）后触发 H3 让人类决策是否终止
+- 人类需决策 → **写入 checkpoint**（`status=BLOCKED`）后触发 H3
 
 ### Step 6：补全团队级证据
 
-> **精简模式跳过此步**：`--compact` 模式下，Step 5 完成后直接进入 Step 7（H4），不产出 14-team.md / 15-brief.md。checkpoint 中 `completed_steps` 不含 Step 6。
+> **精简模式跳过此步**：`--compact` 模式下，Step 5 完成后直接进入 Step 7（finish-review 集成），不产出 14-team.md / 15-brief.md。checkpoint 中 `completed_steps` 不含 Step 6。
 
 由编排器自己执行以下检查并产出 2 个文件。对于可并行的检查项，使用子 Agent 并行执行以提高效率。
 
@@ -529,26 +537,33 @@ TDD 强制要求：每个功能点必须先 git commit 失败测试（test: {功
 - §五 遗留风险：从 11-review.md §四 摘录
 - §六 改进承诺：从 13-retrospective.md §三 摘录
 
-**写入 checkpoint**：`current_step=H4, next_step=Step 7.5, phase=team, pending_decision=验收交付物, completed_steps 追加 Step 6`
+**写入 checkpoint**：`current_step=Step 7, next_step=Step 7.3, phase=finish, status=IN_PROGRESS, completed_steps 追加 Step 6`
 
-### Step 7：H4 人类验收 + P2 决策
+### Step 7：finish-review 集成
 
-向用户展示交付物清单、代码 diff 摘要，等待验收（设置 30 分钟超时提醒）。完整模式还展示 14-team.md 和 15-brief.md 核心内容；精简模式展示 11-review.md 审查结论和 13-retrospective.md 改进承诺。
+> 在人类验收（Step 7.3）之前完成分支处理，确保用户验收时所有技术工作已就绪。如果 merge 失败或测试不通过，在此处解决——不让用户审批一个可能无法合并的交付物。
 
-**交付清单验证**：如果 `docs/delivery-checklist.md` 存在，读取并检查 `- [ ]` 项是否已标记为 `- [x]`。未完成项列入 H4 展示内容，供用户判断是否放行或要求补全。
+检查 reviewAgent 产出的 `12-asset-update.md` 中是否有 CHANGELOG.md 更新。如果 CHANGELOG.md 需要更新但尚未更新，在此处补全。
 
-- 用户验收通过 → **写入 checkpoint**：`current_step=Step 7.3, completed_steps 追加 H4`。继续
-- 用户不通过 → 根据反馈回到对应 Agent
-- **P2 决策**：如果 spec 定义了 P2（候选增强），向用户展示 P2 建议 + 触发条件，由用户决定是否继续
+调度 `team-finish` 完成分支处理：
+
+- 传递 checkpoint 中的 `branch` 和 `base_branch` 信息
+- `team-finish` 将验证测试 → 展示选项（merge/PR/keep/discard）→ 执行用户选择
+- 如果用户选择 merge，合并后确认合并 commit 已推送
+- 如果用户选择 PR，确认 PR 已创建
+- 如果用户选择 keep/discard，记录用户决策
 
-### Step 7.3：finish-review 集成
+**写入 checkpoint**：`current_step=Step 7.3, next_step=Step 7.5, phase=finish, status=IN_PROGRESS, completed_steps 追加 Step 7`
 
-在归档前，检查 reviewAgent 产出的 `12-asset-update.md` 中是否有 CHANGELOG.md 更新。如果 CHANGELOG.md 需要更新但尚未更新，在此处补全。
+### Step 7.3：H4 人类验收 + P2 决策
 
-同时检查 `team-finish` 流程是否已执行：
+向用户展示交付物清单、代码 diff 摘要，等待验收（设置 30 分钟超时提醒）。完整模式还展示 14-team.md 和 15-brief.md 核心内容；精简模式展示 11-review.md 审查结论和 13-retrospective.md 改进承诺。
+
+**交付清单验证**：如果 `docs/delivery-checklist.md` 存在，读取并检查 `- [ ]` 项是否已标记为 `- [x]`。未完成项列入 H4 展示内容，供用户判断是否放行或要求补全。
 
-- 如果分支尚未合并，推荐使用 `team-finish` 完成分支处理
-- 如果已合并，确认合并 commit 已推送
+- 用户验收通过 → **写入 checkpoint**：`current_step=Step 7.5, status=IN_PROGRESS, completed_steps 追加 H4`。继续
+- 用户不通过 → 根据反馈回到对应 Agent
+- **P2 决策**：如果 spec 定义了 P2（候选增强），向用户展示 P2 建议 + 触发条件，由用户决定是否继续
 
 ### Step 7.5：归档与知识合并
 
@@ -577,7 +592,7 @@ TDD 强制要求：每个功能点必须先 git commit 失败测试（test: {功
 
 ### Step 8：最终质量检查
 
-逐条核验，确保每个维度都有明确证据。**精简模式下**，标注 `[完整模式]` 的检查项跳过，标注 `[精简替代]` 的检查项替换原项。
+**模式判断**：读取 `.checkpoint.json` 的模式字段。精简模式下：标注 `[完整模式]` 的检查项跳过，标注 `[精简替代]` 的检查项替换原项，D5 整组跳过。仅当剩余检查项全部通过时才声明质量检查通过。
 
 **硬门槛（7 项全部必须通过）：**
 
@@ -632,9 +647,9 @@ TDD 强制要求：每个功能点必须先 git commit 失败测试（test: {功
 
 如有未通过项，回到对应 Agent 补全。
 
-## STOP Signals
+**全部通过后写入 checkpoint**：`current_step=Step 8, status=DONE, completed_steps 追加 Step 7.5 和 Step 8`。此时且仅此时 `status` 设为 `DONE`（如有保留意见则设为 `DONE_WITH_CONCERNS`）。
 
-如果你发现自己即将做以下任何一件事——立即停止，重新审视：
+## STOP Signals
 
 - 跳过 H1 或 H4
 - 延迟回退（"先记着后面一起修"）
@@ -646,7 +661,7 @@ TDD 强制要求：每个功能点必须先 git commit 失败测试（test: {功
 在报告完成状态前，执行以下自检：
 
 - [ ] 完整模式：所有 17 个文件已产出（01-15 + prompt-template + task-rules）；精简模式：核心文件已产出（03-sdd + 04-boundary + 06-tdd-log + 07-prompt-log + 08-ai-decisions + 09-test-matrix + 10-test-report + 11-review + 12-asset-update + 13-retrospective + task-rules）
-- [ ] H1 和 H4 经过人类确认，未被跳过（完整模式还需确认 H2）
+- [ ] H1 和 H4 经过人类确认，未被跳过（完整模式还需确认 H2；精简模式需确认 H2 单句确认已执行）
 - [ ] 回退计数未超过上限（同一阶段 ≤ 2 次）
 - [ ] Step 8 质量检查全部通过
 - [ ] CHANGELOG.md 已更新（如 reviewAgent 要求）
@@ -675,7 +690,3 @@ Team 全流程完成 ✅
 - `team-test` — REQUIRED：编排流程中必须调度测试审计
 - `team-review` — REQUIRED：编排流程中必须调度代码审查
 - `team-finish` — 分支完成处理
-
-## 下一步
-
-- 如果发现流程问题，更新 `CLAUDE.md` 和 `skills/_team-rules/` 中的规则