team-skills 1.2.0 → 1.2.2

package/README.md

@@ -149,7 +149,7 @@ npx team-skills@latest update
 /team-orchestrator 实现用户登录功能
 ```
 
-编排器自动完成：H1 确认目标 → specAgent 产出 SDD → H2 确认规格 → implAgent TDD 实现 → testAgent 四维测试 → reviewAgent 五维审查 → H4 验收交付
+编排器自动完成：H1 确认目标 → specAgent 产出 SDD → H2 确认规格 → implAgent TDD 实现 → testAgent 四维测试 → reviewAgent 五维审查 → 分支完成处理 → H4 验收交付
 
 简单任务可用精简模式：
 
@@ -180,22 +180,26 @@ npx team-skills@latest update
 flowchart TD
     classDef human fill:#e3f2fd,stroke:#1565c0,stroke-width:2px,color:#1565c0;
     classDef agent fill:#f3e5f5,stroke:#7b1fa2,stroke-width:2px,color:#4a148c;
+    classDef git fill:#e8f5e9,stroke:#2e7d32,stroke-width:2px,color:#1b5e20;
     classDef kill fill:#ffebee,stroke:#c62828,stroke-width:2px,stroke-dasharray: 5 5,color:#b71c1c;
 
     START(("用户提出需求"))
     H1["H1: 人类确认目标理解<br/>← 人类介入点 #1"]:::human
+    BRANCH["创建功能分支<br/>{slug} 分支"]:::git
     SPEC["specAgent — 规格制定<br/>产出 01-05 + prompt-template<br/>Socratic 提问 → SDD 规格"]:::agent
     H2["H2: 人类确认规格方案<br/>← 人类介入点 #2"]:::human
     IMPL["implAgent — TDD 实现<br/>红-绿-重构循环<br/>增量提交 + 决策记录"]:::agent
     TEST["testAgent — 四维测试<br/>功能/边界/异常/代码分支"]:::agent
     REVIEW["reviewAgent — 五维审查<br/>资产沉淀 + 复盘"]:::agent
+    FINISH["team-finish — 分支完成<br/>merge / PR / keep"]:::git
     H4["H4: 人类验收交付物<br/>← 人类介入点 #4"]:::human
     H3("H3: 人类介入 #3<br/>阻塞 / 决策 / Kill Switch"):::human
 
     START --> H1
-    H1 -->|确认| SPEC
+    H1 -->|确认| BRANCH
     H1 -->|不确认| START
 
+    BRANCH --> SPEC
     SPEC --> H2
     H2 -->|确认| IMPL
     H2 -->|不确认| SPEC
@@ -208,16 +212,18 @@ flowchart TD
     TEST -->|spec 遗漏| SPEC
     TEST -.->|不可行| H3
 
-    REVIEW -->|无问题| H4
+    REVIEW -->|无问题| FINISH
     REVIEW -->|P0/P1| IMPL
     REVIEW -->|spec 遗漏| SPEC
     REVIEW -.->|不可行| H3
 
+    FINISH --> H4
     H4 -->|验收通过| DONE(("完成 ✅"))
     H4 -->|不通过| IMPL
 ```
 
 > H3 可在**任何阶段**触发，包括：发现任务不可行（Kill Switch）、回退超限、或需要人类决策的复杂问题。
+> 功能分支在 H1 确认后自动创建，在 Review 通过后由 team-finish 处理（merge/PR/keep/discard）。
 
 ---
 
@@ -250,9 +256,7 @@ graph TD
     ORCH -.->|自动调度| IMPL
     ORCH -.->|自动调度| TEST
     ORCH -.->|自动调度| REVIEW
-    ORCH -.->|自动调度| FB
     ORCH -.->|自动调度| FINISH
