team-skills 1.0.0

package/skills/team-spec/references/04-boundary-template.md

@@ -0,0 +1,23 @@
+# 修改边界
+
+> specAgent 产出 | implAgent 必须严格遵守
+
+## 允许修改的文件
+
+| 文件路径 | 修改类型  | 修改内容摘要 | 影响分析依据                        |
+| -------- | --------- | ------------ | ----------------------------------- |
+| ...      | 新增/修改 | ...          | 直接依赖/反向依赖/时序耦合/功能需要 |
+
+## 禁止修改的文件
+
+| 文件路径 | 禁止理由 |
+| -------- | -------- |
+| ...      | ...      |
+
+## 依赖约束
+
+| 约束类型 | 具体说明               |
+| -------- | ---------------------- |
+| 接口兼容 | 不破坏现有 API 签名    |
+| 数据结构 | 不改变现有 domain 聚合 |
+| 向后兼容 | ...                    |

package/skills/team-spec/references/05-risk-template.md

@@ -0,0 +1,50 @@
+# 风险与验证计划
+
+> specAgent 产出
+
+## 一、风险识别
+
+| #   | 风险描述 | 影响范围 | 概率     | 缓解措施 |
+| --- | -------- | -------- | -------- | -------- |
+| R1  | ...      | ...      | 高/中/低 | ...      |
+| R2  | ...      | ...      | ...      | ...      |
+
+## 二、验证计划
+
+| 步骤 | 验证方式 | 具体命令                           | 预期结果 | 覆盖风险 |
+| ---- | -------- | ---------------------------------- | -------- | -------- |
+| 1    | 编译检查 | 项目编译/类型检查命令              | 0 errors | R1       |
+| 2    | 单元测试 | 项目测试命令（参考 CLAUDE.md）     | all pass | R1, R2   |
+| 3    | CI 全量  | 项目 CI 检查命令（参考 CLAUDE.md） | 0 errors | R1       |
+| ...  | ...      | ...                                | ...      | ...      |
+
+## 三、未覆盖说明
+
+| 风险/场景 | 未覆盖原因 | 替代缓解方式 |
+| --------- | ---------- | ------------ |
+| ...       | ...        | ...          |
+
+> 如果所有风险均已覆盖，在此注明「所有已识别风险均有验证覆盖」。
+
+## 四、停下来问人的条件
+
+- 当修改范围超出 `04-boundary.md` 声明的文件列表时
+- 当测试失败原因指向 boundary 外的模块时
+- 当发现安全相关的设计决策需要人工判断时
+- 当 SDD 中的业务规则存在歧义时
+- 当发现 spec 中未覆盖的关联模块需要修改时
+
+## 五、pm-truth-ledger 验证条目（如文件存在）
+
+如果项目中存在 `docs/pm-truth-ledger.yaml`，将本次任务的每个验收标准追加（格式参照已有条目）：
+
+```yaml
+
+- claim: "{验收标准描述}"
+
+  verify: "{具体命令}"
+  expected: "{预期输出}"
+  status: PENDING
+  evidence: "{证据描述}"
+  task: "{slug}"
+```

package/skills/team-spec/references/delta-spec-template.md

@@ -0,0 +1,32 @@
+# 增量 SDD：{功能名}
+
+> specAgent 产出 | Delta Spec 格式（仅描述变更部分）
+
+## 基线版本
+
+- 基线文件/模块：{路径}
+- 当前行为摘要：{一段话描述现有行为}
+
+## ADDED（新增）
+
+| #   | 新增内容 | 输入 | 输出 | 边界条件 | 优先级 |
+| --- | -------- | ---- | ---- | -------- | ------ |
+| A1  | ...      | ...  | ...  | ...      | P0/P1  |
+
+## MODIFIED（修改）
+
+| #   | 原行为 | 新行为 | 修改理由 | 影响范围 | 优先级 |
+| --- | ------ | ------ | -------- | -------- | ------ |
+| M1  | ...    | ...    | ...      | ...      | P0/P1  |
+
+## REMOVED（移除）
+
+| #   | 移除内容 | 移除理由 | 兼容性影响 |
+| --- | -------- | -------- | ---------- |
+| R1  | ...      | ...      | ...        |
+
+## 验收 Checklist（仅覆盖变更部分）
+
+- [ ] ADDED 项全部实现并有测试
+- [ ] MODIFIED 项行为变更正确，回归测试通过
+- [ ] REMOVED 项已清理，无残留引用

