team-skills 1.3.8 → 1.4.0

package/CHANGELOG.md

@@ -7,6 +7,52 @@
 
 ## [Unreleased]
 
+## [1.4.0] - 2026-06-27
+
+### 新增
+
+- `team-range` 开发者命令：逐文件遍历项目文件执行用户指定操作，修改后重检直到干净再处理下一个
+
+### 变更
+
+- CLAUDE.md §2.2 引用规范更新：新增 `**REF**` 关键词统一外部规则引用格式，新增内联引用反引号格式规范
+- README 对齐 CLAUDE.md 命名规范：Agent 类名 → Skill 名称、H1-H4 → 正式介入点名称（CONFIRM_GOAL/CONFIRM_SPEC/ASK_HUMAN/HUMAN_ACCEPT）、Mermaid 核心架构图节点标签同步更新
+- `team-refine` 打磨顺序调整
+
+### 修复
+
+- 29 个文件全量一致性修复：22 处 Skill 名称反引号统一、4 处角色命名统一（"Agent" → "Skill"）、5 处模板章节编号修正
+- README 事实修正：SDD 章节数 7→9、设计原则数 20→21、refine 维度数修正、开发者命令表补齐 `/team-range`
+
+## [1.3.9] - 2026-06-27
+
+### 新增
+
+- team-impl: Phase 0 无 SDD 时 fallback 分支（design-brief 轻量替代 + boundary 缺失时最小修改约束）
+- team-impl: 并行记录 section 意图说明（贯穿 Phase 1，非独立阶段）
+- team-debug: Phase 3 假设验证 REPEAT MAX=5 迭代限制，超限后 GOTO Phase 5
+- team-feedback: Phase 4 入口新增 ASK_HUMAN 回复状态断言
+- team-review: Phase 1.5 Constitutional 检查统一文件缺失处理规则
+- task-lifecycle: 目录结构补充 .checkpoint.json
+
+### 变更
+
+- SDD 章节编号统一：七部分→九章节，spec-driven-workflow + team-spec inline skeleton + task-lifecycle 同步更新
+- team-brainstorm: Phase 6 跳过 spec 路由添加前置 ASSERT（需 design-brief 存在）
+- team-security: Phase 2 改为"标记违规 + 继续检查"模式，全部 6 条红线检查完毕后统一路由
+- team-score: OUTPUT_TEMPLATE 维度分数从 {n}/100 改为各维度实际满分（25/25/27/13/10）
+- team-orchestrator: compact 模式文档计数 12→11、COMPLETION_STATUS→COMPLETION_PROTOCOL、13 个兜底标签 *default*/*none* → *DEFAULT*/*NONE*
+- team-test: Phase 2 标题改为"设计并写入四维测试矩阵"
+- 6 个 Skill INTEGRATION "被谁调用" 补充"用户直接调用"
+
+### 修复
+
+- 5 个 Skill SELF_CHECK 双重复选框 `- [ ] - [ ]` 修正 + 裸文本自问补 checkbox
+- team-spec inline skeleton §六/§七 → §七/§八（对齐 sdd-template.md 实际编号）
+- team-feedback Phase 4 步骤序号重复修正（3→4→5→6）
+- spec-driven-workflow 追溯链示例 M1→D1（有效 SDD 条目编号）
+- lint 结构检查规则与 SKILL.md 实际章节名对齐
+
 ## [1.3.8] - 2026-06-27
 
 ### 新增

package/README.md

@@ -38,7 +38,7 @@
 
 ```
 传统方式：用户 → AI（一句话）→ 代码（随机产出）
-Team Skills：用户 → H1确认 → SDD规格 → H2确认 → TDD实现 → 测试 → Review → H4验收
+Team Skills：用户 → CONFIRM_GOAL → SDD 规格 → CONFIRM_SPEC → TDD 实现 → 测试 → Review → HUMAN_ACCEPT
 ```
 
 每个环节有明确的输入/输出标准，AI 不是"猜需求"，而是**执行规格**。
@@ -46,8 +46,8 @@ Team Skills：用户 → H1确认 → SDD规格 → H2确认 → TDD实现 →
 ### 🔄 有向图回退，不是线性流水线
 
 ```
-testAgent 发现 bug ──→ 自动回退 implAgent
-reviewAgent 发现 spec 遗漏 ──→ 自动回退 specAgent
+team-test 发现 bug ──→ 自动回退 team-impl
+team-review 发现 spec 遗漏 ──→ 自动回退 team-spec
 同一阶段回退 ≤ 2 次，超过触发人类介入
 ```
 
