team-skills 1.3.8 → 1.3.9

package/CHANGELOG.md

@@ -7,6 +7,35 @@
 
 ## [Unreleased]
 
+## [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

@@ -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.8（Skill Spec：格式约定 + 关键词参考 + 设计原则）。
 
 ### 开发者斜杠命令（Claude Code）
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "team-skills",
-  "version": "1.3.8",
+  "version": "1.3.9",
   "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,13 +45,13 @@
 
 | 内容类别    | 定义位置                                                                  |
 | ----------- | ------------------------------------------------------------------------- |
-| 业务术语    | specAgent `02-context.md` 模板（术语表）                                  |
-| 系统架构    | orchestrator 有向图流程图 + specAgent `03-sdd.md` §四 数据流              |
+| 业务术语    | team-spec `02-context.md` 模板（术语表）                                  |
+| 系统架构    | 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 实例）                       |
+| 接口约定    | 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 实例）                       |
 | 交付要求    | 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

package/skills/team-brainstorm/SKILL.md

@@ -5,7 +5,7 @@ description: Use when requirements are fuzzy, need to discuss and form a plan be
 
 # Team Brainstorm — 讨论形成方案
 
-## 角色定位
+## ROLE
 
 ### 系统提示词
 
@@ -41,13 +41,13 @@ description: Use when requirements are fuzzy, need to discuss and form a plan be
 - [ ] 方案如果是错的，最可能错在哪？
 - [ ] 六个月后维护者会对什么不满？
 
-## Iron Law
+## IRON_LAW
 
 ```
 NO IMPLEMENTATION WITHOUT USER APPROVED DESIGN FIRST
 ```
 
-## 质量职责
+## QUALITY
 
 | 质量维度 | 产出文件 |
 | -------- | -------- |
@@ -55,16 +55,16 @@ NO IMPLEMENTATION WITHOUT USER APPROVED DESIGN FIRST
 | 方案对比 | 方案比较表（对话中） |
 | 用户确认 | 确认记录（对话中） |
 
-## 输入
+## INPUT
 
 - 用户传入的参数即为任务描述
 - 项目源码和文档（探索阶段读取）
 
-## 产出目录
+## OUTPUT_TEMPLATE
 
 `docs/tasks/{slug}/`（slug 由 Phase 1 **RESOLVE**）
 
-## 执行步骤
+## STEPS
 
 ### Phase 1：探索
 
@@ -80,7 +80,7 @@ NO IMPLEMENTATION WITHOUT USER APPROVED DESIGN FIRST
 5. **RESOLVE** `keyword`（首个命中即停）：
    1. 从用户需求提取核心关键词（kebab-case）
    2. 从项目上下文推断关键词
-   3. *none* → **NEEDS_CONTEXT**：请用户提供任务关键词
+   3. *NONE* → **NEEDS_CONTEXT**：请用户提供任务关键词
 6. **IF** `docs/tasks/ NOT_EXISTS` → 创建 `docs/tasks/`
 7. **READ** `docs/tasks/` 已有目录列表 → 取最大序号 +1（从 `0001` 起）→ 拼接 `slug` = `{序号}-{keyword}`（整体 ≤ 50 字符）
 8. **EXEC** 创建 `docs/tasks/{slug}/` 目录（**IF** 已存在 → 跳过）→ **ASSERT** `exit_code == 0`
@@ -92,7 +92,7 @@ NO IMPLEMENTATION WITHOUT USER APPROVED DESIGN FIRST
 > TRAP：你会倾向于接受用户的初始框架，不质疑其前提假设。
 > 用户说"我需要一个缓存层"——但也许问题根源是查询太慢，缓存只是用户想到的第一个方案。
 
-> 一次最多 3 个问题，优先用选项形式降低用户认知负担（FP-1）。
+> 一次最多 3 个问题，优先用选项形式降低用户认知负担（First Principle #1）。
 
 向用户展示最多 3 个关键问题，等待用户一次回复：
 
@@ -102,7 +102,7 @@ NO IMPLEMENTATION WITHOUT USER APPROVED DESIGN FIRST
 
 **IF** 用户回复揭示需求不可行：
 
-- **H3**：暂停设计，展示不可行原因，请用户决策（Kill Switch / 调整需求）
+- **ASK_HUMAN**：暂停设计，展示不可行原因，请用户决策（Kill Switch / 调整需求）
 
 **ELSE**：
 
@@ -137,7 +137,7 @@ NO IMPLEMENTATION WITHOUT USER APPROVED DESIGN FIRST
 
 ### Phase 4：展示设计
 
-> 逐段确认而非一次倾倒，每段确认后再展示下一段。目标是让用户在每个维度上做出知情决策，而非被信息量压垮后草率同意（FP-1）。
+> 逐段确认而非一次倾倒，每段确认后再展示下一段。目标是让用户在每个维度上做出知情决策，而非被信息量压垮后草率同意（First Principle #1）。
 
 逐段展示设计，每段后等待用户确认：
 
@@ -159,7 +159,7 @@ NO IMPLEMENTATION WITHOUT USER APPROVED DESIGN FIRST
 - 用户确认通过 → 继续 Phase 5
 - 用户要求修改 → **GOTO** Phase 3（仅重新展示修改后的方案，无需重新生成全部选项）
 - 用户决定放弃 → **BLOCKED**，记录原因
-- *default* → 向用户澄清确认意图
+- *DEFAULT* → 向用户澄清确认意图
 
 ### Phase 5：产出 00-design-brief.md
 