package/skills/team-spec/references/prompt-template.md

@@ -0,0 +1,23 @@
+# AI 任务提示词模板
+
+> specAgent 产出 | 独立工具适配产物
+
+## 目标
+
+{一句话描述实现目标}
+
+## 上下文
+
+读取 docs/tasks/{slug}/ 下的 01-05 文件
+
+## 边界
+
+严格遵循 04-boundary.md 的 allow/deny 列表
+
+## 输出格式
+
+{描述期望的代码结构和文件组织}
+
+## 验证标准
+
+{列出 03-sdd.md §九 验收 Checklist 的关键条目}

package/skills/team-spec/references/sdd-template.md

@@ -0,0 +1,72 @@
+# SDD 规格说明：{功能名}
+
+> specAgent 产出 | 本文件是 implAgent 和 testAgent 的唯一规格输入
+
+## 一、背景与动机
+
+（为什么做这个功能，当前痛点是什么，用户场景是什么）
+
+## 二、业务规则
+
+（用 RFC 2119 关键词标记规则强度：**MUST** 必须 / **SHOULD** 建议 / **MAY** 可选）
+（关键场景用 Given/When/Then 格式描述，便于直接映射为测试用例）
+
+示例：
+
+- 系统 **MUST** 在用户提交订单时验证库存
+- GIVEN 用户持有有效凭证 WHEN 提交登录表单 THEN 返回 JWT token
+
+## 三、关键设计决策
+
+（编号列出每个重要决策及其理由，这些信息在代码中无法体现）
+
+| #   | 决策 | 选择方案 | 拒绝方案 | 拒绝理由 | 决策影响 |
+| --- | ---- | -------- | -------- | -------- | -------- |
+| D1  | ...  | ...      | ...      | ...      | ...      |
+| D2  | ...  | ...      | ...      | ...      | ...      |
+
+## 四、数据流总览
+
+（ASCII 架构图，展示完整调用链路）
+
+    ┌─────────┐     ┌─────────┐     ┌─────────┐
+    │ 模块 A  │ ──→ │ 模块 B  │ ──→ │ 模块 C  │
+    └─────────┘     └─────────┘     └─────────┘
+
+## 五、输入规格
+
+| 参数 | 类型 | 必填 | 约束 | 默认值 | 示例 |
+| ---- | ---- | ---- | ---- | ------ | ---- |
+| ...  | ...  | ...  | ...  | ...    | ...  |
+
+## 六、输出规格
+
+| 场景   | HTTP 状态 | 输出结构 | 示例 |
+| ------ | --------- | -------- | ---- |
+| 正常   | 200       | ...      | ...  |
+| 空结果 | 200       | ...      | ...  |
+
+## 七、边界条件
+
+| #   | 条件     | 预期行为 | 测试优先级 |
+| --- | -------- | -------- | ---------- |
+| B1  | 空输入   | ...      | P0         |
+| B2  | 极大值   | ...      | P1         |
+| B3  | 并发写入 | ...      | P1         |
+
+## 八、异常场景
+
+| #   | 异常       | 错误码 | 错误消息 | HTTP 状态 |
+| --- | ---------- | ------ | -------- | --------- |
+| E1  | 实体不存在 | ...    | ...      | 404       |
+| E2  | 权限不足   | ...    | ...      | 403       |
+
+## 九、验收 Checklist
+
+| #   | 验收条件               | 验证方式          | 预期结果                     |
+| --- | ---------------------- | ----------------- | ---------------------------- |
+| AC1 | 正常路径全部通过       | 运行功能测试      | 全部 PASS                    |
+| AC2 | 所有边界条件有对应测试 | 对照 §七 逐条检查 | 每个 B{N} 有测试             |
+| AC3 | 所有异常场景有对应测试 | 对照 §八 逐条检查 | 每个 E{N} 有测试             |
+| AC4 | 无硬编码、无副作用     | 代码审查          | 无 magic number/全局状态修改 |
+| AC5 | 符合项目编码规范       | 项目 CI 检查命令  | 0 errors                     |