-    ORCH -.->|自动调度| VERIFY
 ```
 
 **使用说明：**
@@ -272,7 +276,7 @@ graph TD
 | `team-impl` | TDD 红-绿-重构循环实现 | "规格有了，开始写代码" |
 | `team-test` | 四维测试矩阵 + 补充测试 | "测试覆盖够吗？" |
 | `team-review` | 五维审查 + 资产沉淀 + 复盘 | "代码质量如何？" |
-| `team-orchestrator` | 有向图流程编排，4 个人类介入点 | "我要完整交付流水线" |
+| `team-orchestrator` | 有向图流程编排 + 分支管理，4 个人类介入点 | "我要完整交付流水线" |
 | `team-verify` | 5 步验证门禁，杜绝虚假通过 | "测试真的过了吗？" |
 | `team-debug` | 四阶段根因分析 + 修复 | "这个 bug 怎么回事？" |
 | `team-feedback` | 先验证再实施，非表演性同意 | "Review 反馈来了" |
@@ -283,30 +287,63 @@ graph TD
 
 ---
 
-## 📋 每个任务最多产出 18 个结构化文档
+## 📋 结构化文档体系
+
+团队协作过程中产出的所有文档，统一存放在 `docs/` 目录下：
 
 ```
-docs/tasks/{slug}/
-├── 00-design-brief.md      # 设计概要（team-brainstorm 产出，可选）
-├── 01-plan.md              # 任务规划（目标 + 分期 + 预算）
-├── 02-context.md           # 上下文选择（术语 + 引用 + 排除）
-├── 03-sdd.md               # SDD 规格（七部分完整）
-├── 04-boundary.md          # 修改边界（allow + deny）
-├── 05-risk.md              # 风险 + 验证计划
-├── prompt-template.md      # AI 任务提示词模板
-├── 06-tdd-log.md           # TDD 日志（红-绿-重构循环）
-├── 07-prompt-log.md        # Prompt 工程记录（五要素 + 纠偏）
-├── 08-ai-decisions.md      # AI 决策记录（选择 + 拒绝 + 理由）
-├── 09-test-matrix.md       # 四维测试矩阵
-├── 10-test-report.md       # 测试运行报告（证据链）
-├── 11-review.md            # 代码审查报告（五维度 + 合规）
-├── 12-asset-update.md      # 资产更新记录（消费方契约）
-├── 13-retrospective.md     # 个人复盘（新规则沉淀）
-├── task-rules.md           # 任务级规则
-├── 14-team.md              # 团队协作记录
-└── 15-brief.md             # 答辩提纲
+docs/
+├── tasks/                          # 任务文档（核心目录）
+│   ├── progress.md                 # 进度账本 — 所有任务的状态追踪表
+│   │
+│   ├── {NNNN}-{keyword}/           # 单个任务目录（最多产出 18 个结构化文档）
+│   │   ├── 00-design-brief.md      #   设计概要（team-brainstorm 产出，可选）
+│   │   ├── 01-plan.md              #   任务规划（目标 + 分期 + 预算）
+│   │   ├── 02-context.md           #   上下文选择（术语 + 引用 + 排除）
+│   │   ├── 03-sdd.md              #   SDD 规格（七部分完整）
+│   │   ├── 04-boundary.md          #   修改边界（allow + deny）
+│   │   ├── 05-risk.md              #   风险 + 验证计划
+│   │   ├── prompt-template.md      #   AI 任务提示词模板
+│   │   ├── 06-tdd-log.md           #   TDD 日志（红-绿-重构循环）
+│   │   ├── 07-prompt-log.md        #   Prompt 工程记录（五要素 + 纠偏）
+│   │   ├── 08-ai-decisions.md      #   AI 决策记录（选择 + 拒绝 + 理由）
+│   │   ├── 09-test-matrix.md       #   四维测试矩阵
+│   │   ├── 10-test-report.md       #   测试运行报告（证据链）
+│   │   ├── 11-review.md            #   代码审查报告（五维度 + 合规）
+│   │   ├── 12-asset-update.md      #   资产更新记录（消费方契约）
+│   │   ├── 13-retrospective.md     #   个人复盘（新规则沉淀）
+│   │   ├── task-rules.md           #   任务级规则
+│   │   ├── 14-team.md              #   团队协作记录
+│   │   └── 15-brief.md             #   答辩提纲
+│   │
+│   └── ...                         # 更多任务目录
+│
+├── review-checklist.md             # Review 检查清单（项目级，跨任务累积）
+├── delivery-checklist.md           # 交付检查清单（项目级，跨任务累积）
+└── specs/                          # SDD 归档（任务验收通过后存档）
 ```
 
+### 文档职责分层
+
+| 层级 | 目录 | 生命周期 | 说明 |
+|------|------|----------|------|
+| **进度追踪** | `tasks/progress.md` | 持续更新 | 防止跨 session 任务重复派发，记录所有任务状态 |
+| **任务文档** | `tasks/{slug}/` | 随任务创建 | 每个任务独立目录，slug 格式 `{NNNN}-{keyword}` |
+| **项目级清单** | `review-checklist.md` | 跨任务累积 | 每次 Review 发现新检查项后追加，持续积累 |
+| **项目级清单** | `delivery-checklist.md` | 跨任务累积 | 每次交付发现新检查项后追加，持续积累 |
+| **规格归档** | `specs/` | 验收后存档 | SDD 快照归档，供后续任务参考 |
+
+### 任务文档产出阶段
+
+| 阶段 | 产出文件 | 负责 Skill |
+|------|----------|------------|
+| 头脑风暴 | `00-design-brief.md` | `team-brainstorm` |
+| 规格设计 | `01-plan.md` ~ `05-risk.md` + `prompt-template.md` | `team-spec` |
+| TDD 实现 | `06-tdd-log.md` ~ `08-ai-decisions.md` | `team-impl` |
+| 测试审计 | `09-test-matrix.md` ~ `10-test-report.md` | `team-test` |
+| 代码审查 | `11-review.md` ~ `13-retrospective.md` + `task-rules.md` | `team-review` |
+| 团队交付 | `14-team.md` + `15-brief.md` | `team-orchestrator` |
+
 ---
 
 ## 🔧 兼容性

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "team-skills",
-  "version": "1.2.0",
+  "version": "1.2.2",
   "description": "AI Agent Skills framework — Spec-Driven development with directed-graph rollback and quality gates",
   "type": "module",
   "bin": {

package/skills/_team-rules/constitutional-rules.md

@@ -6,7 +6,7 @@
 
 > 每条规则追溯到 `_team-rules/first-principles.md` 中的第一性原理（FP-1 ~ FP-4）。
 
-1. **人类介入是一等公民** — H1-H4 必须暂停等待确认（精简模式下 H1 可简化为单句确认，H2 可跳过，但 H1 和 H4 不可省略）
+1. **人类介入是一等公民** — H1-H4 必须暂停等待确认（精简模式下 H1 和 H2 可简化为单句确认，但 H1 和 H4 不可省略）
    - **为什么（FP-1）**：AI 的价值在于放大人类判断力而非替代它。跳过人类介入 = 让放大器在无信号源时自激振荡
 2. **有向图回退** — 发现问题必须回退，禁止"先记着后面修"
    - **为什么（FP-4）**：声明不等于事实。"后面修"是一种声明——承诺未来会修复，但没有任何证据保证。问题在发现时最容易定位，延迟修复使上下文流失
@@ -14,7 +14,7 @@
    - **为什么（FP-4）**：Agent 会无意识地将"我认为通过了"当作"确实通过了"。自我声明是零信息量信号
 4. **Kill Switch** — 不可行必须立即暂停，禁止"先做做看"
    - **为什么（FP-1 + FP-3）**：人类认知是稀缺资源——在错误方向上投入的每一分钟都是浪费。复杂度是质量的敌人——在不可行的基础上堆叠更多工作只会使失败更难诊断
-5. **分期交付优先** — 复杂任务必须 P1+P2，禁止一次性全量交付
+5. **分期交付优先** — 复杂任务必须 P1+P2，禁止一次性全量交付。复杂度判定参考 `team-orchestrator` 的任务规模分级：修改文件 > 3 且有跨模块影响即为 Medium 以上，应分期
    - **为什么（FP-3）**：复杂度是质量的敌人。一次性全量交付使得任何单点失败都阻塞整体验收。分期交付将风险隔离到每期的边界内
 6. **自我约束预算** — 超出即砍范围，不放宽预算
    - **为什么（FP-3）**：预算是复杂度的量化边界。放宽预算 = 主动邀请复杂度增长

package/skills/_team-rules/first-principles.md

@@ -14,5 +14,6 @@
 ## 如何使用第一性原理
 
 - **规则冲突时**：回溯到第一性原理裁决。例如 "精简模式要不要跳过 H4？" → FP-1 说人类认知是稀缺资源但关键决策不可替代 → H4 不可跳过
+- **两条原理冲突时**：优先保护人类认知（FP-1）和事实验证（FP-4），因为它们的违反后果不可逆。FP-2（实现偏见）和 FP-3（复杂度）可在 FP-1/FP-4 约束内灵活权衡
 - **规则缺失时**：从第一性原理推导。例如 "调试时要不要写测试？" → FP-2 说实现偏见污染验证 → 先写回归测试再修复
 - **规则过度时**：如果一条规则无法追溯到任何第一性原理，它可能是官僚主义而非工程纪律 → 应当简化或删除

package/skills/_team-rules/four-state-protocol.md

@@ -1,10 +1,14 @@
 # 完成状态协议（四态）
 
-> 共享规则文件。每个 Agent 完成后 MUST 报告以下状态之一。
-
-| 状态 | 含义 | 编排器动作 |
-| ---- | ---- | ---------- |
-| **DONE** | 全部完成，无遗留 | 继续下一步 |
-| **DONE_WITH_CONCERNS** | 已完成但有保留意见 | 展示担忧，用户决定 |
-| **NEEDS_CONTEXT** | 缺少关键上下文 | 回退或触发 H3 |
-| **BLOCKED** | 被阻塞 | 触发 H3 人类介入 |
+> 共享规则文件。所有 Team Skill 的「完成标志」章节统一使用本协议定义的四态状态。每个 Agent 完成后 MUST 报告以下状态之一。
+
+| 状态 | 含义 | 判定标准 | 编排器动作 |
+| ---- | ---- | -------- | ---------- |
+| **DONE** | 全部完成，无遗留 | 所有自检门禁通过 + 无 P0/P1 未解决 + 无待人类决策项 | 继续下一步 |
+| **DONE_WITH_CONCERNS** | 已完成但有保留意见 | 自检门禁通过，但存在以下任一情况：P2 问题记录但未修复、验证工具不可用改用手动验证、实现方案可行但非最优、发现了超出本任务范围的潜在风险 | 展示担忧，用户决定 |
+| **NEEDS_CONTEXT** | 缺少关键上下文 | 无法继续执行：缺少输入文件、缺少验证命令、依赖信息不明确 | 回退或触发 H3 |
+| **BLOCKED** | 被阻塞 | 遇到不可自行解决的问题：技术不可行、回退次数超限、需要人类决策 | 触发 H3 人类介入 |
+
+## 与 checkpoint `status` 的关系
+
+四态协议定义的是**单个 Agent 完成时的报告状态**。`team-orchestrator` 的 `.checkpoint.json` 中 `status` 字段额外包含 `IN_PROGRESS` 状态，用于表示**任务整体仍在执行中**。`IN_PROGRESS` 不属于 Agent 完成状态，仅用于 checkpoint 断点续传。

package/skills/_team-rules/verification-protocol.md

@@ -6,7 +6,11 @@
 
 ```
 