@@ -63,7 +63,7 @@ reviewAgent 发现 spec 遗漏 ──→ 自动回退 specAgent
 ### 📝 规则沉淀，不是"每次从零"
 
 - **三层规则体系**：项目级 → 模块级 → 任务级，冲突按优先级覆盖
-- **消费方契约**：每条规则含触发条件 + 可执行指令 + 示例，下游 Agent 可直接执行
+- **消费方契约**：每条规则含触发条件 + 可执行指令 + 示例，下游 Skill 可直接执行
 
 ### 📊 量化评估，不是"凭感觉"
 
@@ -156,7 +156,7 @@ npx team-skills@latest update
 /team-orchestrator 实现用户登录功能
 ```
 
-编排器自动完成：H1 确认目标 → specAgent 产出 SDD → H2 确认规格 → implAgent TDD 实现 → testAgent 四维测试 → reviewAgent 五维审查 → 分支完成处理 → H4 验收交付
+编排器自动完成：CONFIRM_GOAL 确认目标 → `team-spec` 产出 SDD → CONFIRM_SPEC 确认规格 → `team-impl` TDD 实现 → `team-test` 四维测试 → `team-review` 五维审查 → 分支完成处理 → HUMAN_ACCEPT 验收交付
 
 简单任务可用精简模式：
 
@@ -193,46 +193,46 @@ flowchart TD
     classDef kill fill:#ffebee,stroke:#c62828,stroke-width:2px,stroke-dasharray: 5 5,color:#b71c1c;
 
     START(("用户提出需求"))
-    H1["H1: 人类确认目标理解<br/>← 人类介入点 #1"]:::human
+    CG["CONFIRM_GOAL<br/>人类确认目标理解"]:::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
+    SPEC["team-spec — 规格制定<br/>产出 01-05 + prompt-template<br/>Socratic 提问 → SDD 规格"]:::agent
+    CS["CONFIRM_SPEC<br/>人类确认规格方案"]:::human
+    IMPL["team-impl — TDD 实现<br/>红-绿-重构循环<br/>增量提交 + 决策记录"]:::agent
+    TEST["team-test — 四维测试<br/>功能/边界/异常/代码分支"]:::agent
+    REVIEW["team-review — 五维审查<br/>资产沉淀 + 复盘"]:::agent
     FINISH["team-finish — 分支完成<br/>merge / PR / keep"]:::git
-    H4["H4: 人类验收交付物<br/>← 人类介入点 #4"]:::human
-    H3("H3: 人类介入 #3<br/>阻塞 / 决策 / Kill Switch"):::human
+    HA["HUMAN_ACCEPT<br/>人类验收交付物"]:::human
+    AH("ASK_HUMAN<br/>阻塞 / 决策 / Kill Switch"):::human
 
-    START --> H1
-    H1 -->|确认| BRANCH
-    H1 -->|不确认| START
+    START --> CG
+    CG -->|确认| BRANCH
+    CG -->|不确认| START
 
     BRANCH --> SPEC
-    SPEC --> H2
-    H2 -->|确认| IMPL
-    H2 -->|不确认| SPEC
-    H2 -.->|Kill Switch| H3
+    SPEC --> CS
+    CS -->|确认| IMPL
+    CS -->|不确认| SPEC
+    CS -.->|Kill Switch| AH
 
     IMPL --> TEST
 
     TEST -->|全部通过| REVIEW
     TEST -->|发现 bug| IMPL
     TEST -->|spec 遗漏| SPEC
-    TEST -.->|不可行| H3
+    TEST -.->|不可行| AH
 
     REVIEW -->|无问题| FINISH
     REVIEW -->|P0/P1| IMPL
     REVIEW -->|spec 遗漏| SPEC
-    REVIEW -.->|不可行| H3
+    REVIEW -.->|不可行| AH
 
-    FINISH --> H4
-    H4 -->|验收通过| DONE(("完成 ✅"))
-    H4 -->|不通过| IMPL
+    FINISH --> HA
+    HA -->|验收通过| DONE(("完成 ✅"))
+    HA -->|不通过| IMPL
 ```
 
