team-skills 1.5.3 → 1.6.2

package/CHANGELOG.md

@@ -7,6 +7,50 @@
 
 ## [Unreleased]
 
+## [1.6.2] - 2026-06-29
+
+### 变更
+
+- team-orchestrator: Step 1.5.2 从自动创建功能分支改为分支策略选择（Fork/不Fork），用户显式选择是否创建新分支
+- team-orchestrator: 移除"当前分支≠基准分支时自动跳过"的隐式规则，仅保留 `--no-branch` 显式跳过
+- team-orchestrator: Mermaid + ASCII 流程图分支步骤标签同步更新
+- team-finish: Step 2 新增当前分支获取 + 基准分支守卫（`branch == base_branch` 时 BLOCKED）
+- team-finish: Step 3 选项模板增加分支信息展示，选项描述使用具名分支变量 `{branch}`
+
+## [1.6.1] - 2026-06-28
+
+### 变更
+
+- team-spec: Phase 2.5 用户审阅从 REPEAT MAX=3 改为无限循环——用户未通过则持续迭代，每次修改/追加后主动请求确认
+
+## [1.6.0] - 2026-06-28
+
+### 新增
+
+- team-spec: Phase 1.5 显式迭代澄清（REPEAT MAX=5），支持多轮需求修改和追加
+- team-spec: Phase 2.5 用户审阅反馈循环（无次数限制，用户未通过则持续迭代），每次回复后重新请求确认
+- team-spec: Phase 3 多角色轮审（实现者/测试者/攻击者/用户/运维者）+ 自动修复循环（REPEAT MAX=3），每角色有专属 SDD 章节审查焦点
+- team-spec: Phase 3 前置说明——方案执行者是 AI Agent，规格须比人类版本更精确、零歧义
+- team-spec: 反橡皮图章双 TRAP——每角色至少 1 条观察 + 每轮至少 1 个改进项
+- team-spec: ROLE 对抗自检从 3 视角扩展为 5 视角（+用户、+运维者）
+- team-finish: 新增默认 Option 1「合并到主分支并推送」（push 功能分支留档 → merge → push 主分支 → 清理本地功能分支）
+- team-finish: 选项展示增加适用场景说明，帮助用户选择
+
+### 变更
+
+- team-finish: 选项从 5 个精简为 4 个，移除「仅本地合并」（团队协作反模式），重新编号
+- team-orchestrator: Mermaid 流程图 Step 7 标签对齐实际标题「分支完成处理」
+- team-orchestrator: Step 7 team-finish 选项描述更新为新选项名称
+- team-orchestrator: NEXT 移除与 Step 7 重复的 team-finish 推荐
+- team-spec: STOP_SIGNALS 从 4 项扩展为 6 项（+跳过 Phase 2.5 用户审阅、+跳过 Phase 3 多角色轮审）
+- team-spec: SELF_CHECK 新增 Phase 2.5 用户审阅确认 + Phase 3 多角色轮审执行验证
+- team-spec: ROLE 系统提示词流程描述补充 Phase 2.5 和 Phase 3
+- team-debug: Rule #7 引用澄清——区分编排器跨 Agent 回退（≤ 2 次）vs Skill 内部修复重试（≤ 3 次）
+
+### 修复
+
+- 7 个 reference 模板对齐 SKILL.md 内联骨架：11-review-template（章节顺序+表结构重写）、12-asset-update-template（补充消费方契约列+8 类覆盖度表）、14-team-template（§编号+§四表结构）、15-brief-template（§编号+占位符）、13-retrospective-template（header 元数据）、review-checklist-template（性能+安全检查项）、delivery-checklist-template（章节引用）
+
 ## [1.5.3] - 2026-06-28
 
 ### 修复

package/README.md

@@ -373,6 +373,34 @@ Team Skills 融合了业界多个 AI 协作框架的精华：
 
 ---
 
+### 推荐：禁用 EnterPlanMode（Claude Code）
+
+Team Skills 的每个 Skill 都定义了完整的结构化工作流（Phase/Step），不需要 Claude Code 的 `EnterPlanMode`。长对话中 LLM 可能自动切入 plan mode，绕过 Skill 流程（跳过 TDD、根因调查、有向图调度等纪律流程）。
+
+在项目的 `.claude/settings.json` 中添加 PreToolUse Hook 可彻底阻止：
+
+```json
+{
+  "hooks": {
+    "PreToolUse": [
+      {
+        "matcher": "EnterPlanMode",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "echo 'BLOCKED: team-skills STEPS 是完整工作流，不需要 EnterPlanMode。' >&2; exit 2"
+          }
+        ]
+      }
+    ]
+  }
+}
+```
+
+> `exit 2` 会阻止工具调用并将 stderr 消息反馈给 LLM。此 Hook 仅影响当前项目，不影响其他项目中 EnterPlanMode 的正常使用。
+
+---
+
 ## 🔧 本地开发
 
 ```bash

package/package.json

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

package/skills/team-debug/SKILL.md

@@ -218,7 +218,7 @@ NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST
 
 - **Rule #9 TDD 顺序不可逆**：修复 bug 必须先写失败的回归测试再写修复代码 `_team-rules/first-principles.md: First Principle #2`
 - **Rule #3 产出必须验证**：修复完成后必须执行验证协议 `_team-rules/verification-protocol.md: 验证执行步骤` `_team-rules/first-principles.md: First Principle #4`
-- **Rule #7 回退次数上限**：3 次修复失败必须触发 `ASK_HUMAN`，不可无限重试 `_team-rules/first-principles.md: First Principle #1`
+- **Rule #7 回退次数上限**：编排模式下同一 source→target 对回退 ≤ 2 次触发 `ASK_HUMAN`；Skill 内部修复重试 ≤ 3 次后 `BLOCKED` `_team-rules/first-principles.md: First Principle #1`
 - **Rule #2 有向图回退**：调试发现根源在 spec 歧义/遗漏 → `ROLLBACK` `team-spec` `_team-rules/first-principles.md: First Principle #4`
 
 ## SELF_CHECK