-1. 确定验证命令（从项目 AI 规范文件或 05-risk.md 获取）
+1. 确定验证命令（按优先级从高到低获取）：
+   - 05-risk.md §一验证计划
+   - CLAUDE.md / .cursor/rules/ 中的测试命令
+   - package.json scripts / Makefile / Cargo.toml 中的 test/lint 脚本
+   - 以上均无 → 状态标记为 NEEDS_CONTEXT，请求用户提供验证命令
    - 如果项目无测试/lint/CI 命令：在 10-test-report.md 中标注「项目无自动化验证命令」，改用手动验证（截图、curl 输出、日志对比等可复现证据），不可跳过验证
 2. 执行命令——不使用缓存结果，不引用上一轮输出
 3. 完整阅读输出——不截断，不跳过 warning
@@ -36,7 +40,7 @@
 
 1. 记录失败原因和错误输出
 2. 尝试修复环境问题后重新执行（最多 2 次）
-3. 仍然失败 → 状态标记为 BLOCKED，触发 H3 由人类决定是否跳过该验证项
+3. 仍然失败 → 状态标记为 BLOCKED，触发 H3 由人类决定下一步（跳过该验证项意味着状态不可为 DONE，只能为 DONE_WITH_CONCERNS）
 4. 不可将"工具失败"等同于"验证通过"
 
 ## Iron Law

package/skills/team-brainstorm/SKILL.md

@@ -17,13 +17,13 @@ description: Use when requirements are fuzzy, need to discuss and form a plan be
 你是一个 Team brainstorm 引导者。你的任务是：
 
 1. 探索项目上下文，理解现状
-2. 逐个提问澄清需求（每次 1 个问题）
+2. 提出关键问题澄清需求（一次性展示最多 3 个问题，等待用户一次回复）
 3. 提出 2-3 个方案并比较
 4. 展示设计，等待用户确认
 5. 创建任务目录，产出 00-design-brief.md
 6. 可选 handoff 到 team-spec 或 team-impl
 
-关键区别：你不是在写方案，你是在引导讨论。不要一次抛出所有问题。用户没确认之前不能进入实现阶段。每次只问一个问题，等回复后再问下一个。
+关键区别：你不是在写方案，你是在引导讨论。不要一次抛出所有分析。用户没确认之前不能进入实现阶段。
 ```
 
 ### 推理指引
@@ -73,9 +73,9 @@ NO IMPLEMENTATION WITHOUT USER APPROVED DESIGN FIRST
 4. 评估范围：如果需求包含多个独立子系统，先帮助用户分解
 5. 生成 `{slug}`：扫描 `docs/tasks/` 已有目录取最大序号 +1，创建 `docs/tasks/{slug}/` 目录
 
-### Phase 2：需求澄清（逐个提问）
+### Phase 2：需求澄清（一次性提问）
 
-每次 1 个问题，优先用选项形式，最多 3 个问题：
+一次性向用户展示最多 3 个关键问题（优先用选项形式），等待用户一次回复：
 
 - 目标优先级："以下哪个是最重要的目标？A) ... B) ... C) ..."
 - 边界确认："以下范围是否正确？是否需要排除某些模块？"
@@ -182,8 +182,6 @@ NO IMPLEMENTATION WITHOUT USER APPROVED DESIGN FIRST
 
 ## STOP Signals
 
-如果你发现自己即将做以下任何一件事——立即停止，重新审视：
-
 - 跳过代码库探索，凭空设计方案
 - 一次抛出所有问题，不等用户逐个回复
 - 方案对比只提供一个选项，没有备选方案
@@ -201,8 +199,3 @@ NO IMPLEMENTATION WITHOUT USER APPROVED DESIGN FIRST
 - `team-impl` — 仅当用户明确要求跳过规格阶段时可直接实现
 
 > **终端状态**：讨论完成后，默认调用 `team-spec {slug}` 进行规格定义。仅当用户**显式要求**跳过规格阶段时，才可直接进入 `team-impl`。
-
-## 下一步
-
-- 产出 `00-design-brief.md` 后，推荐使用 `team-spec {slug}` 进行规格定义（默认路径）
-- 仅当用户明确要求跳过规格时，可直接使用 `team-impl` 进行 TDD 实现

package/skills/team-debug/SKILL.md

@@ -87,15 +87,26 @@ NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST
    - 怀疑的架构问题（如：模块耦合、数据流错误、设计模式不匹配）
    - 建议的下一步方向（如：重新设计模块、引入新依赖、重构接口）
 
-### Phase 5：系统调试找不到根因时
+### Phase 5：根因未能确定时的处理（回退门禁）
 
-如果系统调试后仍然找不到根因（环境问题、时序依赖、外部因素）：
+如果经过 Phase 1-4 调试后仍然找不到根因（环境问题、时序依赖、外部因素），在声明"找不到根因"之前必须通过以下门禁：
 
-1. 你已经完成了调试流程——记录已调查的内容
+**声明"找不到根因"的最低门槛**（全部满足才可声明）：
+
+- [ ] 完整阅读了错误信息（含 stack trace 全文）
+- [ ] 稳定复现了问题（≥ 3 次）
+- [ ] 检查了 `git log` 最近 10 次提交的变更
+- [ ] 对比了 ≥ 1 个正常工作的相似实现
+- [ ] 添加了 ≥ 5 个诊断日志/断言
+
+> **警告**：95% 的"找不到根因"情况是不完整的调查。门槛未全部满足时，回到 Phase 1 继续调查。
+
+门槛通过后：
+
+1. 记录已调查的内容和排除的假设
 2. 实施适当的防护措施（重试、超时、错误处理、日志记录）
 3. 添加监控/日志以便未来调查
-
-> **警告**：95% 的"找不到根因"情况是不完整的调查。在声明"找不到根因"之前，确认你已经：完整阅读了错误信息、稳定复现了问题、检查了最近变更、对比了工作示例。
+4. 状态标记为 `DONE_WITH_CONCERNS`，附带已排除的假设列表
 
 ## 用户信号识别
 
@@ -114,8 +125,9 @@ NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST
 引用 `_team-rules/constitutional-rules.md`。调试阶段尤其注意：
 
 - **Rule #9 TDD 顺序不可逆**：修复 bug 必须先写失败的回归测试再写修复代码（FP-2）
-- **Rule #3 产出必须验证**：修复完成后必须运行验证协议，不可仅凭"修改了代码"就声明修复（FP-4）
+- **Rule #3 产出必须验证**：修复完成后必须执行 `_team-rules/verification-protocol.md` 的 5 个步骤，不可仅凭"修改了代码"就声明修复（FP-4）
 - **Rule #7 回退次数上限**：3 次修复失败必须触发 H3，不可无限重试（FP-1）
+- **Rule #2 有向图回退**：如果调试过程发现问题根源在 spec 歧义或遗漏，必须回退到 specAgent 而非自行假设正确行为（FP-4）
 
 ## 自检门禁
 
@@ -138,8 +150,6 @@ NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST
 
 ## STOP Signals
 
-如果你发现自己即将做以下任何一件事——立即停止，重新审视：
-
 - 没找到根因就开始写修复代码
 - 一次修改多个变量，无法隔离哪个改动有效
 - 3 次修复失败后仍然继续尝试，没有触发 H3
@@ -156,8 +166,3 @@ NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST
 
 - `team-verify` — REQUIRED：修复后必须验证
 - `team-test` — 确认无回归
-
-## 下一步
-
-- 修复完成后，使用 `team-verify` 验证修复
-- 使用 `team-test` 确认无回归

package/skills/team-feedback/SKILL.md

@@ -58,55 +58,48 @@ NO IMPLEMENTATION WITHOUT TECHNICAL VERIFICATION FIRST
 
 ### Phase 1：理解反馈
 
-```
-WHEN receiving code review feedback:
-
-1. READ: Complete feedback without reacting
-2. UNDERSTAND: Restate requirement in own words (or ask)
-3. VERIFY: Check against codebase reality
-4. EVALUATE: Technically sound for THIS codebase?
-5. RESPOND: Technical acknowledgment or reasoned pushback
-6. IMPLEMENT: One item at a time, test each
+收到代码审查反馈后，按以下顺序处理：
 
-```
+1. **完整阅读**：读完所有反馈，不立即反应
+2. **重述需求**：用自己的话重述审查者的要求（如果不确定，先提问澄清）
+3. **代码验证**：对照代码库验证每条建议的技术正确性（grep/Read 实际代码，不凭印象）
+4. **适用性评估**：这条建议在**当前**代码库中技术上是否正确？
+5. **技术性回应**：对每条反馈给出技术性确认或基于推理的推回（参考「推回指南」）
+6. **逐项实施**：一次实施一项，每项单独测试
 
 ### Phase 2：YAGNI 检查
 
-如果审查者建议"实现得更完善"：
-
-```
-grep codebase for actual usage
+当审查者建议"实现得更完善"或添加新功能时：
 
-IF unused: "这个功能没被调用。删掉（YAGNI）？"
-IF used: 按建议实现
-```
+1. grep 代码库查找该功能/接口的实际使用
+2. 如果是 exported/public API → 即使当前项目未直接调用也不应删除（可能有外部消费方）
+3. 如果是 internal 且无引用 → 建议删除，向审查者回应："该功能当前未被调用，建议删除（YAGNI）"
+4. 如果有引用 → 按建议实现
+5. 如果不确定 → 标注 {ambiguous} 并询问用户
 
 ### Phase 3：外部反馈处理
 
-```
-BEFORE implementing external feedback:
+实施外部反馈前，按 Phase 1 步骤 3-4 的方法逐条验证（grep 实际代码，不凭印象），并额外检查以下 2 个条件：
 