-> H3 可在**任何阶段**触发，包括：发现任务不可行（Kill Switch）、回退超限、或需要人类决策的复杂问题。
-> 功能分支在 H1 确认后自动创建，在 Review 通过后由 team-finish 处理（merge/PR/keep/discard）。
+> ASK_HUMAN 可在**任何阶段**触发，包括：发现任务不可行（Kill Switch）、回退超限、或需要人类决策的复杂问题。
+> 功能分支在 CONFIRM_GOAL 确认后自动创建，在 Review 通过后由 `team-finish` 处理（merge/PR/keep/discard）。
 
 ---
 
@@ -310,7 +310,7 @@ docs/
 │   │   ├── 00-design-brief.md      #   设计概要（team-brainstorm 产出，可选）
 │   │   ├── 01-plan.md              #   任务规划（目标 + 分期 + 预算）
 │   │   ├── 02-context.md           #   上下文选择（术语 + 引用 + 排除）
-│   │   ├── 03-sdd.md              #   SDD 规格（七部分完整）
+│   │   ├── 03-sdd.md              #   SDD 规格（九章节完整）
 │   │   ├── 04-boundary.md          #   修改边界（allow + deny）
 │   │   ├── 05-risk.md              #   风险 + 验证计划
 │   │   ├── prompt-template.md      #   AI 任务提示词模板
@@ -369,7 +369,7 @@ Team Skills 融合了业界多个 AI 协作框架的精华：
 | **OpenSpec** (Fission AI) | Delta Spec 增量规格、RFC 2119 + Given/When/Then |
 | **Karpathy Skills** | 过度抽象防御、死代码清理、困惑管理 |
 | **Agent-Style** | 5 条 LLM 输出质量约束 |
-| **独创** | 有向图回退、质量追溯矩阵、消费方契约、H1-H4 人类介入点、100 分制量化评估、Skill Spec Language（20 条设计原则） |
+| **独创** | 有向图回退、质量追溯矩阵、消费方契约、CONFIRM_GOAL-HUMAN_ACCEPT 人类介入点、100 分制量化评估、Skill Spec Language（21 条设计原则） |
 
 ---
 
@@ -392,7 +392,7 @@ npm run setup      # 安装 Skills 到全局目录
 
 ### Skill 编写规范
 
-编写或修改 Skill 时，请参考 `skills/_team-rules/skill-spec.md`（Skill Spec v1.0：格式约定 + 关键词参考 + 20 条设计原则）。
+编写或修改 Skill 时，请参考 `CLAUDE.md` §2.7（Skill Spec：格式约定 + 关键词参考 + 设计原则）。
 
 ### 开发者斜杠命令（Claude Code）
 
@@ -400,7 +400,8 @@ npm run setup      # 安装 Skills 到全局目录
 
 | 命令 | 说明 | 参数 |
 |------|------|------|
-| `/team-refine` | 对抗审计（10 维度）+ 执行质量打磨（5 维度），按编排流程顺序逐 Skill 精炼到收敛 | 轮次数，默认 5 |
+| `/team-refine` | 改进飞轮：规范 ↔ SKILL.md 双向对抗审计（15 维度）+ LLM 执行质量打磨，逐轮收敛 | 轮次数，默认 5 |
+| `/team-range` | 逐文件遍历：对项目文件逐个执行指定操作，修改后重检直到干净 | `--scope skills\|rules\|commands\|all\|<glob>` + 操作描述 |
 | `/team-release` | 版本发布：更新 package.json + CHANGELOG，运行 install/format/lint/cli-test | `patch` / `minor` / `major` / `x.y.z` |
 
 ### CI 流程

package/package.json

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

package/scripts/check-skill-structure.js