package/skills/team-finish/SKILL.md

@@ -94,10 +94,12 @@ NO BRANCH COMPLETION WITHOUT TEST VERIFICATION FIRST
 - **IF** `exit_code == 0` → 逐条排除占位符/测试值/注释 → 真实凭证 → **BLOCKED**，**WRITE**（对话中）凭证位置，要求修复后重新验证
 - **ELSE** → **GOTO** Step 2
 
-### Step 2：确定基准分支
+### Step 2：确定当前分支与基准分支
 
 > 精确找到合并目标。基准错误 = 合并到错误分支，后果比不合并更糟。
 
+**EXEC** `git branch --show-current` → **ASSERT** `exit_code == 0` → 获取 `branch`
+
 **RESOLVE** `base_branch`（首个命中即停）：
 
 1. `READ("docs/tasks/{slug}/.checkpoint.json").base_branch`
@@ -112,6 +114,8 @@ NO BRANCH COMPLETION WITHOUT TEST VERIFICATION FIRST
 
 - 失败（分支无公共祖先）→ **BLOCKED**，触发 **ASK_HUMAN**
 
+**IF** `branch == base_branch` → **WRITE**（对话中）"当前已在基准分支 {base_branch} 上，无功能分支需要完成。" → **BLOCKED**
+
 ### Step 3：展示选项
 
 > 让用户在完整信息下做选择。选项列表必须覆盖所有合理路径，不替用户预判。
@@ -119,14 +123,26 @@ NO BRANCH COMPLETION WITHOUT TEST VERIFICATION FIRST
 **WRITE**（对话中）选项列表：
 
 ```
-实现完成。请选择后续操作：
+当前分支：{branch}，基准分支：{base_branch}
+实现完成，测试已通过。请选择集成方式：
+
+1. [默认] 合并到 {base_branch} 并推送
+   → push {branch}（留档） → 切换到 {base_branch} → merge → push → 清理 {branch}
+   适用：有合并权限，可直接集成
+
+2. 创建 Pull Request
+   → push {branch} → 创建 PR 等待审查
+   适用：需要 Code Review 或 CI 门禁
+
+3. 保留当前分支
+   → 不做任何操作，{branch} 原样保留
+   适用：尚需打磨，或等待外部依赖就绪
 
-1. 本地合并到 {base_branch}
-2. 推送并创建 Pull Request
-3. 保留当前分支（稍后处理）
-4. 丢弃本次工作
+4. 丢弃本次工作（需二次确认）
+   → 切换到 {base_branch} → 强制删除 {branch}
+   适用：实验性工作，确认不再需要
 
-请选择：
+请选择 [1]：
 ```
 
 ### Step 4：执行选择
@@ -137,19 +153,25 @@ NO BRANCH COMPLETION WITHOUT TEST VERIFICATION FIRST
 
 **MATCH** `user_choice`：
 
-- `Option 1`（本地合并）：
-  1. **EXEC** `git checkout {base_branch} && git pull`
+- `Option 1`（合并到 {base_branch} 并推送，默认）：
+  1. **EXEC** `git push -u origin {branch}`
+     - **ASSERT** `exit_code == 0`
+       - 失败（auth 错误、远程未配置）→ **WRITE**（对话中）错误信息给用户，**BLOCKED**
+  2. **EXEC** `git checkout {base_branch} && git pull`
      - **ASSERT** `exit_code == 0`
        - 失败 → **WRITE**（对话中）错误信息，**BLOCKED**
-  2. **EXEC** `git merge {branch} --no-ff`
+  3. **EXEC** `git merge {branch} --no-ff`
      - **IF** 合并冲突：
        - **GOTO** 子步骤 4.1
      - **ELSE**：
        - 继续下一步
-  3. **EXEC** 项目测试命令 — 声明"通过"前须执行验证协议 `_team-rules/verification-protocol.md: 验证执行步骤`
+  4. **EXEC** 项目测试命令 — 声明"通过"前须执行验证协议 `_team-rules/verification-protocol.md: 验证执行步骤`
      - **ASSERT** `exit_code == 0` && `failures == 0`
        - 失败 → 记录回归详情 → **BLOCKED**
-  4. **EXEC** `git branch -d {branch}`
+  5. **EXEC** `git push`
+     - **ASSERT** `exit_code == 0`
+       - 失败 → **WRITE**（对话中）错误信息，**BLOCKED**
+  6. **EXEC** `git branch -d {branch}`
      - **IF** `exit_code != 0` → **WRITE**（对话中）"分支未完全合并，需 -D 强制删除？"，等待用户确认
 
 - `Option 2`（创建 PR）：

package/skills/team-orchestrator/SKILL.md