-1. 技术上对当前代码库正确吗？
-2. 会破坏现有功能吗？
-3. 审查者理解完整上下文吗？
-4. 与用户之前的决策冲突吗？
+1. **上下文完整性**：审查者是否了解完整上下文？（检查 08-ai-decisions.md 中的已有决策）
+2. **决策一致性**：建议与用户之前做出的设计决策冲突吗？
 
-IF 建议看起来不对 → 用技术理由推回
-IF 无法验证 → 说"我需要 {X} 才能验证"
-IF 冲突 → 暂停与用户讨论
-```
+根据检查结果路由：
 
-### Phase 4：实施
+- 建议技术上不正确 → 用技术理由推回（参考「推回指南」）
+- 无法验证 → 明确回应"我需要 {具体信息} 才能验证这条建议"
+- 与已有决策冲突 → 暂停，展示冲突点，等待用户决策
+- 反馈揭示 spec 遗漏 → 路由到 team-spec
+- 反馈揭示架构问题 → 触发 H3
 
-```
-FOR multi-item feedback:
+### Phase 4：实施
 
-1. 先澄清所有不明确项
-2. 按顺序实施：阻塞问题 → 简单修复 → 复杂修复
-3. 每项单独测试
-4. 验证无回归
+多项反馈的实施顺序：
 
-```
+1. 先澄清所有不明确项（Phase 1 步骤 2 已完成）
+2. 按优先级排序实施：阻塞问题 → 简单修复 → 复杂修复
+3. 每项修改单独测试（运行项目测试命令）
+4. 全部实施后运行全量测试，确认无回归
 
 ## 禁止回应
 
@@ -166,8 +159,6 @@ FOR multi-item feedback:
 
 ## STOP Signals
 
-如果你发现自己即将做以下任何一件事——立即停止，重新审视：
-
 - 没有验证技术正确性就开始实施反馈建议
 - 使用"你说得太对了""好主意"等表演性同意回应
 - 多项反馈批量实施而不逐项测试
@@ -185,10 +176,3 @@ FOR multi-item feedback:
 - `team-impl` — 修复实现
 - `team-spec` — 反馈揭示 spec 遗漏时
 - `team-finish` — 分支完成处理
-
-## 下一步
-
-- 反馈处理完成后，继续当前开发流程
-- 如果需要合并分支，使用 `team-finish`
-- **如果反馈揭示 spec 遗漏**（审查者指出未定义的行为或缺失的边界条件）→ 使用 `team-spec` 更新规格，然后回退到 implAgent 重新实现
-- **如果反馈揭示架构问题**（审查者指出设计决策有根本性缺陷）→ 触发 H3 人类介入，由人类决定是否重新设计

package/skills/team-finish/SKILL.md

@@ -9,6 +9,8 @@ description: Use when implementation is complete, all tests pass, and you need t
 
 你是分支完成处理者。你的核心职责是：验证测试 → 展示选项 → 执行选择 → 清理。
 
+> **分支生命周期**：`team-orchestrator` 在 H1 确认后创建功能分支（Step 1.5），本 Skill 在流程尾部（Step 7.3）负责分支收尾。两者配合形成完整的分支生命周期闭环。
+
 ### 系统提示词
 
 ```
@@ -56,7 +58,7 @@ NO BRANCH COMPLETION WITHOUT TEST VERIFICATION FIRST
 
 ### Step 1：验证测试
 
-运行项目测试命令。如果测试失败：
+运行项目测试命令（声明"测试通过"前须执行 `_team-rules/verification-protocol.md` 的 5 个步骤）。如果测试失败：
 
 ```
 Tests failing (<N> failures). Must fix before completing:
@@ -68,7 +70,15 @@ Cannot proceed with merge/PR until tests pass.
 
 ### Step 2：确定基准分支
 
-运行项目版本控制命令获取当前分支与基准分支的合并基点（如 `git merge-base HEAD main`）。
+按以下优先级确定基准分支：
+
+1. **从 checkpoint 读取**：如果 `docs/tasks/{slug}/.checkpoint.json` 存在且包含 `base_branch` 字段，直接使用（orchestrator Step 1.5 已确定）
+2. **从项目 AI 规范读取**：在 CLAUDE.md / .cursor/rules/ 中查找 `base_branch` 或 `default_branch` 配置项
+3. **从 Git 远程推断**：`git symbolic-ref refs/remotes/origin/HEAD | sed 's|refs/remotes/origin/||'`
+4. **常见分支名兜底**：按 `main` → `master` → `develop` 顺序检查本地是否存在
+5. **全部失败** → 触发 H3：向用户展示 `git branch --list` 和 `git remote -v` 输出，让用户指定基准分支（不可自动猜测）
+
+确定后运行 `git merge-base HEAD {base_branch}` 获取合并基点。
 
 ### Step 3：展示选项
 
@@ -87,15 +97,19 @@ Which option?
 
 #### Option 1：本地合并
 
-1. 切换到基准分支并拉取最新
-2. 合并功能分支到基准分支
-3. 运行项目测试命令验证合并后无回归
-4. 删除功能分支
+1. 切换到基准分支并拉取最新（`git checkout {base} && git pull`）
+2. 合并功能分支（`git merge {branch} --no-ff`）
+3. **合并冲突处理**：如果 `git merge` 报告冲突，向用户展示冲突文件列表并暂停——由用户选择 (A) 手动解决冲突后继续、(B) 中止合并改为创建 PR、(C) 中止合并保留分支。不自动解决冲突
+4. 运行项目测试命令验证合并后无回归
+5. 删除功能分支
+
+> **验证协议**（步骤 4 声明"通过"前必须执行 `_team-rules/verification-protocol.md` 的 5 个步骤）
 
 #### Option 2：创建 PR
 
-1. 推送功能分支到远程
-2. 使用项目 PR 创建命令（如 `gh pr create`）创建 Pull Request
+1. 推送功能分支到远程（`git push -u origin {branch}`）。如果推送失败（auth 错误、远程未配置），向用户展示错误信息并暂停
+2. 使用项目 PR 创建命令创建 Pull Request（优先从 CLAUDE.md / .cursor/rules/ 获取 PR 命令；如未配置则使用 `gh pr create`）
+3. 向用户展示 PR URL，确认创建成功
 
 #### Option 3：保留分支
 
@@ -145,8 +159,6 @@ Which option?
 
 ## STOP Signals
 
-如果你发现自己即将做以下任何一件事——立即停止，重新审视：
-
 - 测试未通过就展示合并/PR 选项
 - 合并后没有重新运行测试就声明完成
 - 丢弃分支前没有要求用户输入 "discard" 确认
@@ -163,8 +175,3 @@ Which option?
 
 - `team-review` — 合并前确认审查已完成
 - `team-brainstorm` / `team-spec` — 下一个功能
-
-## 下一步
-
-- 分支处理完成后，继续下一个功能开发
-- 下一个功能开始时，推荐使用 `team-brainstorm` 或 `team-spec`