@@ -201,14 +201,14 @@ NO IMPLEMENTATION WITHOUT USER APPROVED DESIGN FIRST
 | 当期（最小闭环） | {核心功能} | {具体交付物} | {估算} |
 | 后续分期（增强，可选） | {扩展功能} | {具体交付物} | {估算} |
 
-> 如任务范围小（预计修改 ≤ 3 文件），可标注"无需分期，一次交付"。后续分期经 H4 批准后将以新序号启动独立任务。
+> 如任务范围小（预计修改 ≤ 3 文件），可标注"无需分期，一次交付"。后续分期经 HUMAN_ACCEPT 批准后将以新序号启动独立任务。
 
 ## 用户确认记录
 
 - 确认时间：{YYYY-MM-DD}
 - 确认内容：{用户同意的方案和范围}
 
-## 下一步建议
+## NEXT
 
 - 推荐使用：{team-spec / team-impl}
 - 理由：{...}
@@ -228,40 +228,41 @@ NO IMPLEMENTATION WITHOUT USER APPROVED DESIGN FIRST
 
 **MATCH** `user_intent`：
 
-- 用户接受默认路径 → **ROUTE** `team-spec {slug}`（在同一 slug 目录中产出完整 SDD）
-- 用户明确要求跳过规格阶段 → **ROUTE** `team-impl`（直接 TDD 实现）
+- 用户接受默认路径 → **ROUTE** `team-spec`（用 `Skill: team-spec` 加载并执行，传递 slug 参数）
+- 用户明确要求跳过规格阶段 → **ASSERT** `00-design-brief.md EXISTS`（跳过 spec 需要 design brief 作为 team-impl 的轻量输入）→ **ROUTE** `team-impl`（用 `Skill: team-impl` 加载并执行，传递 slug 参数。告知用户：跳过 spec 意味着无 SDD 边界约束，team-impl 将以 design brief 为规格输入）
 - 用户未表态 → 推荐 `team-spec {slug}`，等待用户确认
-- *default*（其他意图）→ 询问用户偏好
+- *DEFAULT*（其他意图）→ 询问用户偏好
 
-## STOP Signals
+## STOP_SIGNALS
 
 - **跳过**代码库探索，凭空设计方案
 - **抛出**所有问题而不等用户逐个回复
 - **提供**单一方案，没有备选方案对比
 - **跳过**用户确认就进入实现或产出 `01-plan.md`
 
-## Constitutional Rules 遵守
+## CONSTITUTIONAL_RULES
 
 引用 `_team-rules/constitutional-rules.md`。brainstorm 阶段尤其注意：
 
-- **Rule #1 人类介入是一等公民**：每个方案设计决策必须等待用户确认，不可自行决定（FP-1）
-- **Rule #5 分期交付优先**：方案设计时主动考虑分期交付（FP-3）
-- **Rule #4 Kill Switch**：如果探索阶段发现需求不可行，立即暂停而非继续设计（FP-1 + FP-3）
+- **Rule #1 人类介入是一等公民**：每个方案设计决策必须等待用户确认，不可擅自决定（First Principle #1）
+- **Rule #5 分期交付优先**：方案设计时主动考虑分期交付（First Principle #3）
+- **Rule #4 Kill Switch**：如果探索阶段发现需求不可行，立即暂停而非继续设计（First Principle #1 + First Principle #3）
 
-## 自检门禁
+## SELF_CHECK
 
 **GATE** 产出前自检（全部通过才放行）：
 
 - [ ] 已 **READ** 代码库和现有实现（不是凭空设计）
 - [ ] **ASSERT** `方案数 >= 2`（不是只有一个选项）
-- [ ] **ASSERT** `用户已确认设计方案`（不是自行决定）
+- [ ] **ASSERT** `用户已确认设计方案`（不是擅自决定）
 - [ ] **ASSERT** `00-design-brief.md EXISTS`（已 **WRITE** 到 `docs/tasks/{slug}/`）
 - [ ] **ASSERT** `00-design-brief.md 无占位符残留`
 - [ ] **ASSERT** `01-plan.md NOT_EXISTS`（那是 team-spec 的职责）
+- [ ] **ASSERT** `IRON_LAW 遵守` — 设计方案已获用户确认，未擅自决定
 - [ ] 我是否真的探索了不同方向，还是只是同一个想法的变体？
 - [ ] 如果用户的前提假设是错的，我的方案还成立吗？
 
-## 完成标志
+## COMPLETION
 
 **MATCH** `result`：
 
@@ -270,9 +271,9 @@ NO IMPLEMENTATION WITHOUT USER APPROVED DESIGN FIRST
 - 需求信息不足，无法形成方案 → **NEEDS_CONTEXT**
 - 需求不可行 → **BLOCKED**
 - 用户决定放弃 → **DONE**（`状态: 用户主动终止`）
-- *default* → **NEEDS_CONTEXT**
+- *DEFAULT* → **NEEDS_CONTEXT**
 
-## 集成关系
+## INTEGRATION
 
 **被谁调用：**
 
@@ -283,7 +284,7 @@ NO IMPLEMENTATION WITHOUT USER APPROVED DESIGN FIRST
 - `team-spec` — REQUIRED：讨论完成后必须进行规格定义
 - `team-impl` — 仅当用户明确要求跳过规格阶段时可直接实现
 
-## 下一步
+## NEXT
 
 - 方案确定后 → 使用 `team-spec` 编写完整 SDD
 - 需要技术验证 → 使用 `team-debug` 进行原型验证