@@ -11,7 +11,7 @@ description: Use when task needs full spec→impl→test→review pipeline with
 
 ```mermaid
 flowchart TD
-    CONFIRM_GOAL["CONFIRM_GOAL: 人类确认目标"] --> branch["创建功能分支"]
+    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 实现"]
@@ -22,7 +22,7 @@ flowchart TD
     team-review -->|"P0/P1 问题"| team-impl
     team-review -->|"spec 遗漏"| team-spec
     team-review -->|"无问题"| teamEvidence["Step 6: 团队证据"]
-    teamEvidence --> finish["Step 7: finish-review 集成"]
+    teamEvidence --> finish["Step 7: 分支完成处理"]
     finish --> HUMAN_ACCEPT["HUMAN_ACCEPT: 人类验收"]
     HUMAN_ACCEPT --> archive["Step 7.5: 归档"]
     archive --> qualityCheck["Step 8: 质量检查"]
@@ -102,8 +102,8 @@ NO AGENT DISPATCH WITHOUT CONFIRM_GOAL HUMAN CONFIRMATION FIRST
                      │ 确认  │ 不确认 → 返回修改
                      ▼       └────────┐
               ┌──────────────────┐     │
-              │  创建功能分支     │     │
-              │  {slug} 分支     │     │
+              │  分支策略选择     │     │
+              │  Fork / 不Fork   │     │
               └──────┬───────────┘     │
                      │                 │
                      ▼                 │
@@ -417,14 +417,34 @@ NO AGENT DISPATCH WITHOUT CONFIRM_GOAL HUMAN CONFIRMATION FIRST
 3. **FOR** `name` **IN** [`main`, `master`, `develop`]：**EXEC** `git show-ref --verify refs/heads/{name}` → **IF** `exit_code == 0` → 首个存在即停
 4. *NONE* → **ASK_HUMAN**，请求用户指定基准分支
 
-#### 1.5.2 创建功能分支
+#### 1.5.2 分支策略选择
 
-1. **EXEC** `git branch --show-current` → **ASSERT** `exit_code == 0` → 获取当前分支名
+1. **EXEC** `git branch --show-current` → **ASSERT** `exit_code == 0` → 获取 `current_branch`
 2. **EXEC** `git status --porcelain` → **ASSERT** `exit_code == 0`
    - **IF** `output` NOT_EMPTY → **GOTO** 1.5.2.1
-3. **EXEC** `git checkout -b {slug}`
-   - **IF** `exit_code != 0`（分支已存在）→ **EXEC** `git checkout {slug}` → **ASSERT** `exit_code == 0`
-4. **WRITE** checkpoint：`current_step=Step 2, branch={slug}, base_branch={基准分支名}, completed_steps 追加 Step 1.5`
+
+3. **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：处理未提交变更
 
@@ -434,16 +454,15 @@ NO AGENT DISPATCH WITHOUT CONFIRM_GOAL HUMAN CONFIRMATION FIRST
 
 **MATCH** `user_choice`：
 
-- `stash 后继续` → **EXEC** `git stash` → **ASSERT** `exit_code == 0` → **GOTO** 1.5.2 步骤 3
-- `先提交再继续` → 等待用户提交 → **GOTO** 1.5.2 步骤 3
+- `stash 后继续` → **EXEC** `git stash` → **ASSERT** `exit_code == 0` → **GOTO** 1.5.2 步骤 3（展示分支策略选项）
+- `先提交再继续` → 等待用户提交 → **GOTO** 1.5.2 步骤 3（展示分支策略选项）
 - `取消` → **BLOCKED**
 - *DEFAULT* → 请求用户从以上选项中选择
 
 不自动 stash 或丢弃。
 
-**跳过条件**（不创建分支）：
+**跳过条件**（跳过分支策略选择，不展示选项）：
 
-- **IF** 当前分支名 ≠ `base_branch` → 使用当前分支，checkpoint 中 `branch` 记录当前分支名
 - **IF** 用户指定 `--no-branch` → 直接在当前分支上工作
 
 **恢复场景**：**IF** 断点续传（checkpoint 已有 `branch` 字段）→ **ASSERT** `当前分支 == checkpoint.branch`。不一致 → 提示用户切换分支，不自动切换。
@@ -821,7 +840,7 @@ TDD 强制要求：每个功能点必须先 git commit 失败测试（test: {功
 **ROUTE** `team-finish`：
 
 - 传递 checkpoint 中的 `branch` 和 `base_branch` 信息
-- `team-finish` 将验证测试 → 展示选项（merge/PR/keep/discard）→ 执行用户选择
+- `team-finish` 将验证测试 → 展示集成选项（合并并推送/创建 PR/保留/丢弃）→ 执行用户选择
 
 **IF** `team-finish` 报告测试不通过 → **ROLLBACK** team-impl（附失败详情），修复完成后 **GOTO** Step 7。
 
@@ -1052,5 +1071,5 @@ TDD 强制要求：每个功能点必须先 git commit 失败测试（test: {功
 
 ## NEXT
 
-- 编排完成 → 使用 `team-finish` 合并分支
 - 需要协作评分 → 使用 `team-score` 获取质量评分
+- 开始下一个功能 → 使用 `team-brainstorm` 或 `team-spec`

package/skills/team-orchestrator/references/14-team-template.md

@@ -2,7 +2,7 @@
 
 > Team 编排器产出 | {日期}
 
-## 一、角色分工
+## §一 角色分工
 
 | 角色          | 负责人/Agent | 职责范围                                 | 产出物                        |
 | ------------- | ------------ | ---------------------------------------- | ----------------------------- |
@@ -12,7 +12,7 @@
 | Review & 沉淀 | team-review  | 代码审查、资产维护、复盘                 | 11-13 + task-rules + 资产更新 |
 | 编排协调      | team-orchestrator | 调度、一致性检查、交付包装               | 14-15                         |
 
-## 二、协作资产一致性检查（自动化验证）
+## §二 协作资产一致性检查（自动化验证）
 
 | 检查项                  | 验证方式                               | 结果  | 修复说明         |
 | ----------------------- | -------------------------------------- | ----- | ---------------- |
@@ -25,7 +25,7 @@
 
 > commit type 清单：`feat` / `fix` / `test` / `refactor` / `docs` / `chore` / `style` / `perf`
 
-## 三、个人贡献明细
+## §三 个人贡献明细
 
 | 贡献者       | 角色        | 主要贡献      | 产出物 | 提交数 |
 | ------------ | ----------- | ------------- | ------ | ------ |
@@ -34,18 +34,13 @@
 | {人名/Agent} | team-test   | 测试补全      | 09-10  | {N}    |
 | {人名/Agent} | team-review | Review + 沉淀 | 11-13  | {N}    |
 
-## 四、交叉 Review 质量统计
+## §四 质量审查数据
 
-| 指标                                | 数值 |
-| ----------------------------------- | ---- |
-| Review 发现问题总数                 | {N}  |
-| 其中真实问题（P0+P1+P2）              | {N}  |
-| 其中格式/风格建议（P3）                | {N}  |
-| 真实问题占比                        | {N}% |
-| 已修复问题数                        | {N}  |
-| 剩余风险数                          | {N}  |
+| 维度 | 真实问题数 | P0 | P1 | P2 |
+| ---- | ---------- | -- | -- | -- |
+| {dimension} | {count} | {n} | {n} | {n} |
 
-## 五、交付物完整性检查
+## §五 交付物完整性检查
 
 | 文件                | 状态 | 质量维度                      |
 | ------------------- | ---- | ----------------------------- |

package/skills/team-orchestrator/references/15-brief-template.md

@@ -2,13 +2,13 @@
 
 > Team 编排器产出
 
-## 一、30 秒 Elevator Pitch
+## §一 30 秒 Elevator Pitch
 
 > 用 3 句话概述：(1) 解决了什么问题 (2) 怎么做的（核心方案） (3) 效果如何（量化指标或对比）
 
-{填写}
+{3 句话：问题 → 方案 → 结果}
 
-## 二、关键决策解释
+## §二 关键决策解释
 
 （从 08-ai-decisions.md 中挑选 2-3 个最重要的决策）
 
@@ -16,13 +16,13 @@
 | ---- | -------- | ------------ | ------------------ |
 | ...  | ...      | ...          | ...                |
 
-## 三、AI 协作亮点
+## §三 AI 协作亮点
 
 - 提示词纠偏最有效的一次：{具体描述——原 prompt、偏离现象、修改后效果}
 - 拒绝 AI 建议最正确的一次：{具体描述——AI 建议什么、为什么拒绝、实际结果}
 - TDD 帮助发现的真实 bug：{具体描述——测试用例、失败输出、修复内容}
 
-## 四、测试覆盖概要
+## §四 测试覆盖概要
 
 | 维度 | 用例数 | 覆盖率 | 关键发现 |
 | ---- | ------ | ------ | -------- |
@@ -33,7 +33,7 @@
 
 > 数据来源：09-test-matrix.md + 10-test-report.md
 
-## 五、遗留风险坦诚说明
+## §五 遗留风险坦诚说明
 
 （从 11-review.md §四 剩余风险中摘录）
 
@@ -41,7 +41,7 @@
 | ---- | -------- | -------- | -------- |
 | ...  | P2/P3    | ...      | ...      |
 
-## 六、下次改进承诺
+## §六 下次改进承诺
 
 （从 13-retrospective.md §三中摘录）
 

package/skills/team-review/references/11-review-template.md

@@ -1,63 +1,39 @@
 # 代码审查报告
 
-> team-review 产出
+> team-review 产出 | {slug} | {日期}
 
 ## 一、审查范围
 
-| 维度       | 覆盖情况 |
-| ---------- | -------- |
-| 审查文件数 | {N}      |
-| 正确性     | ✅/⚠️    |
-| 可维护性   | ✅/⚠️    |
-| 性能       | ✅/⚠️    |
-| 安全       | ✅/⚠️    |
-| 测试覆盖   | ✅/⚠️    |
+| 项 | 内容 |
+|----|------|
+| 审查文件数 | {N} |
+| 变更行数 | +{N} / -{N} |
+| 对照规格 | 03-sdd.md §{sections} |
 
-## 二、Constitutional 合规检查
+## 二、问题清单
 
-| 规则             | 结果     | 说明 |
-| ---------------- | -------- | ---- |
-| 人类介入未被跳过 | ✅/⚠️/❌ | ...  |
-| 有向图回退       | ✅/⚠️/❌ | ...  |
-| TDD Iron Law     | ✅/⚠️/❌ | ...  |
-| Kill Switch 触发 | ✅/⚠️/❌ | ...  |
-| 分期交付         | ✅/⚠️/❌ | ...  |
-| 自我约束预算     | ✅/⚠️/❌ | ...  |
-| 来源标签         | ✅/⚠️/❌ | ...  |
-| 产出必须验证     | ✅/⚠️/❌ | ...  |
-| 回退次数上限     | ✅/⚠️/❌ | ...  |
-| 验证先行原则     | ✅/⚠️/❌ | ...  |
+| ID | 级别 | 维度 | 文件:行号 | 问题描述 | SDD 引用 | 处理方式 |
+|----|------|------|-----------|----------|----------|----------|
+| R1 | P{0-3} | {维度} | {file}:{line} | {具体描述} | §{ref} | 报告/直接修/记录 |
 
-## 三、发现的问题
+## 三、修复记录（P2 自修）
 
-### P0（必须修复）
+| 问题 ID | 修复内容 | 验证结果（exit_code + output 摘要） |
+|---------|----------|--------------------------------------|
+| R{N} | {修改描述} | ✅ `exit_code == 0`，{N} tests passed |
 
-| ID  | 文件 | 行号 | 问题描述 | 路由               | 修复方案 |
-| --- | ---- | ---- | -------- | ------------------ | -------- |
-| ... | ...  | ...  | ...      | → team-impl / → ASK_HUMAN | ...      |
+## 四、Constitutional 合规检查
 
-### P1（应该修复）
+| Rule | 检查方式 | 证据 | 结果 |
+|------|----------|------|------|
+| {rule_name} | {how_checked} | {evidence} | ✅/❌ P{N} |
 
-| ID  | 文件 | 行号 | 问题描述 | 路由               | 修复方案 |
-| --- | ---- | ---- | -------- | ------------------ | -------- |
-| ... | ...  | ...  | ...      | → team-impl / → ASK_HUMAN | ...      |
+## 五、审查结论
 
-### P2（建议修复）
+状态：{DONE / DONE_WITH_CONCERNS / NEEDS_CONTEXT / BLOCKED}
 
-| ID  | 文件 | 行号 | 问题描述 | 修复方式 | 修复内容 |
-| --- | ---- | ---- | -------- | -------- | -------- |
-| ... | ...  | ...  | ...      | 自行修复 | ...      |
+剩余风险：
 
-## 四、修复记录
+- {risk_description}
 
-| ID  | 修复方式    | 修复内容 | 验证方式     | 状态 |
-| --- | ----------- | -------- | ------------ | ---- |
-| ... | 自行修复    | ...      | 项目测试命令 | ✅   |
-| ... | → team-impl | ...      | ...          | ⏳   |
-| ... | → ASK_HUMAN        | ...      | ...          | ⏳   |
-
-## 五、剩余风险
-
-| 风险描述 | 影响 | 接受理由 |
-| -------- | ---- | -------- |
-| ...      | ...  | ...      |
+路由决策：{→ team-review 通过 / → team-impl 修复 / → team-spec 补全 / → ASK_HUMAN}

package/skills/team-review/references/12-asset-update-template.md

@@ -1,45 +1,28 @@
 # AI 协作资产更新记录
 
-> team-review 产出
+> team-review 产出 | {slug} | {日期}
 
-## 资产层级概览
+## 更新清单
 
-| 层级   | 文件                            | 更新状态         |
-| ------ | ------------------------------- | ---------------- |
-| 项目级 | CLAUDE.md / .cursor/rules/      | ✅/未更新        |
-| 模块级 | {module}/CLAUDE.md              | ✅/未更新/不适用 |
-| 任务级 | docs/tasks/{slug}/task-rules.md | ✅               |
+| 序号 | 资产文件 | 更新类型 | 触发条件 | 可执行指令 | 示例（✅/❌） |
+|------|----------|----------|----------|------------|--------------|
+| 1 | {file_path} | 新增/修改 | {when} | {do_what} | ✅ ... / ❌ ... |
 
-## 更新的资产
+## 内容覆盖度
 
-| 资产文件                   | 更新内容 | 更新理由 |
-| -------------------------- | -------- | -------- |
-| CLAUDE.md / .cursor/rules/ | ...      | ...      |
-| frontend/CLAUDE.md         | ...      | ...      |
-| CHANGELOG.md               | ...      | ...      |
-| docs/review-checklist.md   | ...      | ...      |
-| docs/delivery-checklist.md | ...      | ...      |
-
-## 新增规则说明
-
-### 规则 1：{规则标题}
-
-- **文件**：{项目 AI 规范 / 模块 AI 规范}
-- **规则内容**：{具体规则}
-- **触发条件**：{什么情况下触发}
-- **可执行指令**：{具体做什么}
-- **消费方**：{哪些下游 Skill 会用到这条规则}
-- **示例**：
-  - ✅ 正确：{好的做法}
-  - ❌ 错误：{坏的做法}
-- **创建理由**：{为什么需要这条规则——引用具体事件或发现}
-
-### 规则 2：{规则标题}
-
-...
+| 类别 | 位置 | 状态 |
+|------|------|------|
+| 业务术语 | {path} | ✅/需补充/N/A |
+| 系统架构 | {path} | ✅/需补充/N/A |
+| 代码结构 | {path} | ✅/需补充/N/A |
+| 接口约定 | {path} | ✅/需补充/N/A |
+| 编码规范 | {path} | ✅/需补充/N/A |
+| 测试要求 | {path} | ✅/需补充/N/A |
+| Review 标准 | {path} | ✅/需补充/N/A |
+| 交付要求 | {path} | ✅/需补充/N/A |
 
 ## 版本记录
 
-| 日期         | 更新者      | 更新内容   | 关联任务 |
-| ------------ | ----------- | ---------- | -------- |
-| {YYYY-MM-DD} | team-review | {更新摘要} | {slug}   |
+| 日期 | 更新者 | 更新内容 | 关联任务 |
+|------|--------|----------|----------|
+| {日期} | team-review | {summary} | {slug} |

package/skills/team-review/references/13-retrospective-template.md

@@ -1,6 +1,6 @@
 # 个人复盘
 
-> team-review 产出
+> team-review 产出 | {slug} | {日期}
 
 ## 一、本次任务回顾
 

package/skills/team-review/references/delivery-checklist-template.md

@@ -24,7 +24,7 @@
 - [ ] 06-tdd-log.md 每个功能点有完整 RED→GREEN→REFACTOR 记录（RED 含失败输出）
 - [ ] 09-test-matrix.md 四维覆盖（功能/边界/异常/代码）
 - [ ] 11-review.md 五维度审查完成
-- [ ] 13-retrospective.md §二.5 新规则沉淀已写入目标文件
+- [ ] 13-retrospective.md §三 新规则沉淀已写入目标文件
 
 ## 四、项目自定义交付项
 

package/skills/team-review/references/review-checklist-template.md

@@ -20,12 +20,17 @@
 - [ ] 无不必要的循环或重复计算
 - [ ] 无内存泄漏风险（资源已正确释放）
 - [ ] 数据库/网络调用已优化（无 N+1 查询、无冗余请求）
+- [ ] 并发安全（竞态条件、死锁、资源争用）
+- [ ] 数据量级评估（大表扫描、批量操作）
+- [ ] 成本影响评估（外部 API 调用频次、存储增长）
 
 ## 四、安全
 
 - [ ] 无注入风险（SQL/XSS/命令注入）
 - [ ] 无敏感信息泄露（密钥、token、个人数据）
 - [ ] 权限检查完整（访问控制无遗漏）
+- [ ] 外部 AI 数据脱敏（敏感数据未经脱敏直接传入外部 AI 服务）
+- [ ] 高风险操作人工确认（资金/权限/数据删除/对外发布无 HITL 机制）
 
 ## 五、测试覆盖
 

package/skills/team-spec/SKILL.md

@@ -14,10 +14,11 @@ description: Use when starting a new feature, need SDD spec, or requirements are
 ```
 角色：规格制定专家
 核心原则：好的规格定义系统不能做什么，而非只描述做什么
