team-skills 1.2.1 → 1.2.2

package/skills/team-orchestrator/SKILL.md

@@ -21,8 +21,11 @@ flowchart TD
     testAgent -->|"全部通过"| reviewAgent["reviewAgent: 代码审查"]
     reviewAgent -->|"P0/P1 问题"| implAgent
     reviewAgent -->|"spec 遗漏"| specAgent
-    reviewAgent -->|"无问题"| finish["team-finish: 分支完成"]
+    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
 ```
 
@@ -37,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 可在精简模式下简化为单句确认）。
 ```
@@ -62,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`，不内联重复。
@@ -258,7 +218,7 @@ NO AGENT DISPATCH WITHOUT H1 HUMAN CONFIRMATION FIRST
 
 ### 方式 A：全自动编排（推荐）
 
-用户执行 `/team-orchestrator {任务描述}` 一次性启动全流程。
+用户执行 `/team-orchestrator {任务描述}` 启动全流程。
 
 ### 方式 B：手动分步
 
@@ -268,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 文件 + 多期迭代 |
 
@@ -293,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 | ✅ | ✅ |
@@ -333,36 +286,45 @@ 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 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 1.5, 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 1.5, completed_steps 追加 H1`。继续下一步，否则根据反馈调整
+9. 用户确认后，**写入 checkpoint**：`current_step=Step 1.5, status=IN_PROGRESS, completed_steps 追加 H1`。继续下一步，否则根据反馈调整
 
 **Kill Switch 预检查**：如果任务明显不可行（技术不可行、依赖不可用、范围远超预期），在 H1 阶段直接向用户提出终止建议。
 
@@ -383,8 +345,9 @@ H1 确认后、specAgent 启动前，创建功能分支隔离本次任务的所
 #### 1.5.2 创建功能分支
 
 1. **检测当前分支**：获取当前分支名（`git branch --show-current`）
-2. **创建功能分支**：`git checkout -b {slug}`（分支名直接使用 slug，如 `0012-refactor-auth`）
-3. **写入 checkpoint**：`current_step=Step 2, branch={slug}, base_branch={基准分支名}, completed_steps 追加 Step 1.5`
+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`
 
 **跳过条件**（不创建分支）：
 
@@ -411,21 +374,22 @@ H1 确认后、specAgent 启动前，创建功能分支隔离本次任务的所
 模式：{完整 / --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**：如果用户认为任务不可行或范围不可接受 → 终止流程
 
@@ -451,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`，对每个功能点块执行以下检查：
@@ -463,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
 
@@ -481,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
 