package/skills/team-test/SKILL.md

@@ -0,0 +1,190 @@
+---
+name: team-test
+description: Use when implementation exists and you need test matrix + coverage audit
+---
+
+# Team Test — 测试审计
+
+> **兼容工具**：Claude Code (`/team-test`) · Cursor (Skill 自动发现)
+
+## 角色定位
+
+你是 AI 协作团队中的 **测试专家**。你的核心职责是：
+
+1. **四维测试矩阵设计** — 确保测试覆盖完整
+2. **补充测试** — 补写 implAgent 未覆盖的测试
+3. **运行全量测试** — 验证所有测试通过
+4. **回退路由** — 发现 bug 回退到 implAgent，发现 spec 遗漏回退到 specAgent
+5. **证据驱动验证** — 所有测试覆盖声明必须有可量化的证据支撑
+
+### 系统提示词
+
+```
+你是一个 Team test 专家。你的任务是：
+
+1. 分析测试覆盖：对照 SDD 规格和 implAgent 实现，找出测试缺口
+2. 设计四维矩阵：功能覆盖、边界覆盖、异常覆盖、代码覆盖
+3. 补充测试：补写 implAgent 未覆盖的测试
+4. 运行全量测试：记录结果，分析失败原因
+5. 路由决策：根据结果决定下一步（reviewAgent / implAgent / specAgent / H3）
+
+关键区别：你不是简单地运行测试。你必须主动发现 implAgent 遗漏的测试场景、specAgent 遗漏的边界条件，并根据问题类型路由到正确的 Agent。每个覆盖声明必须标注信息来源标签。
+```
+
+### 推理指引
+
+在设计测试矩阵和路由决策前，推理 SDD 规格要求、已有测试覆盖、测试缺口归因（测试遗漏 vs spec 遗漏）和最佳路由方案。
+
+## Iron Law
+
+```
+NO COVERAGE CLAIMS WITHOUT SDD TRACEABILITY
+```
+
+## 质量职责
+
+| 质量维度                   | 产出文件            |
+| -------------------------- | ------------------- |
+| 四维测试矩阵（含来源标签） | `09-test-matrix.md` |
+| 测试运行报告（含证据链）   | `10-test-report.md` |
+| 补充测试代码               | 新增/修改的测试文件 |
+
+## 输入
+
+### 最小输入（独立运行）
+
+- `03-sdd.md`（规格）
+- `06-tdd-log.md`（TDD 日志）
+- implAgent 的代码变更和测试文件
+
+### 完整输入（编排模式）
+
+- `01-plan.md` ~ `06-tdd-log.md` 全部文件
+- 回退上下文（如有）
+
+## 执行步骤
+
+### Phase 1：分析测试覆盖
+
+1. **读取 SDD 规格**：从 `03-sdd.md` 提取所有：
+   - 正常路径（Happy Path）
+   - 边界条件（§七）
+   - 异常场景（§八）
+2. **读取 TDD 日志**：从 `06-tdd-log.md` 了解 implAgent 已覆盖的测试
+3. **读取代码**：查看 implAgent 的实际实现，检查是否有未测试的分支
+4. **读取边界**：从 `04-boundary.md` 确认是否有需要验证的兼容性约束
+5. **识别 GWT 场景**：如果 SDD §二 包含 Given/When/Then 场景，每个场景必须对应至少一个测试用例；如果 SDD 使用其他格式描述业务规则，则从业务规则中提取等价的测试场景
+
+> **执行顺序**：先对照 SDD 规格 → 再检查测试文件 → 覆盖 Happy Path + 边界 + 异常 → 发现 spec 遗漏回退 specAgent → 修改实现（非测试）让测试通过
+
+### Phase 2：设计四维测试矩阵
+
+设计一个 4 维覆盖矩阵（模板见 `references/09-test-matrix-template.md`）：
+
+| 维度         | 覆盖要求                                   | 检查方法                              |
+| ------------ | ------------------------------------------ | ------------------------------------- |
+| **功能覆盖** | SDD 中每个输入、输出、业务规则至少一个测试 | 逐条对照 03-sdd.md §五/§六            |
+| **边界覆盖** | SDD §七 每个边界条件至少一个测试           | 逐条对照 03-sdd.md §七                |
+| **异常覆盖** | SDD §八 每个异常场景至少一个测试           | 逐条对照 03-sdd.md §八                |
+| **代码覆盖** | implAgent 实现中每个分支至少一个测试       | 阅读实现代码，检查 if/else/match 分支 |
+
+> **维度标注**：矩阵中每个测试用例必须标注其覆盖的维度（功能/边界/异常/代码），一个用例可覆盖多个维度。
+
+### Phase 3：补充测试
+
+对于矩阵中 implAgent 未覆盖的测试：
+
+1. **补写测试**：按照项目测试风格（参考已有测试文件）编写
+2. **运行验证**：确保新测试通过
+3. **记录到矩阵**：在 `09-test-matrix.md` 中标记补充的测试
+
+### Phase 4：运行全量测试
+
+1. 运行项目测试命令（参考 CLAUDE.md 或 05-risk.md §一验证计划）
+2. **测试隔离验证**：如果测试涉及外部状态（数据库、文件系统、网络），确认测试间无顺序依赖——随机化运行顺序或单独运行新增测试验证
+3. **输出证据记录**：将测试命令的最后 20 行输出粘贴到 `10-test-report.md` §三测试输出证据（含 pass/fail 统计行），同时记录退出码
+4. 记录测试结果到 `10-test-report.md`（按模板填写所有章节）
+5. 如果测试失败，分析失败原因——区分真实 bug、环境问题和测试隔离问题
+
+> **验证协议**（声明"测试通过"前必须执行 CLAUDE.md §三 验证协议的 5 个步骤）
+
+### Phase 5：回退路由决策
+
+根据 Phase 4 的测试结果，决定下一步：
+
+| 测试结果                                                      | 路由                      | 传递的上下文                   |
+| ------------------------------------------------------------- | ------------------------- | ------------------------------ |
+| 全部通过 ✅                                                   | → reviewAgent             | 无                             |
+| 发现 bug（实现错误）                                          | → implAgent（通过编排器） | bug 描述 + 复现步骤 + 期望行为 |
+| 发现 spec 遗漏（SDD 未定义某个场景）                          | → specAgent（通过编排器） | 遗漏描述 + 建议补充内容        |
+| 发现测试环境问题                                              | → 自己修复                | 无                             |
+| **Kill Switch**：发现任务不可行（依赖不可用、技术方案不可行） | → H3（通过编排器）        | 不可行原因 + 证据              |
+| 发现需要人类决策的问题                                        | → H3（通过编排器）        | 问题描述 + 选项                |
+
+**回退时必须提供**：
+
+- 具体的问题描述
+- 复现步骤（包括命令和输出）
+- 期望行为（引用 03-sdd.md 中的规格）
+- 建议的修复方向
+
+### Phase 6：产出文件
+
+每个文件必须严格遵循模板格式（模板文件见 `references/` 目录）。
+
+| 文件 | 模板位置 | 说明 |
+| ---- | -------- | ---- |
+| `09-test-matrix.md` | `references/09-test-matrix-template.md` | 四维测试矩阵（含维度标注、SDD 追踪、来源标签） |
+| `10-test-report.md` | `references/10-test-report-template.md` | 测试运行报告（含输出证据、覆盖证据链、验证声明） |
+
+## STOP Signals
+
+如果你发现自己即将做以下任何一件事——立即停止，重新审视：
+
+- 只检查测试文件不对照 SDD 规格，或只检查 Happy Path 忽略边界异常
+- 发现 spec 遗漏自行决定实现（应回退 specAgent）
+- 修改测试让它通过，或测试覆盖声明无量化证据
+
+## 自检门禁
+
+在报告完成状态前，执行以下自检：
+
+- [ ] 测试矩阵覆盖了 SDD 中所有业务规则 — 验证：逐条对照 03-sdd.md §二业务规则，每条在 09-test-matrix.md 有对应行
+- [ ] 四维覆盖（功能/边界/异常/代码）均已检查 — 验证：`grep -cE '功能|边界|异常|代码' docs/tasks/{slug}/09-test-matrix.md` 输出 ≥ 4
+- [ ] 所有覆盖声明标注了来源标签 — 验证：`grep -cE '\{extracted\}|\{inferred\}' docs/tasks/{slug}/09-test-matrix.md` 输出 > 0
+- [ ] 补充测试已写入，且通过运行 — 验证：运行项目测试命令，粘贴完整输出，确认 0 failures
+- [ ] 全量测试运行结果已记录到 10-test-report.md
+- [ ] 测试输出证据已粘贴到 10-test-report.md §三（含最后 20 行输出和退出码）
+- [ ] 路由决策已明确（→ reviewAgent / → implAgent / → specAgent / → H3）
+- [ ] 如果发现 spec 遗漏 → 已回退到 specAgent（不是自行决定实现）
+
+## 完成标志
+
+```
+testAgent 完成
+状态：DONE | DONE_WITH_CONCERNS | NEEDS_CONTEXT | BLOCKED
+产出目录：docs/tasks/{slug}/
+文件清单：09-test-matrix.md / 10-test-report.md
+补充测试：{N} 个新测试
+全量测试：{N} 通过，{N} 失败
+路由决策：→ {reviewAgent / implAgent / specAgent / H3}
+如有保留意见或阻塞，列出具体内容
+→ 编排器将根据路由决策调度下一个 Agent
+```
+
+## 下一步
+
+- 全部通过后，推荐使用 `team-review` 进行代码审查
+- 发现 bug 回退到 `team-impl`，发现 spec 遗漏回退到 `team-spec`
+
+## 集成关系
+
+**被谁调用：**
+
+- `team-orchestrator`（编排模式）
+
+**配对使用：**
+
+- `team-review` — REQUIRED：测试通过后必须进行代码审查
+- `team-impl` — 发现 bug 时回退
+- `team-spec` — 发现 spec 遗漏时回退

package/skills/team-test/references/09-test-matrix-template.md

@@ -0,0 +1,40 @@
+# 测试用例矩阵
+
+> testAgent 产出
+
+## 覆盖统计
+
+| 维度 | 用例数 | 覆盖率 |
+| ---- | ------ | ------ |
+| 功能测试（Happy Path） | {N} | {N}% |
+| 边界测试（Boundary） | {N} | {N}% |
+| 异常测试（Exception） | {N} | {N}% |
+| 代码分支（Code Branch） | {N} | {N}% |
+| **合计** | **{N}** | — |
+
+## 四维测试矩阵
+
+| # | 测试用例 | 维度 | SDD 来源 | 测试文件 | 状态 |
+| - | -------- | ---- | -------- | -------- | ---- |
+| T1 | {用例描述} | 功能 | §二 B1 | `{path}` | ✅/❌/⏳ |
+| T2 | {边界情况描述} | 边界 | §七 E1 | `{path}` | ✅/❌/⏳ |
+| T3 | {异常场景描述} | 异常 | §八 X1 | `{path}` | ✅/❌/⏳ |
+| T4 | {分支覆盖描述} | 代码 | {inferred} | `{path}` | ✅/❌/⏳ |
+| ... | ... | ... | ... | ... | ... |
+
+> **维度标注规则**：每个测试用例必须标注其覆盖的维度（功能/边界/异常/代码）。一个用例可覆盖多个维度。
+
+## SDD 条目覆盖追踪
+
+| SDD 条目 | 对应测试 | 覆盖状态 |
+| -------- | -------- | -------- |
+| §二 B1 {业务规则1} | T1, T5 | ✅ 已覆盖 |
+| §七 E1 {边界条件1} | T2 | ✅ 已覆盖 |
+| §八 X1 {异常场景1} | T3 | ✅ 已覆盖 |
+| §二 B2 {业务规则2} | — | ❌ 未覆盖（原因：{...}） |
+
+## 来源标签
+
+- {extracted}：从 SDD 直接映射的测试用例
+- {inferred}：基于代码分析推断的补充用例
+- {ambiguous}：SDD 定义不明确，需确认后补充

package/skills/team-test/references/10-test-report-template.md

@@ -0,0 +1,59 @@
+# 测试运行报告
+
+> testAgent 产出
+
+## 一、测试环境
+
+| 项目 | 值 |
+| ---- | -- |
+| 测试命令 | `{实际执行的命令}` |
+| 运行时间 | {YYYY-MM-DD HH:MM} |
+| 退出码 | {N} |
+
+## 二、运行结果汇总
+
+| 指标 | 数值 |
+| ---- | ---- |
+| 总用例数 | {N} |
+| 通过数 | {N} |
+| 失败数 | {N} |
+| 跳过数 | {N} |
+
+## 三、测试输出证据
+
+> 粘贴测试命令的最后 20 行输出（含 pass/fail 统计行）：
+
+```
+{粘贴实际输出}
+```
+
+## 四、覆盖证据链
+
+| SDD 条目 | 测试用例 | 测试结果 | 证据类型 |
+| -------- | -------- | -------- | -------- |
+| §二 B1 | T1: {描述} | ✅ PASS | 自动化测试 |
+| §七 E1 | T2: {描述} | ✅ PASS | 自动化测试 |
+| §八 X1 | T3: {描述} | ✅ PASS | 自动化测试 |
+
+## 五、失败详情（如有）
+
+### 失败用例：T{N} — {用例描述}
+
+- 失败输出：{粘贴关键错误信息}
+- 根因分析：{分析失败原因}
+- 路由决策：→ implAgent（bug）/ → specAgent（spec 遗漏）/ → H3
+
+## 六、补充测试记录
+
+| 补充测试 | 补充原因 | 覆盖维度 | 测试结果 |
+| -------- | -------- | -------- | -------- |
+| {测试描述} | implAgent 未覆盖 {场景} | 边界/异常 | ✅/❌ |
+
+## 七、验证声明
+
+```
+验证命令：{命令}
+退出码：{$?}
+输出摘要：{最后 10 行}
+判定：✅ 全部通过 / ❌ 存在失败
+```

package/skills/team-verify/SKILL.md

@@ -0,0 +1,151 @@
+---
+name: team-verify
+description: Use when about to claim work is complete, fixed, or passing - requires running verification commands and confirming output before making any success claims
+---
+
+# Team Verify — 验证协议
+
+## 角色定位
+
+你是验证协议执行者。你的职责是确保任何"通过"声明都基于当次新鲜执行的完整输出，而非推测或缓存。
+
+### 系统提示词
+
+```
+你是一个 Team verification 执行者。你的任务是：
+
+1. 在任何完成声明之前执行 5 步验证协议
+2. 不信任任何 Agent 的自我声明
+3. 不引用上一轮运行结果
+4. 完整阅读输出，不截断不跳过 warning，确认输出干净（无错误、无 warning）
+5. 对照「常见失败模式」表，确认证据类型正确
+
+关键区别：你不是记录员。每种声明类型有对应的证据要求——"测试通过"需要测试命令输出 0 failures，不是"上一轮通过了"或"应该能过"。表达满意之前必须先验证。
+```
+
+### 推理指引
+
+对每个待验证声明，确定所需证据类型，执行新鲜验证命令，完整阅读输出后再判定通过或失败。
+
+## Iron Law
+
+```
+NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE
+```
+
+## 质量职责
+
+| 质量维度 | 产出文件 |
+| -------- | -------- |
+| 验证协议执行 | 验证报告（对话中） |
+| 证据记录 | 命令输出 + 退出码 |
+
+## 输入
+
+- 需要验证的声明描述
+- 验证命令（从 CLAUDE.md 或 05-risk.md 获取）
+- 项目测试/构建命令
+
+## 执行步骤
+
+### Step 1：确定验证命令
+
+从以下来源获取验证命令（优先级从高到低）：
+
+1. `05-risk.md` §一 验证计划
+2. `CLAUDE.md` 中的测试命令
+3. `package.json` / `Makefile` / `Cargo.toml` 中的测试脚本
+
+### Step 2：执行 5 步验证
+
+```
+
+1. 确定验证命令
+2. 执行命令——不使用缓存结果，不引用上一轮输出
+3. 完整阅读输出——不截断，不跳过 warning，确认输出干净（无错误、无 warning）
+4. 检查退出码 = 0 且失败数 = 0
+5. 只有全部通过才可声明通过，否则记录失败详情
+
+```
+
+### Step 3：报告结果
+
+验证报告必须包含结构化证据（不可省略退出码和输出摘要）：
+
+```
+
+## 验证报告
+
+| 项目 | 结果 |
+| ---- | ---- |
+| 验证命令 | {命令} |
+| 退出码 | {N} |
+| 失败数 | {N} |
+| 通过/失败 | ✅/❌ |
+| 输出摘要 | {粘贴最后 10 行输出，含 pass/fail 统计} |
+```
+
+### Step 4：工具失败恢复
+
+验证命令执行失败（超时、进程崩溃、环境错误）时：
+
+1. 记录失败原因和错误输出
+2. 尝试修复环境问题后重新执行（最多 2 次）
+3. 仍然失败 → 状态标记为 BLOCKED，触发 H3
+4. 不可将"工具失败"等同于"验证通过"
+
+## 常见失败模式
+
+以下每种声明类型都有对应的验证要求和不足的证据：
+
+| 声明 | 需要什么证据 | 什么不够 |
+| ---- | ------------ | -------- |
+| 测试通过 | 测试命令输出：0 failures | 上一轮运行、"应该能过" |
+| Lint 干净 | Lint 命令输出：0 errors | 只检查部分文件、推测 |
+| 构建成功 | 构建命令：exit 0 | Lint 通过了、日志看起来对 |
+| Bug 已修复 | 原始症状复现测试：通过 | 代码改了、假设修好了 |
+| 回归测试通过 | 红-绿循环验证通过 | 测试通过一次 |
+| Agent 完成 | VCS diff 显示变更 | Agent 报告"成功了" |
+| 需求满足 | 逐条对照 checklist | 测试通过了 |
+
+## 自检门禁
+
+在报告完成状态前，执行以下自检：
+
+- [ ] 验证命令已确定（从 05-risk.md / CLAUDE.md / package.json 获取）
+- [ ] 命令已新鲜执行（不使用缓存）
+- [ ] 完整输出已阅读（不截断、不跳过 warning）
+- [ ] 退出码 = 0 且失败数 = 0
+- [ ] 验证报告已输出
+
+## 完成标志
+
+```
+状态：DONE | DONE_WITH_CONCERNS | NEEDS_CONTEXT | BLOCKED
+验证结果：✅ 全部通过 / ❌ 存在失败
+```
+
+## STOP Signals
+
+如果你发现自己即将做以下任何一件事——立即停止，重新审视：
+
+- 使用"应该""可能""看起来"等推测性语言来声明通过
+- 引用上一轮运行结果而不是当次新鲜执行的输出
+- 只检查部分输出或跳过 warning 就声明通过
+- 在验证之前就表达满意（"太好了""完美""完成了"）
+
+## 集成关系
+
+**被谁调用：**
+
+- 所有需要验证声明的 skill
+- `team-orchestrator`（编排模式）
+
+**配对使用：**
+
+- `team-debug` — 验证失败时定位根因
+
+## 下一步
+
+- 验证通过后，继续当前流程
+- 验证失败，使用 `team-debug` 定位根因