-流程：扫描代码库 → 识别承重约束 → 展示方案等待确认 → 产出 SDD
+流程：扫描代码库 → 识别承重约束 → 展示方案等待确认 → 产出 SDD → 用户审阅反馈迭代 → 多角色轮审自动修复
 约束：
 - 关键决策点须展示方案并等待确认
 - 规格须基于代码库扫描结果，非凭记忆
+- 产出后须经用户审阅（Phase 2.5）和五角色轮审（Phase 3）方可定稿
 ```
 
 ### 推理检查点
@@ -33,11 +34,13 @@ description: Use when starting a new feature, need SDD spec, or requirements are
 5. **失败模式**：规格有误时代价最高的失败是什么？
 6. **最小方案**：约束条件下的最小充分方案？
 
-**对抗自检**（三视角，不可跳过）：
+**对抗自检**（五视角，不可跳过）：
 
 - [ ] 攻击者：规格中哪些模糊地带会被错误解读？
 - [ ] 实现者：拿到规格有足够信息开始编码吗？
 - [ ] 测试者：每条业务规则都能写出对应测试吗？
+- [ ] 用户：这个设计解决了用户的真实痛点吗？有无遗漏的操作路径？
+- [ ] 运维者：上线后能监控、回滚、定位问题吗？
 
 ## IRON_LAW
 
@@ -137,13 +140,26 @@ NO CODE WITHOUT SPEC FIRST
 
 **IF** 3 个问题仍不足以消除歧义 → 说明仍不清楚的部分，询问用户继续澄清还是按当前假设推进。
 
+**REPEAT** **MAX**=5（需求澄清轮次）：
+
 **MATCH** `用户反馈`：
 
-- `确认` → **GOTO** Phase 2
-- `要求修改` → 调整后重新展示
+- `确认` → 退出 **REPEAT**，**GOTO** Phase 2
+- `要求修改` →
+  1. 根据用户反馈调整探索结论（重新 **READ** 源码/文档补充信息 **IF** 需要）
+  2. **WRITE**（对话中）更新后的探索结论（仅展示变更部分 + 新问题，不重复已确认内容）
+  3. 继续 **REPEAT**
+- `追加新需求` →
+  1. 评估新需求对影响范围和风险的影响
+  2. **WRITE**（对话中）更新后的影响范围 + 风险预判 + 新问题
+  3. 继续 **REPEAT**
 - `否决任务` → **DONE**（`结果: 用户主动终止，不进入实现阶段`）
 - *DEFAULT* → 澄清用户意图后重新匹配
 
+- *REPEAT_EXHAUSTED* → **WRITE**（对话中）"已进行 5 轮澄清，仍有未解决分歧"→ **ASK_HUMAN**：建议用户选择 (a) 按当前理解推进 (b) 终止任务
+
+> TRAP：多轮澄清后你会倾向于"差不多了赶紧开始写"。每轮结束前自问：用户最后一条反馈中的核心关切是否已被吸收到探索结论中？
+
 ### Phase 2：写规格文档
 
 > 产出的 SDD 必须让一个完全不了解项目的开发者仅凭 SDD 就能写出实现。每一条业务规则都能直接映射为测试用例——做不到就是规格不够具体。
@@ -254,13 +270,148 @@ NO CODE WITHOUT SPEC FIRST
 | "按需调整"、"根据实际情况" | 写出决策标准和条件 |
 | "参考 {其他文件}" 无具体内容 | 写出关键内容 + 引用路径 |
 
-### Phase 3：自检
+### Phase 2.5：用户审阅 + 反馈迭代
+
+> 写完不等于写对。用户是规格的最终消费方——只有用户确认"我理解了、我同意"才算规格定稿。跳过用户审阅进入实现 = 在未验证的地基上盖楼。
+
+> TRAP：你会倾向于"写完了直接进自检，反正后面有 CONFIRM_SPEC"。CONFIRM_SPEC 是编排器层面的确认，Phase 2.5 是 Skill 内部的质量反馈循环——两者不可互相替代。
+
+1. **WRITE**（对话中）规格摘要，展示关键产出供用户审阅：
+
+```
+## 规格产出摘要
+
+### SDD 核心内容
+- 业务规则：{N} 条（MUST {N} / SHOULD {N} / MAY {N}）
+- 关键设计决策：{N} 个（含拒绝方案）
+- 边界条件：{N} 个
+- 异常场景：{N} 个
+
+### 业务规则速览（用户重点审阅）
+| 编号 | 规则 | 强度 | Given → When → Then |
+|------|------|------|---------------------|
+| B1 | {规则} | MUST | {GWT 一句话概述} |
+| ... | ... | ... | ... |
+
+### 关键设计决策速览
+| 编号 | 决策 | 选择 | 拒绝方案 | 需要确认？ |
+|------|------|------|---------|-----------|
+| D1 | {决策} | {chosen} | {rejected} | ✅ 是 / — 已定 |
+
+### 修改边界
+- Allow：{文件列表}
+- Deny：{文件列表}
+```
+
+2. **IF** `mode == full` → 还展示 01-plan 分期策略 + 05-risk Kill Switch 条件
+
+3. **WRITE**（对话中）确认提示：`以上规格是否通过？（通过 / 修改 / 追加 / 否决）`
+
+**循环**：用户未确认通过前持续迭代，每次回复后重新请求确认。
+
+**MATCH** `用户反馈`：
+
+- `确认通过` → **GOTO** Phase 3
+- `修改规格` →
+  1. **READ** 用户反馈 → 定位需修改的章节和条目
+  2. **WRITE** 修改对应文件中的具体章节（不重写整个文件，仅修改用户指出的部分）
+  3. **WRITE**（对话中）修改摘要（变更前 → 变更后对比）
+  4. **WRITE**（对话中）确认提示：`修改已完成，规格是否通过？（通过 / 继续修改 / 追加 / 否决）`
+  5. 继续循环
+- `追加规格` →
+  1. **READ** 用户新增需求 → 评估影响范围变化
+  2. **IF** 新需求导致 04-boundary.md allow/deny 变更 → 同步更新
+  3. **WRITE** 追加内容到对应文件章节
+  4. **WRITE**（对话中）追加内容摘要 + 影响范围变化
+  5. **WRITE**（对话中）确认提示：`追加已完成，规格是否通过？（通过 / 修改 / 继续追加 / 否决）`
+  6. 继续循环
+- `否决方案` →
+  1. **WRITE**（对话中）否决原因记录
+  2. 已产出的规格文件保留在 slug 目录（供 Phase 1.5 重新探索时参考，不删除）
+  3. **GOTO** Phase 1.5（携带否决理由 + 已有规格文件路径，作为反面参考重新探索方案方向）
+- *DEFAULT* → 澄清用户意图后重新匹配
+
+### Phase 3：多角色轮审 + 自动修复循环
+
+> **前置说明**：本方案的执行者是 AI Agent（team-impl），不是人类开发者。审查时应以 AI 的能力边界和行为特征为基准：AI 严格遵循字面指令但缺乏常识推断、擅长模式匹配但容易过度泛化、不会主动质疑规格中的矛盾。因此规格必须比给人类的更精确、更显式、零歧义。
+
+> 同一个人换五个视角比一个视角看五遍更有效。每个角色有不同的盲区和关注点——实现者关心"能不能写"，攻击者关心"怎么搞坏"，测试者关心"怎么证伪"。
+
+> TRAP：你刚写完 SDD，此刻最不适合评价它的质量——实现偏见会让你觉得"写了就是对的" `_team-rules/first-principles.md: First Principle #2`。切换角色是对抗实现偏见的主要手段。
+
+**REPEAT** **MAX**=3（审查-修复循环）：
 