@@ -12,14 +12,12 @@ import { execSync } from 'node:child_process';
 const root = execSync('git rev-parse --show-toplevel', { encoding: 'utf8' }).trim();
 
 const REQUIRED_SECTIONS = [
-  ['角色定位'],
-  ['系统提示词'],
-  ['推理检查点', '路由推理检查点', '推理指引', '路由推理'],
-  ['Iron Law'],
-  ['执行步骤'],
-  ['自检门禁'],
-  ['完成标志'],
-  ['STOP Signals'],
+  ['ROLE'],
+  ['IRON_LAW'],
+  ['STEPS'],
+  ['SELF_CHECK'],
+  ['COMPLETION'],
+  ['STOP_SIGNALS'],
 ];
 
 const SHARED_RULES = [

package/skills/_team-rules/ai-collaboration-standards.md

@@ -28,7 +28,7 @@
   - ❌ 错误：{坏的做法}
 ```
 
-不满足三要素的规则视为"空口号"，reviewAgent **MUST** 补全或删除。
+不满足三要素的规则视为"空口号"，`team-review` **MUST** 补全或删除。
 
 ### 1.3 资产维护机制
 
@@ -45,14 +45,14 @@
 
 | 内容类别    | 定义位置                                                                  |
 | ----------- | ------------------------------------------------------------------------- |
-| 业务术语    | specAgent `02-context.md` 模板（术语表）                                  |
-| 系统架构    | orchestrator 有向图流程图 + specAgent `03-sdd.md` §四 数据流              |
+| 业务术语    | `team-spec` `02-context.md` 模板（术语表）                                |
+| 系统架构    | `team-orchestrator` 有向图流程图 + `team-spec` `03-sdd.md` §四 数据流     |
 | 代码结构    | `_team-rules/task-lifecycle.md` §1（17 文件目录结构）                     |
-| 接口约定    | specAgent `02-context.md`（接口约束表）+ `03-sdd.md` §五/§六              |
-| 编码规范    | `_team-rules/spec-driven-workflow.md` §2 TDD + 本文件 §2.3 输出质量约束 + implAgent 各阶段禁止项 |
-| 测试要求    | `_team-rules/verification-protocol.md` + testAgent 四维测试矩阵           |
-| Review 标准 | reviewAgent 五维度审查 + 严重级别校准（P0-P3 实例）                       |
-| 交付要求    | orchestrator Step 8 完整性检查                                            |
+| 接口约定    | `team-spec` `02-context.md`（接口约束表）+ `03-sdd.md` §五/§六           |
+| 编码规范    | `_team-rules/spec-driven-workflow.md` §2 TDD + 本文件 §2.3 输出质量约束 + `team-impl` 各阶段禁止项 |
+| 测试要求    | `_team-rules/verification-protocol.md` + `team-test` 四维测试矩阵        |
+| Review 标准 | `team-review` 五维度审查 + 严重级别校准（P0-P3 实例）                     |
+| 交付要求    | `team-orchestrator` Step 8 完整性检查                                     |
 
 ## §2 Prompt 工程规范
 

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

@@ -4,17 +4,17 @@
 
 ## 规则列表
 
-> 每条规则追溯到 `_team-rules/first-principles.md`（FP-1 ~ FP-4）。
+> 每条规则追溯到 `_team-rules/first-principles.md`（First Principle #1 ~ First Principle #4）。
 
-1. **人类介入是一等公民** — H1-H4 暂停等待确认；精简模式 H1/H2 可简化为单句确认，H1/H4 不可省略（FP-1）
-2. **有向图回退** — 发现问题立即回退，禁止延迟。测试失败 = 事实，忽略只会放大修复代价（FP-4）
-3. **产出必须验证** — 不信任 Agent 自我声明，"我认为通过了" ≠ "确实通过了"（FP-4）
-4. **Kill Switch** — 不可行立即暂停，在不可行基础上堆叠工作只会使失败更难诊断（FP-1 + FP-3）
-5. **分期交付优先** — 修改文件 > 3 且跨模块影响 → 分期，每期独立序号和目录。单点失败只阻塞本期（FP-3）
-6. **自我约束预算** — 超出砍范围，不放宽预算（FP-3）
-7. **回退次数上限** — 同阶段 ≤ 2 次，超过触发 H3。两次未解决 = 信息不足，需人类介入（FP-1）
-8. **验证先行** — "通过"声明须基于当次新鲜执行的完整输出，上一轮结果是历史而非当前事实（FP-4）
-9. **TDD 顺序不可逆** — RED + commit 先于 GREEN + commit。后写测试 = 测试你构建的；先写测试 = 测试需求的（FP-2）
+1. **人类介入是一等公民** — CONFIRM_GOAL-HUMAN_ACCEPT 暂停等待确认；精简模式 CONFIRM_GOAL/CONFIRM_SPEC 可简化为单句确认，CONFIRM_GOAL/HUMAN_ACCEPT 不可省略（First Principle #1）
+2. **有向图回退** — 发现问题立即回退，禁止延迟。测试失败 = 事实，忽略只会放大修复代价（First Principle #4）
+3. **产出必须验证** — 不信任 Agent 自我声明，"我认为通过了" ≠ "确实通过了"（First Principle #4）
+4. **Kill Switch** — 不可行立即暂停，在不可行基础上堆叠工作只会使失败更难诊断（First Principle #1 + First Principle #3）
+5. **分期交付优先** — 修改文件 > 3 且跨模块影响 → 分期，每期独立序号和目录。单点失败只阻塞本期（First Principle #3）
+6. **自我约束预算** — 超出砍范围，不放宽预算（First Principle #3）
+7. **回退次数上限** — 同阶段 ≤ 2 次，超过触发 ASK_HUMAN。两次未解决 = 信息不足，需人类介入（First Principle #1）
+8. **验证先行** — "通过"声明须基于当次新鲜执行的完整输出，上一轮结果是历史而非当前事实（First Principle #4）
+9. **TDD 顺序不可逆** — RED + commit 先于 GREEN + commit。后写测试 = 测试你构建的；先写测试 = 测试需求的（First Principle #2）
 
 ## 常见规避借口（不成立）
 

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

@@ -6,14 +6,14 @@
 
 | # | 原理 | 推论 |
 | - | ---- | ---- |
-| FP-1 | **人类认知是稀缺资源** — AI 的价值在于放大人类判断力，而非替代它。因此关键决策必须由人类做出，AI 负责降低决策所需的认知负荷 | → H1-H4 介入点、Kill Switch、结构化选项展示 |
-| FP-2 | **实现偏见污染验证** — 编写代码的行为会改变你对"正确"的认知。先写代码再写测试，你测试的是你构建的东西，不是需求的东西 | → TDD 顺序不可逆、先测试后实现、硬重置规则 |
-| FP-3 | **复杂度是质量的敌人** — 每增加一个活动部件，出错的可能性指数增长。因此每一步都追求最小充分方案 | → 分期交付、自我约束预算、最小实现路径、YAGNI |
-| FP-4 | **声明不等于事实** — Agent（包括人类和 AI）会无意识地将"我认为通过了"当作"确实通过了"。唯一的解药是当次新鲜证据 | → 验证协议、不信任自我声明、产出必须验证 |
+| First Principle #1 | **人类认知是稀缺资源** — AI 的价值在于放大人类判断力，而非替代它。因此关键决策必须由人类做出，AI 负责降低决策所需的认知负荷 | → CONFIRM_GOAL-HUMAN_ACCEPT 介入点、Kill Switch、结构化选项展示 |
+| First Principle #2 | **实现偏见污染验证** — 编写代码的行为会改变你对"正确"的认知。先写代码再写测试，你测试的是你构建的东西，不是需求的东西 | → TDD 顺序不可逆、先测试后实现、硬重置规则 |
+| First Principle #3 | **复杂度是质量的敌人** — 每增加一个活动部件，出错的可能性指数增长。因此每一步都追求最小充分方案 | → 分期交付、自我约束预算、最小实现路径、YAGNI |
+| First Principle #4 | **声明不等于事实** — Agent（包括人类和 AI）会无意识地将"我认为通过了"当作"确实通过了"。唯一的解药是当次新鲜证据 | → 验证协议、不信任自我声明、产出必须验证 |
 
 ## 如何使用第一性原理
 
-- **规则冲突时**：回溯到第一性原理裁决。例如 "精简模式要不要跳过 H4？" → FP-1 说人类认知是稀缺资源但关键决策不可替代 → H4 不可跳过
-- **两条原理冲突时**：优先保护人类认知（FP-1）和事实验证（FP-4），因为它们的违反后果不可逆。FP-2（实现偏见）和 FP-3（复杂度）可在 FP-1/FP-4 约束内灵活权衡
-- **规则缺失时**：从第一性原理推导。例如 "调试时要不要写测试？" → FP-2 说实现偏见污染验证 → 先写回归测试再修复
+- **规则冲突时**：回溯到第一性原理裁决。例如 "精简模式要不要跳过 HUMAN_ACCEPT？" → First Principle #1 说人类认知是稀缺资源但关键决策不可替代 → HUMAN_ACCEPT 不可跳过
+- **两条原理冲突时**：优先保护人类认知（First Principle #1）和事实验证（First Principle #4），因为它们的违反后果不可逆。First Principle #2（实现偏见）和 First Principle #3（复杂度）可在 First Principle #1/First Principle #4 约束内灵活权衡
+- **规则缺失时**：从第一性原理推导。例如 "调试时要不要写测试？" → First Principle #2 说实现偏见污染验证 → 先写回归测试再修复
 - **规则过度时**：如果一条规则无法追溯到任何第一性原理，它可能是官僚主义而非工程纪律 → 应当简化或删除

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

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

package/skills/_team-rules/spec-driven-workflow.md

@@ -7,36 +7,38 @@
 ### 1.1 规格先于代码
 
 - 任何功能实现必须有对应的 SDD（Software Design Document）作为输入
-- SDD 是 implAgent 和 testAgent 的唯一规格来源——不依赖口头约定或聊天记录
+- SDD 是 `team-impl` 和 `team-test` 的唯一规格来源——不依赖口头约定或聊天记录
 - 修改类任务使用 Delta Spec（ADDED/MODIFIED/REMOVED），新建类任务使用完整 SDD
 
-### 1.2 SDD 七部分质量标准
+### 1.2 SDD 九章节质量标准
 
-每份 SDD **MUST** 包含以下七部分（缺一不可）：
+每份 SDD **MUST** 包含以下九章节（章节编号与 `references/sdd-template.md` 一致）：
 
-| 部分          | 内容                                                       | 消费方                       |
+| 章节          | 内容                                                       | 消费方                       |
 | ------------- | ---------------------------------------------------------- | ---------------------------- |
-| 背景与动机    | 为什么做、痛点、用户场景                                   | 所有 Agent                   |
-| 业务规则      | RFC 2119 强度标记（MUST/SHOULD/MAY）+ Given/When/Then 场景 | testAgent → 直接映射测试用例 |
-| 关键设计决策  | 选择方案 + 拒绝方案 + 拒绝理由                             | reviewAgent → 审查决策合理性 |
-| 数据流总览    | ASCII 架构图                                               | implAgent → 理解调用链路     |
-| 输入/输出规格 | 参数类型、约束、默认值、示例                               | implAgent + testAgent        |
-| 边界条件      | 空值、极值、并发、格式异常                                 | testAgent → 边界测试         |
-| 异常场景      | 错误码、错误消息、HTTP 状态                                | testAgent → 异常测试         |
+| §一 背景与动机    | 为什么做、痛点、用户场景                                   | 所有 Agent                   |
+| §二 业务规则      | RFC 2119 强度标记（MUST/SHOULD/MAY）+ Given/When/Then 场景 | `team-test` → 直接映射测试用例 |
+| §三 关键设计决策  | 选择方案 + 拒绝方案 + 拒绝理由                             | `team-review` → 审查决策合理性 |
+| §四 数据流总览    | ASCII 架构图                                               | `team-impl` → 理解调用链路     |
+| §五 输入规格 | 参数类型、约束、默认值、示例                               | `team-impl` + `team-test`        |
+| §六 输出规格 | 场景、HTTP 状态、输出结构、示例                            | `team-impl` + `team-test`        |
+| §七 边界条件      | 空值、极值、并发、格式异常                                 | `team-test` → 边界测试         |
+| §八 异常场景      | 错误码、错误消息、HTTP 状态                                | `team-test` → 异常测试         |
+| §九 验收 Checklist | 验收条件、验证方式、预期结果                               | `team-review` → 验收检查       |
 
 ### 1.3 规格驱动的验证链
 
 ```
 SDD §二 业务规则（GWT 场景）
     ↓ 直接映射
-testAgent 测试用例
+team-test 测试用例
     ↓ 验证
-implAgent 实现代码
+team-impl 实现代码
     ↓ 审查
-reviewAgent 对照 SDD 逐条检查
+team-review 对照 SDD 逐条检查
 ```
 
-每个验证环节 **MUST** 引用 SDD 条目编号（如 B1、E2、M1），形成闭环可追溯链。
+每个验证环节 **MUST** 引用 SDD 条目编号（如 B1、E2、D1），形成闭环可追溯链。
 
 ## §2 TDD 工作流
 
@@ -70,11 +72,11 @@ COMMIT: git commit（每个功能点一次，不攒多个功能点）
 
 | 发现者      | 问题类型         | 回退目标           |
 | ----------- | ---------------- | ------------------ |
-| testAgent   | 实现 bug         | → implAgent        |
-| testAgent   | SDD 未定义的场景 | → specAgent        |
-| reviewAgent | P0/P1 实现 bug   | → implAgent        |
-| reviewAgent | spec 遗漏        | → specAgent        |
-| 任何 Agent  | 任务不可行       | → Kill Switch → H3 |
+| `team-test`   | 实现 bug         | → `team-impl`        |
+| `team-test`   | SDD 未定义的场景 | → `team-spec`        |
+| `team-review` | P0/P1 实现 bug   | → `team-impl`        |
+| `team-review` | spec 遗漏        | → `team-spec`        |
+| 任何 Agent  | 任务不可行       | → Kill Switch → ASK_HUMAN |
 
 ### 3.2 回退携带上下文
 
@@ -87,4 +89,4 @@ COMMIT: git commit（每个功能点一次，不攒多个功能点）
 
 ### 3.3 回退次数上限
 
-同一阶段回退 ≤ 2 次。第 3 次强制触发 H3 人类介入。
+同一阶段回退 ≤ 2 次。第 3 次强制触发 ASK_HUMAN 人类介入。

package/skills/_team-rules/task-lifecycle.md

@@ -8,10 +8,11 @@
 
 ```
 docs/tasks/{NNNN}-{keyword}/
+├── .checkpoint.json          # 编排器断点续传状态（team-orchestrator 产出）
 ├── 00-design-brief.md      # 设计概要（team-brainstorm 产出，可选）
 ├── 01-plan.md              # 任务规划（目标 + 分期 + 预算）
 ├── 02-context.md           # 上下文选择（术语 + 引用 + 排除）
-├── 03-sdd.md               # SDD 规格（七部分完整）
+├── 03-sdd.md               # SDD 规格（九章节完整）
 ├── 04-boundary.md          # 修改边界（allow + deny）
 ├── 05-risk.md              # 风险 + 验证计划
 ├── prompt-template.md      # AI 任务提示词模板
@@ -54,23 +55,23 @@ docs/tasks/{NNNN}-{keyword}/
 
 | 介入点 | 时机             | 目的                               |
 | ------ | ---------------- | ---------------------------------- |
-| H1     | 编排器初始化后   | 确认目标理解 + 方案方向            |
-| H2     | specAgent 产出后 | 确认规格方案 + 分期策略            |
-| H3     | 发现阻塞/需决策  | 人类决策（Kill Switch / 方案选择） |
-| H4     | 全部完成后       | 验收交付物 + P2 决策               |
+| CONFIRM_GOAL     | 编排器初始化后   | 确认目标理解 + 方案方向            |
+| CONFIRM_SPEC     | `team-spec` 产出后 | 确认规格方案 + 分期策略            |
+| ASK_HUMAN     | 发现阻塞/需决策  | 人类决策（Kill Switch / 方案选择） |
+| HUMAN_ACCEPT     | 全部完成后       | 验收交付物 + P2 决策               |
 
 ### 2.2 禁止跳过
 
 - 任何 Agent **MUST NOT** 自动确认人类介入点
 - "用户没回复就默认同意"是违规行为
-- 即使任务看起来简单，H1 和 H4 不可省略（精简模式下 H1 和 H2 可简化为单句确认）
+- 即使任务看起来简单，CONFIRM_GOAL 和 HUMAN_ACCEPT 不可省略（精简模式下 CONFIRM_GOAL 和 CONFIRM_SPEC 可简化为单句确认）
 
-### 2.3 H3 结构化协议
+### 2.3 ASK_HUMAN 结构化协议
 
-H3 触发时，编排器 **MUST** 向用户展示以下结构化信息：
+ASK_HUMAN 触发时，编排器 **MUST** 向用户展示以下结构化信息：
 
 ```markdown
-## H3 人类介入请求
+## ASK_HUMAN 人类介入请求
 
 **触发来源**：{Agent 名称} | **触发原因**：{阻塞 / Kill Switch / 需决策}
 

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

@@ -19,7 +19,7 @@
 
 ```
 
-违反此协议的声明视为无效，reviewAgent MUST 标记为 P0。
+违反此协议的声明视为无效，`team-review` MUST 标记为 P0。
 
 ## 结构化证据格式
 
@@ -38,10 +38,10 @@
 
 1. 记录失败原因和错误输出
 2. 修复环境后重试（最多 2 次）
-3. 仍失败 → BLOCKED，触发 H3（状态不可为 DONE，只可 DONE_WITH_CONCERNS）
+3. 仍失败 → BLOCKED，触发 ASK_HUMAN（状态不可为 DONE，只可 DONE_WITH_CONCERNS）
 4. "工具失败" ≠ "验证通过"
 
-## Iron Law
+## IRON_LAW
 
 ```
 NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE