team-skills 1.5.2 → 1.6.1

package/CHANGELOG.md

@@ -7,6 +7,49 @@
 
 ## [Unreleased]
 
+## [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
+
+### 修复
+
+- 全部 12 个 SKILL.md 在 frontmatter 后增加顶级 CRITICAL 约束，阻止 LLM 使用 EnterPlanMode 绕过 Skill 自身的结构化流程（有向图/TDD/根因调查）
+- constitutional-rules.md 新增 Rule #10「禁止外部规划工具替代 Skill 流程」+ 常见规避借口补充
+- team-orchestrator/team-impl/team-debug: ROLE 约束、Step 1 TRAP、STOP_SIGNALS、SELF_CHECK 四层防护
+- 清理 docs/tasks 历史产出并加入 .gitignore
+
 ## [1.5.2] - 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.2",
+  "version": "1.6.1",
   "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

@@ -15,6 +15,7 @@
 7. **回退次数上限** — 同阶段 ≤ 2 次，超过触发 ASK_HUMAN。两次未解决 = 信息不足，需人类介入（First Principle #1）
 8. **验证先行** — "通过"声明须基于当次新鲜执行的完整输出，上一轮结果是历史而非当前事实（First Principle #4）
 9. **TDD 顺序不可逆** — RED + commit 先于 GREEN + commit。后写测试 = 测试你构建的；先写测试 = 测试需求的（First Principle #2）
+10. **禁止外部规划工具替代 Skill 流程** — 不得使用 EnterPlanMode 等工具替代 SKILL.md 定义的 STEPS。每个 Skill 自身的 Phase/Step 就是完整的规划与执行流程，外部规划工具会绕过纪律流程（TDD、根因调查、有向图调度）（First Principle #4）
 
 ## 常见规避借口（不成立）
 
@@ -26,6 +27,7 @@
 | "改动太小不需要测试" | 至少运行相关测试 |
 | "先实现再补测试" | 先测试再实现 |
 | "代码已经写好了，补个测试就行" | 删除实现代码，从 RED 开始 |
+| "先规划一下再按流程走" | Skill 的 STEPS 就是规划，不需要 EnterPlanMode |
 | "先继续后面再修" | 立即修复，修复后重新验证 |
 | "这个失败跟我的改动无关" | 验证无关性（git stash → 运行 → 仍失败 = 确认无关并记录）；未验证 = 掩盖 |
 | "用户没要求写文档" | 文档是流程一部分 |

package/skills/team-brainstorm/SKILL.md

@@ -5,6 +5,8 @@ description: Use when requirements are fuzzy, need to discuss and form a plan be
 
 # Team Brainstorm — 讨论形成方案
 
+**CRITICAL: DO NOT use EnterPlanMode.** This skill defines its own structured workflow. Follow STEPS below directly.
+
 ## ROLE
 
 ### 系统提示词
@@ -245,7 +247,7 @@ NO IMPLEMENTATION WITHOUT USER APPROVED DESIGN FIRST
 
 ## CONSTITUTIONAL_RULES
 
-**REF** `_team-rules/constitutional-rules.md` — 9 条 Constitutional Rules
+**REF** `_team-rules/constitutional-rules.md` — 10 条 Constitutional Rules
 **REF** `_team-rules/first-principles.md` — 4 条第一性原理（First Principle #1 ~ #4）
 
 brainstorm 阶段尤其注意：

package/skills/team-debug/SKILL.md

@@ -5,6 +5,8 @@ description: Use when encountering any bug, test failure, or unexpected behavior
 
 # Team Debug — 系统调试
 
+**CRITICAL: DO NOT use EnterPlanMode.** This skill defines its own investigation workflow (Phase 1→Phase 5). EnterPlanMode bypasses systematic root cause analysis, causing fix-before-investigation (violates IRON_LAW). Follow STEPS below directly, starting from Phase 1.
+
 ## ROLE
 
 ### 系统提示词
@@ -60,6 +62,8 @@ NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST
 
 > 收集所有症状的完整描述，不遗漏任何错误细节。"差不多记住了"不算收集。
 
+> TRAP：不要使用 EnterPlanMode 来"先分析一下 bug"——本 SKILL.md 的 Phase 1→Phase 5 就是完整的调试流程。EnterPlanMode 会跳过系统性根因调查，导致基于初步印象直接写修复（违反 IRON_LAW）。
+
 > TRAP：你会倾向于读完错误信息第一行就跳到修复方案（"我觉得我知道问题在哪"）。强制自己读完完整 stack trace 和错误上下文。第一行是症状，最后几行才是根因。
 
 1. **READ** 完整错误信息 — 不跳过 stack trace、行号、错误码
@@ -173,6 +177,7 @@ NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST
 
 ## STOP_SIGNALS
 
+- **使用** EnterPlanMode 或其他外部规划工具替代根因调查流程（plan mode 中的阅读 ≠ 系统性根因调查）
 - **跳过**根因调查直接写修复代码
 - **修改**多个变量同时进行，无法隔离有效改动
 - **继续**尝试 3 次修复失败后仍不触发 `ASK_HUMAN`
@@ -204,7 +209,7 @@ NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST
 
 ## CONSTITUTIONAL_RULES
 
-**REF** `_team-rules/constitutional-rules.md` — 9 条 Constitutional Rules
+**REF** `_team-rules/constitutional-rules.md` — 10 条 Constitutional Rules
 **REF** `_team-rules/first-principles.md` — 4 条第一性原理（First Principle #1 ~ #4）
 **REF** `_team-rules/verification-protocol.md` — 5 步验证协议
 **REF** `_team-rules/spec-driven-workflow.md` — TDD 修复循环与有向图回退规则
@@ -213,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
@@ -226,7 +231,7 @@ NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST
 - [ ] **ASSERT** `修复失败次数 < 3` || `ASK_HUMAN 已触发`
 - [ ] **ASSERT** `同时修改变量数 <= 1`
 - [ ] **ASSERT** `无占位符残留（{N}、{slug} 等已被实际值替换）`
-- [ ] **ASSERT** `IRON_LAW 遵守` — 根因已确定后才修复，未跳过调查
+- [ ] **ASSERT** `IRON_LAW 遵守` — 根因已确定后才修复，未跳过调查、未使用 EnterPlanMode 替代调查流程
 - [ ] 我的假设如果错了，还有什么能解释所有已知症状？
 - [ ] 我是在修根因还是在修症状？根因仍在时这个修复能撑多久？
 

package/skills/team-feedback/SKILL.md

@@ -5,6 +5,8 @@ description: Use when receiving code review feedback, before implementing sugges
 
 # Team Feedback — 审查反馈应对
 
+**CRITICAL: DO NOT use EnterPlanMode.** This skill defines its own structured workflow. Follow STEPS below directly.
+
 ## ROLE
 
 ### 系统提示词
@@ -221,7 +223,7 @@ NO IMPLEMENTATION WITHOUT TECHNICAL VERIFICATION FIRST
 
 ## CONSTITUTIONAL_RULES
 
-**REF** `_team-rules/constitutional-rules.md` — 9 条 Constitutional Rules
+**REF** `_team-rules/constitutional-rules.md` — 10 条 Constitutional Rules
 **REF** `_team-rules/first-principles.md` — 4 条第一性原理（First Principle #1 ~ #4）
 **REF** `_team-rules/spec-driven-workflow.md` — TDD 逐项验证与有向图回退规则
 **REF** `_team-rules/verification-protocol.md` — verify_cmd 解析流程与 5 步验证协议

package/skills/team-finish/SKILL.md

@@ -5,6 +5,8 @@ description: Use when implementation is complete, all tests pass, and you need t
 
 # Team Finish — 分支完成处理
 
+**CRITICAL: DO NOT use EnterPlanMode.** This skill defines its own structured workflow. Follow STEPS below directly.
+
 ## ROLE
 
 > **分支生命周期**：`team-orchestrator` 在 CONFIRM_GOAL 确认后创建功能分支（Step 1.5），本 Skill 在流程尾部（Step 7）负责分支收尾。
@@ -117,14 +119,25 @@ NO BRANCH COMPLETION WITHOUT TEST VERIFICATION FIRST
 **WRITE**（对话中）选项列表：
 
 ```
-实现完成。请选择后续操作：
+实现完成，测试已通过。请选择集成方式：
+
+1. [默认] 合并到 {base_branch} 并推送
+   → push 功能分支（留档） → merge 到 {base_branch} → push {base_branch} → 清理本地功能分支
+   适用：有合并权限，可直接集成
+
+2. 创建 Pull Request
+   → push 功能分支 → 创建 PR 等待审查
+   适用：需要 Code Review 或 CI 门禁
 
-1. 本地合并到 {base_branch}
-2. 推送并创建 Pull Request
-3. 保留当前分支（稍后处理）
-4. 丢弃本次工作
+3. 保留当前分支
+   → 不做任何操作，功能分支原样保留
+   适用：尚需打磨，或等待外部依赖就绪
 
-请选择：
+4. 丢弃本次工作（需二次确认）
+   → 切回 {base_branch} → 强制删除功能分支
+   适用：实验性工作，确认不再需要
+
+请选择 [1]：
 ```
 
 ### Step 4：执行选择
@@ -135,19 +148,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）：
@@ -285,7 +304,7 @@ NO BRANCH COMPLETION WITHOUT TEST VERIFICATION FIRST
 
 ## CONSTITUTIONAL_RULES
 
-**REF** `_team-rules/constitutional-rules.md` — 9 条 Constitutional Rules
+**REF** `_team-rules/constitutional-rules.md` — 10 条 Constitutional Rules
 **REF** `_team-rules/first-principles.md` — 4 条第一性原理（First Principle #1 ~ #4）
 **REF** `_team-rules/verification-protocol.md` — verify_cmd 解析流程与 5 步验证协议
 **REF** `_team-rules/task-lifecycle.md` — 进度追踪与知识合并（§3）

package/skills/team-impl/SKILL.md

@@ -5,6 +5,8 @@ description: Use when SDD exists and you need TDD implementation with 06-08 docs
 
 # Team Impl — 实现
 
+**CRITICAL: DO NOT use EnterPlanMode.** This skill defines its own TDD workflow (RED→GREEN→REFACTOR). EnterPlanMode bypasses the TDD cycle, causing implementation-before-test (violates IRON_LAW). Follow STEPS below directly, starting from Phase 1.
+
 ## ROLE
 
 ### 系统提示词
@@ -115,6 +117,8 @@ NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST
 
 > 通过红-绿-重构循环逐个实现功能点。每个 GREEN 完成时代码应是"能工作的最简单方案"，不是"我能想到的最好方案"。
 
+> TRAP：不要使用 EnterPlanMode 来"先规划实现方案"——本 SKILL.md 的 Phase 1→Phase 4 就是完整的实现流程。EnterPlanMode 会跳过 RED→GREEN→REFACTOR 循环，导致先写实现再补测试（违反 IRON_LAW）。
+
 **FOR** `feature_point`（从 SDD 提取）：
 
 #### 循环 1：红（Red）— 写测试
@@ -343,13 +347,14 @@ NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST
 
 ## STOP_SIGNALS
 
+- **使用** EnterPlanMode 或其他外部规划工具替代 TDD 循环（plan mode 完成 ≠ RED 阶段完成）
 - **编码**前没 `READ` spec，或发现 spec 问题不 `ROLLBACK` 而自己决定
 - **跳过** RED 阶段直接写实现，或先写实现再补测试
 - **修改**测试让它通过（而非修改实现），或困惑不记录默默假设
 
 ## CONSTITUTIONAL_RULES
 
-**REF** `_team-rules/constitutional-rules.md` — 9 条 Constitutional Rules
+**REF** `_team-rules/constitutional-rules.md` — 10 条 Constitutional Rules
 **REF** `_team-rules/first-principles.md` — 4 条第一性原理（First Principle #1 ~ #4）
 **REF** `_team-rules/verification-protocol.md` — 5 步验证协议
 **REF** `_team-rules/spec-driven-workflow.md` — Spec-Driven 开发原则与 TDD 工作流
@@ -376,7 +381,7 @@ NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST
 - [ ] **ASSERT** `实际消耗 <= 01-plan.md 自我约束预算`
 - [ ] **ASSERT** `所有困惑已显式记录于 06-tdd-log.md 审计段落`
 - [ ] **ASSERT** `无占位符残留（{N}、{slug} 等已被实际值替换）`
-- [ ] **ASSERT** `IRON_LAW 遵守` — 未自行假设 spec、未跳过 TDD 顺序
+- [ ] **ASSERT** `IRON_LAW 遵守` — 未自行假设 spec、未跳过 TDD 顺序、未使用 EnterPlanMode 替代 TDD 循环
 - [ ] **IF** 发现 spec 问题 → **ASSERT** `已 ROLLBACK team-spec`
 - [ ] 我是否在某个 GREEN 阶段写了超出当前测试要求的代码？
 - [ ] 我是否有任何"通过"声明是基于上一轮输出而非本轮刚执行的结果？

package/skills/team-orchestrator/SKILL.md

@@ -5,6 +5,8 @@ description: Use when task needs full spec→impl→test→review pipeline with
 
 # Team Orchestrator — 流程编排器
 
+**CRITICAL: DO NOT use EnterPlanMode.** This skill defines its own structured workflow (Step 1→Step 8). EnterPlanMode bypasses the directed graph, skips sub-skill dispatch (team-spec/team-impl/team-test/team-review), and skips human intervention points (CONFIRM_GOAL/HUMAN_ACCEPT). Follow STEPS below directly, starting from Step 1.
+
 ## ROLE
 
 ```mermaid
@@ -20,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: 质量检查"]
@@ -45,6 +47,7 @@ flowchart TD
 - CONFIRM_GOAL/HUMAN_ACCEPT 任何模式下不可省略
 - 编排器不得自己写实现代码（必须 dispatch 子 Skill，不可亲自实现）
 - 子 Skill 不可用时不得自动降级为自我执行，必须 ASK_HUMAN 请示用户
+- 编排器不得使用 EnterPlanMode 等外部规划工具替代自身有向图流程——STEPS 定义的 Step 1→Step 8 就是规划与执行的全部流程
 ```
 
 ### 路由推理检查点
@@ -369,6 +372,8 @@ NO AGENT DISPATCH WITHOUT CONFIRM_GOAL HUMAN CONFIRMATION FIRST
 
 > 确保任务目标被准确理解，用户对方案方向有明确确认。跳过 CONFIRM_GOAL 是编排器最危险的错误——后续所有 Agent 的工作都建立在这个确认之上。
 
+> TRAP：不要使用 EnterPlanMode 来"先规划一下"——本 SKILL.md 的 Step 1→Step 8 就是完整的规划与执行流程。EnterPlanMode 会绕过有向图、跳过子 Skill 调度、跳过人类介入点，导致编排器退化为普通 Agent 直接写代码。
+
 1. **READ** 用户参数 → 提取任务描述
 2. **IF** `docs/tasks/` NOT_EXISTS → 创建目录，最大序号 = 0
    **ELSE** → **READ** `docs/tasks/` 已有目录 → 提取所有匹配 `NNNN-*` 格式的目录名中的四位数字前缀 → 取最大值记为最大序号（无匹配目录则最大序号 = 0）
@@ -816,7 +821,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。
 
@@ -984,13 +989,14 @@ TDD 强制要求：每个功能点必须先 git commit 失败测试（test: {功
 ## STOP_SIGNALS
 
 - **跳过** CONFIRM_GOAL 或 HUMAN_ACCEPT 人类介入点
+- **使用** EnterPlanMode 或其他外部规划工具替代 STEPS 定义的有向图流程（plan mode 完成 ≠ CONFIRM_GOAL 完成）
 - **延迟**回退（"先记着后面一起修"）
 - **信任** Agent 自我声明而不验证产出
 - **超出**预算不砍范围，或亲自执行实现代码而非 dispatch 子 Skill
 
 ## CONSTITUTIONAL_RULES
 
-**REF** `_team-rules/constitutional-rules.md` — 9 条 Constitutional Rules
+**REF** `_team-rules/constitutional-rules.md` — 10 条 Constitutional Rules
 **REF** `_team-rules/first-principles.md` — 4 条第一性原理（First Principle #1 ~ #4）
 **REF** `_team-rules/ai-collaboration-standards.md` — AI 协作资产与 Prompt 工程规范
 **REF** `_team-rules/spec-driven-workflow.md` — 有向图回退规则与回退次数上限
@@ -1013,7 +1019,7 @@ TDD 强制要求：每个功能点必须先 git commit 失败测试（test: {功
 - [ ] **IF** team-review 要求 → **ASSERT** `CHANGELOG.md 已更新`
 - [ ] **ASSERT** `进度账本已更新`
 - [ ] **ASSERT** `无占位符残留（{N}、{slug} 等已被实际值替换）`
-- [ ] **ASSERT** `IRON_LAW 遵守` — 未自己写实现代码、未跳过人类介入点
+- [ ] **ASSERT** `IRON_LAW 遵守` — 未自己写实现代码、未跳过人类介入点、未使用 EnterPlanMode 替代有向图流程
 - [ ] 我是否因为"这步很简单"而跳过了某个人类介入点？
 - [ ] 我是否把所有 Agent 的 concerns 都传达给了用户，还是悄悄忽略了某些？
 - [ ] 我是否在回退时传递了完整的四要素上下文（问题、位置、期望、建议），还是只说了"有 bug"？
@@ -1046,5 +1052,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/SKILL.md

@@ -5,6 +5,8 @@ description: Use when code + tests exist and you need structured review + asset
 
 # Team Review — 代码审查
 
+**CRITICAL: DO NOT use EnterPlanMode.** This skill defines its own structured workflow. Follow STEPS below directly.
+
 ## ROLE
 
 ### 系统提示词
@@ -466,7 +468,7 @@ NO COMPLETION CLAIMS WITHOUT CONSTITUTIONAL COMPLIANCE CHECK FIRST
 
 ## CONSTITUTIONAL_RULES
 
-**REF** `_team-rules/constitutional-rules.md` — 9 条 Constitutional Rules
+**REF** `_team-rules/constitutional-rules.md` — 10 条 Constitutional Rules
 **REF** `_team-rules/first-principles.md` — 4 条第一性原理（First Principle #1 ~ #4）
 **REF** `_team-rules/spec-driven-workflow.md` — SDD 验证链与有向图回退规则
 **REF** `_team-rules/task-lifecycle.md` — 来源标签规范（§1.3）

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-score/SKILL.md

@@ -5,6 +5,8 @@ description: Use when evaluating AI collaboration maturity of a project
 
 # Team Score — 协作评分
 
+**CRITICAL: DO NOT use EnterPlanMode.** This skill defines its own structured workflow. Follow STEPS below directly.
+
 ## ROLE
 
 ### 系统提示词
@@ -417,7 +419,7 @@ NO SCORE WITHOUT EVIDENCE FIRST
 
 ## CONSTITUTIONAL_RULES
 
-**REF** `_team-rules/constitutional-rules.md` — 9 条 Constitutional Rules
+**REF** `_team-rules/constitutional-rules.md` — 10 条 Constitutional Rules
 **REF** `_team-rules/first-principles.md` — 4 条第一性原理（First Principle #1 ~ #4）
 **REF** `_team-rules/ai-collaboration-standards.md` — AI 协作资产与 Prompt 工程规范
 **REF** `_team-rules/verification-protocol.md` — 5 步验证协议

package/skills/team-security/SKILL.md

@@ -5,6 +5,8 @@ description: Use when AI usage involves sensitive data, external services, or au
 
 # Team Security — AI 安全红线合规检查
 
+**CRITICAL: DO NOT use EnterPlanMode.** This skill defines its own structured workflow. Follow STEPS below directly.
+
 ## ROLE
 
 ### 系统提示词
@@ -535,7 +537,7 @@ NO AI OPERATIONS WITHOUT RED LINE CHECK FIRST
 
 ## CONSTITUTIONAL_RULES
 
-**REF** `_team-rules/constitutional-rules.md` — 9 条 Constitutional Rules
+**REF** `_team-rules/constitutional-rules.md` — 10 条 Constitutional Rules
 **REF** `_team-rules/first-principles.md` — 4 条第一性原理（First Principle #1 ~ #4）
 **REF** `_team-rules/verification-protocol.md` — 5 步验证协议
 

package/skills/team-spec/SKILL.md

@@ -5,6 +5,8 @@ description: Use when starting a new feature, need SDD spec, or requirements are
 
 # Team Spec — 规格制定
 
+**CRITICAL: DO NOT use EnterPlanMode.** This skill defines its own structured workflow. Follow STEPS below directly.
+
 ## ROLE
 
 ### 系统提示词
@@ -12,10 +14,11 @@ description: Use when starting a new feature, need SDD spec, or requirements are
 ```
 角色：规格制定专家
 核心原则：好的规格定义系统不能做什么，而非只描述做什么
-流程：扫描代码库 → 识别承重约束 → 展示方案等待确认 → 产出 SDD
+流程：扫描代码库 → 识别承重约束 → 展示方案等待确认 → 产出 SDD → 用户审阅反馈迭代 → 多角色轮审自动修复
 约束：
 - 关键决策点须展示方案并等待确认
 - 规格须基于代码库扫描结果，非凭记忆
+- 产出后须经用户审阅（Phase 2.5）和五角色轮审（Phase 3）方可定稿
 ```
 
 ### 推理检查点
@@ -31,11 +34,13 @@ description: Use when starting a new feature, need SDD spec, or requirements are
 5. **失败模式**：规格有误时代价最高的失败是什么？
 6. **最小方案**：约束条件下的最小充分方案？
 
-**对抗自检**（三视角，不可跳过）：
+**对抗自检**（五视角，不可跳过）：
 
 - [ ] 攻击者：规格中哪些模糊地带会被错误解读？
 - [ ] 实现者：拿到规格有足够信息开始编码吗？
 - [ ] 测试者：每条业务规则都能写出对应测试吗？
+- [ ] 用户：这个设计解决了用户的真实痛点吗？有无遗漏的操作路径？
+- [ ] 运维者：上线后能监控、回滚、定位问题吗？
 
 ## IRON_LAW
 
@@ -135,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 就能写出实现。每一条业务规则都能直接映射为测试用例——做不到就是规格不够具体。
@@ -252,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** 产出逐条检查：
 
 **通用项**（完整 + 精简模式均检查）：
 
@@ -287,16 +440,44 @@ 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 多角色轮审，或以全部"已确认合规"的正面观察橡皮图章通过
 - **列出**文件名却不列依赖关系
 - **声明**"无风险"，或产出后发现遗漏不补全
 - **凭空**推断而非扫描源码
 
 ## CONSTITUTIONAL_RULES
 
-**REF** `_team-rules/constitutional-rules.md` — 9 条 Constitutional Rules
+**REF** `_team-rules/constitutional-rules.md` — 10 条 Constitutional Rules
 **REF** `_team-rules/first-principles.md` — 4 条第一性原理（First Principle #1 ~ #4）
 **REF** `_team-rules/spec-driven-workflow.md` — Spec-Driven 开发原则与 TDD 工作流
 **REF** `_team-rules/task-lifecycle.md` — 来源标签规范（§1.3）
@@ -312,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`

package/skills/team-test/SKILL.md

@@ -5,6 +5,8 @@ description: Use when implementation exists and you need test matrix + coverage
 
 # Team Test — 测试审计
 
+**CRITICAL: DO NOT use EnterPlanMode.** This skill defines its own structured workflow. Follow STEPS below directly.
+
 ## ROLE
 
 ### 系统提示词
@@ -246,7 +248,7 @@ Phase 1 只分析，不写测试代码。
 
 ## CONSTITUTIONAL_RULES
 
-**REF** `_team-rules/constitutional-rules.md` — 9 条 Constitutional Rules
+**REF** `_team-rules/constitutional-rules.md` — 10 条 Constitutional Rules
 **REF** `_team-rules/first-principles.md` — 4 条第一性原理（First Principle #1 ~ #4）
 **REF** `_team-rules/spec-driven-workflow.md` — SDD 验证链与有向图回退规则
 **REF** `_team-rules/verification-protocol.md` — verify_cmd 解析流程与 5 步验证协议

package/skills/team-verify/SKILL.md

@@ -5,6 +5,8 @@ description: Use when about to claim work is complete, fixed, or passing - requi
 
 # Team Verify — 验证协议
 
+**CRITICAL: DO NOT use EnterPlanMode.** This skill defines its own structured workflow. Follow STEPS below directly.
+
 ## ROLE
 
 ### 系统提示词
@@ -164,7 +166,7 @@ NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE FIRST
 
 ## CONSTITUTIONAL_RULES
 
-**REF** `_team-rules/constitutional-rules.md` — 9 条 Constitutional Rules
+**REF** `_team-rules/constitutional-rules.md` — 10 条 Constitutional Rules
 **REF** `_team-rules/verification-protocol.md` — 5 步验证协议
 **REF** `_team-rules/first-principles.md` — 4 条第一性原理（First Principle #1 ~ #4）
 

package/skills/using-team-skills/SKILL.md

@@ -138,7 +138,7 @@ NO SKILL RECOMMENDATION WITHOUT SCENE ANALYSIS FIRST
 
 ## CONSTITUTIONAL_RULES
 
-**REF** `_team-rules/constitutional-rules.md` — 9 条 Constitutional Rules
+**REF** `_team-rules/constitutional-rules.md` — 10 条 Constitutional Rules
 **REF** `_team-rules/first-principles.md` — 4 条第一性原理（First Principle #1 ~ #4）
 
 分诊阶段尤其注意：