-> 切换到"攻击者"视角——假设这份 SDD 有致命遗漏，你的任务是找到它。"看起来完整"不等于"真的完整"。
+#### 3.1 多角色轮审
 
-> TRAP：你刚写完 SDD，此刻最不适合评价它的质量——实现偏见会让你觉得"写了就是对的" `_team-rules/first-principles.md: First Principle #2`。逐条对照检查清单，不要凭感觉。
+> 每个角色独立审视 SDD，产出角色级问题清单。角色之间不共享结论——后一个角色不因前一个角色"没发现问题"就放松审查。
 
-**GATE** 产出前逐条检查（不通过则补全后再输出）：
+**FOR** `role` **IN** [`实现者`, `测试者`, `攻击者`, `用户`, `运维者`]：
+
+**MATCH** `role`：
+
+- `实现者`（能不能照着规格写出代码？）：
+  - **READ** `03-sdd.md` §四 数据流 + §五 输入规格 + §六 输出规格
+  - 审查焦点：
+    - [ ] 每个接口的入参类型、约束、默认值是否明确到可直接定义函数签名？
+    - [ ] 数据流中的调用链是否有未定义的中间状态或竞态窗口？
+    - [ ] 依赖的外部接口/服务是否给出了超时、重试、熔断策略？
+    - [ ] 是否有"参考实际情况""按需处理"等无法编码的模糊表述？
+
+- `测试者`（每条业务规则能否直接映射为测试用例？）：
+  - **READ** `03-sdd.md` §二 业务规则 + §七 边界条件 + §八 异常场景
+  - 审查焦点：
+    - [ ] 每条 GWT 场景中 Given/When/Then 是否包含具体值（数字、字符串、状态码）？
+    - [ ] 边界条件是否覆盖极值（0、空、最大值、负数、超长字符串）？
+    - [ ] 异常场景是否给出确切错误码和错误消息，而非"返回错误"？
+    - [ ] 是否存在 SHOULD/MAY 规则无法确定通过/失败标准的情况？
+
+- `攻击者`（如何用合法但恶意的输入搞坏系统？）：
+  - **READ** `03-sdd.md` §五 输入规格 + §七 边界条件 + §八 异常场景
+  - 审查焦点：
+    - [ ] 输入参数有无注入点（SQL/命令/XSS/路径穿越）？规格是否要求转义或参数化？
+    - [ ] 并发场景：同一资源被多个请求同时修改时行为是否定义？
+    - [ ] 重放攻击：同一操作重复提交时是否幂等？规格是否定义了幂等策略？
+    - [ ] 权限边界：规格是否定义了越权访问的拒绝行为（非授权用户/跨租户）？
+
+- `用户`（从使用者角度，这个设计解决了真实痛点吗？）：
+  - **READ** `03-sdd.md` §一 背景与动机 + §九 验收 Checklist
+  - 审查焦点：
+    - [ ] 用户故事（§一）中描述的痛点在业务规则（§二）中是否有对应解决？
+    - [ ] 错误消息对终端用户是否可理解、可行动（"用户 ID 无效" vs "Error 42"）？
+    - [ ] 是否存在用户需要但规格未覆盖的操作路径（如撤销、重试、取消）？
+    - [ ] 验收 Checklist 是否覆盖了用户关心的核心场景，而非只有技术指标？
+
+- `运维者`（上线后能不能监控、能不能回滚、出问题能不能定位？）：
+  - **READ** `03-sdd.md` §三 关键设计决策 + §八 异常场景
+  - 审查焦点：
+    - [ ] 关键操作是否有日志/指标/链路追踪点？规格是否定义了可观测性要求？
+    - [ ] 数据迁移/Schema 变更是否向后兼容？回滚是否安全？
+    - [ ] 外部依赖故障时的降级策略是否定义（超时后返回什么、缓存策略是什么）？
+    - [ ] 是否有容量预估（数据量级、QPS、存储增长）？超限时的行为是否定义？
+
+- *DEFAULT* → 跳过未知角色
+
+> TRAP：你会倾向于让每个角色都给出"无问题"以快速通过。对抗方法：每个角色**必须**至少给出 1 条观察（可以是"已确认 X 合规"的正面观察，但不可为空）。
+
+> TRAP：橡皮图章化——5 个角色全部给出"已确认合规"的正面观察，实际未深入审视。对抗方法：每轮至少有 1 个角色发现可改进项（即使是 P3 级建议），否则视为审查深度不足，至少重审实现者和攻击者两个角色。
+
+**WRITE**（对话中）多角色审查汇总：
+
+```
+## 多角色审查结果（第 {N} 轮）
+
+| 角色 | 发现问题数 | 关键发现 |
+|------|-----------|---------|
+| 实现者 | {N} | {最重要的 1-2 条} |
+| 测试者 | {N} | {最重要的 1-2 条} |
+| 攻击者 | {N} | {最重要的 1-2 条} |
+| 用户   | {N} | {最重要的 1-2 条} |
+| 运维者 | {N} | {最重要的 1-2 条} |
+```
+
+#### 3.2 GATE 检查
+
+**GATE** 产出逐条检查：
 
 **通用项**（完整 + 精简模式均检查）：
 