@@ -522,23 +486,23 @@ TDD 强制要求：每个功能点必须先 git commit 失败测试（test: {功
 读取 skills/team-review/SKILL.md 获取完整执行步骤。
 ```
 
+等待 reviewAgent 完成。
+
 **完成验证**：确认 11-review.md / 12-asset-update.md / 13-retrospective.md / task-rules.md 已产出；获取修复/回退决策。
 
-**写入 checkpoint**：`current_step=Step 6, next_step=H4, phase=review, completed_steps 追加 Step 5`
-
-等待 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 并行执行以提高效率。
 
@@ -573,21 +537,13 @@ 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 展示内容，供用户判断是否放行或要求补全。
-
-- 用户验收通过 → **写入 checkpoint**：`current_step=Step 7.3, completed_steps 追加 H4`。继续
-- 用户不通过 → 根据反馈回到对应 Agent
-- **P2 决策**：如果 spec 定义了 P2（候选增强），向用户展示 P2 建议 + 触发条件，由用户决定是否继续
-
-### Step 7.3：finish-review 集成
-
-在归档前，检查 reviewAgent 产出的 `12-asset-update.md` 中是否有 CHANGELOG.md 更新。如果 CHANGELOG.md 需要更新但尚未更新，在此处补全。
+检查 reviewAgent 产出的 `12-asset-update.md` 中是否有 CHANGELOG.md 更新。如果 CHANGELOG.md 需要更新但尚未更新，在此处补全。
 
 调度 `team-finish` 完成分支处理：
 
@@ -597,6 +553,18 @@ TDD 强制要求：每个功能点必须先 git commit 失败测试（test: {功
 - 如果用户选择 PR，确认 PR 已创建
 - 如果用户选择 keep/discard，记录用户决策
 
+**写入 checkpoint**：`current_step=Step 7.3, next_step=Step 7.5, phase=finish, status=IN_PROGRESS, completed_steps 追加 Step 7`
+
+### Step 7.3：H4 人类验收 + P2 决策
+
+向用户展示交付物清单、代码 diff 摘要，等待验收（设置 30 分钟超时提醒）。完整模式还展示 14-team.md 和 15-brief.md 核心内容；精简模式展示 11-review.md 审查结论和 13-retrospective.md 改进承诺。
+
+**交付清单验证**：如果 `docs/delivery-checklist.md` 存在，读取并检查 `- [ ]` 项是否已标记为 `- [x]`。未完成项列入 H4 展示内容，供用户判断是否放行或要求补全。
+
+- 用户验收通过 → **写入 checkpoint**：`current_step=Step 7.5, status=IN_PROGRESS, completed_steps 追加 H4`。继续
+- 用户不通过 → 根据反馈回到对应 Agent
+- **P2 决策**：如果 spec 定义了 P2（候选增强），向用户展示 P2 建议 + 触发条件，由用户决定是否继续
+
 ### Step 7.5：归档与知识合并
 
 用户验收通过后，执行以下知识沉淀：
@@ -624,7 +592,7 @@ TDD 强制要求：每个功能点必须先 git commit 失败测试（test: {功
 
 ### Step 8：最终质量检查
 
-逐条核验，确保每个维度都有明确证据。**精简模式下**，标注 `[完整模式]` 的检查项跳过，标注 `[精简替代]` 的检查项替换原项。
+**模式判断**：读取 `.checkpoint.json` 的模式字段。精简模式下：标注 `[完整模式]` 的检查项跳过，标注 `[精简替代]` 的检查项替换原项，D5 整组跳过。仅当剩余检查项全部通过时才声明质量检查通过。
 
 **硬门槛（7 项全部必须通过）：**
 
@@ -679,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
 - 延迟回退（"先记着后面一起修"）
@@ -693,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 要求）
@@ -722,7 +690,3 @@ Team 全流程完成 ✅
 - `team-test` — REQUIRED：编排流程中必须调度测试审计
 - `team-review` — REQUIRED：编排流程中必须调度代码审查
 - `team-finish` — 分支完成处理
-
-## 下一步
-
-- 如果发现流程问题，更新 `CLAUDE.md` 和 `skills/_team-rules/` 中的规则

package/skills/team-review/SKILL.md

@@ -5,8 +5,6 @@ description: Use when code + tests exist and you need structured review + asset
 
 # Team Review — 代码审查
 
-> **兼容工具**：Claude Code (`/team-review`) · Cursor (Skill 自动发现)
-
 ## 角色定位
 
 你是 AI 协作团队中的 **审查专家**。你的核心职责是：
@@ -22,13 +20,7 @@ description: Use when code + tests exist and you need structured review + asset
 ```
 你的思维方式：审计师——你的第一反应永远是"证据在哪里？"
 
-你是一个 Team review 专家。你的任务是：
-
-1. 五维度 Review：对每个修改文件审查正确性、可维护性、性能、安全、测试覆盖
-2. Constitutional 合规检查：验证所有 Agent 是否遵守了 9 条 Constitutional Rules
-3. 问题路由：根据问题严重级别（P0/P1/P2/P3）决定修复方式
-4. 资产维护：更新 CLAUDE.md / .cursor/rules/、CHANGELOG.md、Review Checklist、Delivery Checklist
-5. 复盘：记录本次任务的经验和改进承诺
+你是一个 Team review 专家。
 
 关键区别：你不是简单地挑错。你必须验证 Constitutional Rules 是否被遵守，确保更新的资产可消费（下游 Agent 能直接执行），并在修复方案需要人类确认时暂停等待。
 ```
@@ -54,7 +46,7 @@ description: Use when code + tests exist and you need structured review + asset
 ## Iron Law
 
 ```
-NO COMPLETION CLAIMS WITHOUT CONSTITUTIONAL COMPLIANCE CHECK
+NO COMPLETION CLAIMS WITHOUT CONSTITUTIONAL COMPLIANCE CHECK FIRST
 ```
 
 ### 严重级别校准示例
@@ -100,13 +92,15 @@ NO COMPLETION CLAIMS WITHOUT CONSTITUTIONAL COMPLIANCE CHECK
 
 对每个修改的文件进行以下 5 个维度的审查：
 
-| 维度         | 检查内容                                                       | 严重级别                       |
-| ------------ | -------------------------------------------------------------- | ------------------------------ |
-| **正确性**   | 逻辑是否正确？边界条件是否处理？异常路径是否覆盖？             | P0（数据错误）/ P1（逻辑缺陷） |
-| **可维护性** | 命名是否清晰？函数是否过长？是否有重复代码？是否遵循项目约定？ | P2（可维护性问题）             |
-| **性能**     | 是否有不必要的循环？是否有内存泄漏风险？是否有不必要的渲染？   | P1（性能退化）/ P2（轻微问题） |
-| **安全**     | 是否有注入风险？是否有敏感信息泄露？是否有权限检查遗漏？       | P0（安全漏洞）                 |
-| **测试覆盖** | 测试是否覆盖了所有边界？测试命名是否清晰？测试是否可重复？     | P1（测试遗漏）                 |
+| 维度         | 检查内容                                                       |
+| ------------ | -------------------------------------------------------------- |
+| **正确性**   | 逻辑是否正确？边界条件是否处理？异常路径是否覆盖？             |
+| **可维护性** | 命名是否清晰？函数是否过长？是否有重复代码？是否遵循项目约定？ |
+| **性能**     | 是否有不必要的循环？是否有内存泄漏风险？是否有不必要的渲染？   |
+| **安全**     | 是否有注入风险？是否有敏感信息泄露？是否有权限检查遗漏？       |
+| **测试覆盖** | 测试是否覆盖了所有边界？测试命名是否清晰？测试是否可重复？     |
+
+> 发现的问题使用下方"问题分级标准"统一分级（P0-P3），不按维度预设级别。
 
 ### Phase 1.5：Constitutional 合规检查
 
@@ -143,6 +137,7 @@ NO COMPLETION CLAIMS WITHOUT CONSTITUTIONAL COMPLIANCE CHECK
 | 问题类型        | 路由                      | 条件                          |
 | --------------- | ------------------------- | ----------------------------- |
 | P0 实现 bug     | → implAgent（通过编排器） | 问题在实现层面，spec 定义正确 |
+| P0 设计/架构缺陷 | → specAgent（通过编排器） | 问题根源在 SDD 设计决策而非实现 |
 | P0 安全漏洞     | → H3（人类介入）          | 安全决策需要人类确认          |
 | P1 实现 bug     | → implAgent（通过编排器） | 问题在实现层面                |
 | P1 测试遗漏     | → implAgent（通过编排器） | 需要补写测试                  |
@@ -160,11 +155,11 @@ NO COMPLETION CLAIMS WITHOUT CONSTITUTIONAL COMPLIANCE CHECK
 - 建议的修复方案
 - 如果回退到 implAgent：提供修复后的期望测试用例
 
-### Phase 3：修复问题
+### Phase 3：执行路由决策
 
 对于路由到自己的问题（P2 及以下）：
 
-1. 直接修改代码/测试
+1. 直接修改代码/测试（**每个问题限 20 行以内的修改**——更大规模的重构记录为建议，不直接执行）
 2. 运行测试确认修复正确
 3. 运行项目 CI 检查命令确认无 lint 问题
 4. **边界约束**：如修复导致新测试失败或引入新问题，**立即停止自修**，将问题路由到 implAgent（通过编排器），附带修复尝试的上下文
@@ -184,6 +179,8 @@ NO COMPLETION CLAIMS WITHOUT CONSTITUTIONAL COMPLIANCE CHECK
 
 ### Phase 4：AI 协作资产维护（消费方契约）
 
+> **精简模式**：仅执行 4.0（任务规则）、4.3（CHANGELOG）、4.6（工具适配确认）。跳过 4.0.5、4.1、4.1.5、4.2、4.4、4.5、4.7——这些在精简模式下不产出或无需更新。
+
 更新以下资产文件（记录到 `12-asset-update.md`）。
 
 **消费方契约原则**：更新的资产必须能被下游 Agent 直接读取并执行，不需要额外解释。每条规则必须包含：
@@ -208,7 +205,7 @@ NO COMPLETION CLAIMS WITHOUT CONSTITUTIONAL COMPLIANCE CHECK
 
 #### 4.0.5 内容覆盖度检查
 
-逐项确认以下 8 个内容类别在项目资产中有明确对应文件或章节。对「需补充」项，在项目 AI 规范文件（CLAUDE.md / .cursor/rules/）对应章节新增内容；如果 `docs/review-checklist.md` 或 `docs/delivery-checklist.md` 不存在，创建之。
+逐项确认以下 8 个内容类别在项目资产中有明确对应文件或章节。对「需补充」项，在项目 AI 规范文件（CLAUDE.md / .cursor/rules/）对应章节新增内容；如果 `docs/review-checklist.md` 或 `docs/delivery-checklist.md` 不存在，创建之。项目类型不适用的类别标注 N/A（如 CLI 工具无需"系统架构"文档）。
 
 | 类别        | 典型位置                                            | 状态      |
 | ----------- | --------------------------------------------------- | --------- |
@@ -299,33 +296,7 @@ NO COMPLETION CLAIMS WITHOUT CONSTITUTIONAL COMPLIANCE CHECK
 
 #### 4.7 资产可维护性保障
 
-在项目 AI 规范文件（CLAUDE.md 或 .cursor/rules/）中确认存在以下维护机制段落（如不存在则新增）：
-
-```markdown
-
-## 资产维护机制
-
-### 更新触发条件
-
-- Review 发现新的通用规则 → 追加到对应章节
-- 缺陷修复发现新的反模式 → 追加到编码规范
-- AI 输出偏差 → 追加到约束规则
-
-### 版本记录
-
-| 日期 | 更新者 | 更新内容 | 关联任务 |
-| ---- | ------ | -------- | -------- |
-
-### 规则管理层级
-
-- 项目级规则集中在根目录 CLAUDE.md / .cursor/rules/
-- 模块级规则在各模块 CLAUDE.md / .cursor/rules/
-- 任务级规则在 docs/tasks/{slug}/task-rules.md
-- 冲突时优先级：项目级 > 模块级 > 任务级
-
-```
-
-每次更新项目 AI 规范文件后，向"版本记录"表追加一行。
+确认项目 AI 规范文件（CLAUDE.md 或 .cursor/rules/）中存在「资产维护机制」段落（含更新触发条件、版本记录表、规则管理层级），如不存在则按 CLAUDE.md §七.2 消费方契约原则新增。每次更新后向"版本记录"表追加一行。
 
 ### Phase 5：个人复盘
 
@@ -333,15 +304,13 @@ NO COMPLETION CLAIMS WITHOUT CONSTITUTIONAL COMPLIANCE CHECK
 
 1. **本次任务回顾**：做得好的 + 可以改进的 + 意外发现（具体事例，不是泛泛而谈）
 2. **AI 协作经验**：提示词优化经验 + 团队协作改进建议
-3. **新规则沉淀**（§二.5）：列出本次发现的可固化规则，注明写入位置和理由。对每条新规则，必须同时执行写入——追加到目标文件（项目 AI 规范 / 模块 AI 规范 / task-rules.md），并在 12-asset-update.md 中记录变更
+3. **新规则沉淀**（§二.5）：列出本次发现的可固化规则，注明写入位置和理由。**固化门槛**：同类问题在本次任务中出现 ≥ 2 次（模式），或该问题可在未来任务中导致 P0/P1（严重性）。一次性 P2/P3 发现仅记录到 task-rules.md。对每条新规则，必须同时执行写入——追加到目标文件（项目 AI 规范 / 模块 AI 规范 / task-rules.md），并在 12-asset-update.md 中记录变更
 4. **改进承诺**（§三）：具体行动 + 预期效果
 
 > 重点：§二.5 的新规则沉淀是质量检查 D4.4 的关键证据，不可省略。"发现规则但未写入目标文件"视为未完成。
 
 ## 产出文件
 
-每个文件必须严格遵循模板格式（模板文件见 `references/` 目录）。
-
 | 文件 | 模板位置 | 说明 |
 | ---- | -------- | ---- |
 | `11-review.md` | `references/11-review-template.md` | 代码审查报告 |
@@ -352,8 +321,6 @@ NO COMPLETION CLAIMS WITHOUT CONSTITUTIONAL COMPLIANCE CHECK
 
 ## STOP Signals
 
-如果你发现自己即将做以下任何一件事——立即停止，重新审视：
-
 - 只审查代码不检查 Constitutional 合规，或跳过三视角对抗审查
 - 发现 P0/P1 问题不路由而自己修复
 - 资产更新缺少消费方契约三要素（触发条件/可执行指令/示例）
@@ -385,12 +352,6 @@ reviewAgent 完成
 → 编排器将补全团队级证据并交付用户验收
 ```
 
-## 下一步
-
-- 产出 11-13 文件后，推荐使用 `team-orchestrator` 补全团队证据并交付
-- 如果收到审查反馈，使用 `team-feedback` 应对
-- 如果分支需要处理，使用 `team-finish`
-
 ## 集成关系
 
 **被谁调用：**