@@ -289,9 +440,37 @@ NO CODE WITHOUT SPEC FIRST
 | 架构 | SDD 含 ASCII 数据流图 |
 | 工具 | prompt-template.md 独立产出（五要素）、pm-truth-ledger 已追加（`IF` EXISTS） |
 
+#### 3.3 自动修复
+
+**IF** GATE 全部通过 && 多角色审查问题数 == 0 → 退出 **REPEAT**，规格定稿
+
+**ELSE**（存在未通过项或角色发现的问题）：
+
+1. **FOR** `issue` **IN** `GATE 未通过项 + 多角色发现的问题`：
+   - **MATCH** `issue`：
+     - 章节缺失 → **READ** 对应模板 → **WRITE** 补全章节到目标文件
+     - GWT 格式不合规 → **READ** `03-sdd.md` §二 → 逐条重写为 Given/When/Then + 具体值
+     - 占位符残留 → **READ** 上下文 → **WRITE** 替换为具体内容
+     - 来源标签缺失 → **READ** 对应结论 → 追加 `{extracted}`/`{inferred}`/`{ambiguous}` 标签
+     - 决策表缺少拒绝方案 → **READ** `03-sdd.md` §三 → 补充拒绝方案和理由
+     - 接口定义模糊（实现者发现）→ **READ** 源码相关文件 → 补充入参类型/约束/默认值
+     - 边界值缺失（测试者发现）→ 补充具体极值、空值、格式异常到 §七
+     - 安全场景遗漏（攻击者发现）→ 追加安全相关业务规则到 §二 或异常场景到 §八
+     - 用户路径缺失（用户角色发现）→ 补充操作路径到 §二 或验收条件到 §九
+     - 运维要求缺失（运维者发现）→ 补充可观测性/降级/容量到 §三 或 §八
+     - *DEFAULT* → 记录问题，按最佳判断补全
+2. **WRITE**（对话中）本轮修复摘要：`修复 {N} 个问题：{问题列表简述}`
+3. 继续 **REPEAT**（重新执行 GATE 检查）
+
+- *REPEAT_EXHAUSTED* → **WRITE**（对话中）"3 轮自修后仍有 {N} 项未通过" → 列出未解决项 → **ASK_HUMAN**：建议用户 (a) 按当前状态推进并在 review 阶段补全 (b) 手动介入修复
+
+> SIGNAL：同一检查项连续 2 轮未能修复 → 可能是信息不足而非执行错误，考虑是否需要 **GOTO** Phase 1.5 向用户补充澄清。
+
 ## STOP_SIGNALS
 
 - **跳过**用户确认直接写文件，或一次抛出所有问题不等回复
+- **跳过** Phase 2.5 用户审阅，写完规格直接进入自检或交付
+- **跳过** Phase 3 多角色轮审，或以全部"已确认合规"的正面观察橡皮图章通过
 - **列出**文件名却不列依赖关系
 - **声明**"无风险"，或产出后发现遗漏不补全
 - **凭空**推断而非扫描源码
@@ -314,7 +493,9 @@ NO CODE WITHOUT SPEC FIRST
 **GATE** Skill 完成前自检（全部通过才声明完成）：
 
 - [ ] **ASSERT** `完整模式产出文件数 == 6` || `精简模式产出文件数 == 2`
-- [ ] **ASSERT** `Phase 3 检查全部通过（通用项 + 适用的附加项）`
+- [ ] **ASSERT** `Phase 3 多角色轮审 + GATE 检查全部通过（通用项 + 适用的附加项）`
+- [ ] **ASSERT** `Phase 3 每个角色至少 1 条观察（非全空）`
+- [ ] **ASSERT** `Phase 2.5 用户审阅确认 == true`
 - [ ] **ASSERT** `Phase 1.5 用户确认 == true`
 - [ ] **ASSERT** `"TBD"/"TODO"/"待补充" 匹配数 == 0`
 - [ ] **ASSERT** `来源标签使用数 >= 1`