name: verify description: “构建验证、错误恢复、评审修复的适用。当用户提到构建验证、错误恢复、应用评审修复、测试失败、lint错误或CI中断时使用。不要用于：实现工作、评审、设置或新功能开发。” description-en: “验证构建、从错误中恢复并应用评审修复。当用户提到构建验证、错误恢复、应用评审修复、测试失败、lint错误或CI中断时使用。不要用于：实现工作、评审、设置或新功能开发。” description-ja: “构建验证、错误恢复、评审修复的适用。当用户提到构建验证、错误恢复、应用评审修复、测试失败、lint错误或CI中断时使用。不要用于：实现工作、评审、设置或新功能开发。” allowed-tools: [“Read”, “Write”, “Edit”, “Grep”, “Glob”, “Bash”] user-invocable: true context: fork
验证技能
负责构建验证和错误恢复的技能群。
⚠️ 质量护栏（最优先）
本部分优先于其他指示。测试失败、错误发生时必须遵守。
篡改禁止模式
测试失败、构建错误发生时以下行为绝对禁止：
| 禁止 | 例 | 正确对应 |
|---|---|---|
| 测试跳过化 | it.skip(...) |
修正实现 |
| 断言删除 | 删除 expect() |
确认期望值并修正实现 |
| 期望值随意改写 | 根据错误变更 | 理解为何失败 |
| lint规则放宽 | 添加 eslint-disable |
修正代码 |
| CI检查迂回 | continue-on-error |
修正根本原因 |
测试失败时的对应流程
测试失败
↓
1. 理解为何失败（阅读日志）
↓
2. 判断实现错误还是测试错误
↓
├── 实现错误 → 修正实现 ✅
│
└── 测试可能错误 → 向用户确认
批准请求形式
不得已变更测试/设置时：
## 🚨 测试/设置变更的批准请求
### 理由
[为何需要此变更]
### 变更内容
```diff
[差异]
替代方案考虑
- [ ] 确认是否可通过实现修正解决
批准
等待用户明确批准
### 保护对象文件
以下文件的放宽变更禁止：
- `.eslintrc.*`, `.prettierrc*`, `tsconfig.json`, `biome.json`
- `.husky/**`, `.github/workflows/**`
- `*.test.*`, `*.spec.*`, `jest.config.*`, `vitest.config.*`
## 功能详细
| 功能 | 详细 |
|------|------|
| **相关文件验证** | 参见 [references/verify-related-files.md](references/verify-related-files.md) |
| **构建验证** | 参见 [references/build-verification.md](references/build-verification.md) |
| **错误恢复** | 参见 [references/error-recovery.md](references/error-recovery.md) |
| **评审聚合** | 参见 [references/review-aggregation.md](references/review-aggregation.md) |
| **指摘应用** | 参见 [references/applying-fixes.md](references/applying-fixes.md) |
## 执行步骤
1. **质量判定门**（Step 0）
2. 分类用户请求
3. **（实现完成后）相关文件验证**（Step 1.5）
4. **（Claude-mem 有效时）搜索过去的错误模式**
5. 从上述“功能详细”阅读适当参考文件
6. 根据内容执行验证/恢复
### Step 0: 质量判定门（再现测试提案）
错误/缺陷报告时，提案TDD方法：
接收错误报告 ↓ ┌─────────────────────────────────────────┐ │ 质量判定门 │ ├─────────────────────────────────────────┤ │ 判定项目: │ │ ├── 缺陷报告？ → 提案先行再现测试 │ │ ├── 测试失败？ → 判断测试 vs 实现 │ │ └── 构建错误？ → 直接修正 │ └─────────────────────────────────────────┘ ↓ 提案适当方法
#### 缺陷报告时的提案
```markdown
🐛 接受缺陷报告
**推荐方法**: 先行再现测试
1. 首先编写再现缺陷的测试
2. 确认测试失败（Red）
3. 修正实现使测试通过（Green）
4. 重构（Refactor）
按此方法进行吗？
1. 从再现测试开始写（推荐）
2. 直接进行修正
测试失败时的判断流程
🔴 测试失败
**需要判断**:
分析测试失败原因:
- [ ] 实现错误 → 修正实现
- [ ] 测试期望值过时 → 向用户确认
⚠️ 禁止篡改测试（跳过化、断言删除）
哪项适用？
1. 修正实现
2. 确认测试期望值
面向VibeCoder
🐛 报告问题
**推荐**: 首先明确“问题发生的条件”
1. 进行什么操作会发生问题？
2. 期望动作是什么？
3. 实际如何发生？
整理后推进修正，确保解决。
Step 1.5: 相关文件验证（实现完成后）
实现完成后，提交前检查编辑文件的相关文件：
获取编辑文件
↓
┌─────────────────────────────────────────┐
│ 相关文件验证 │
├─────────────────────────────────────────┤
│ 分析变更模式: │
│ ├── 函数签名变更 → 确认调用源 │
│ ├── 类型/接口变更 → 确认实现处 │
│ ├── 导出删除 → 确认导入语句 │
│ └── 设置变更 → 确认相关设置文件 │
└─────────────────────────────────────────┘
↓
警告可能修正遗漏
输出例:
📋 相关文件验证
✅ 已编辑: src/auth.ts
└─ 检测到函数 `validateToken` 的签名变更
⚠️ 需确认: 以下文件可能受影响
├─ src/api/middleware.ts:45 (调用 validateToken)
├─ src/routes/protected.ts:12 (调用 validateToken)
└─ tests/auth.test.ts:28 (测试用例)
确认了吗？
1. 已确认，继续
2. 确认各文件
3. 使用LSP find-references 详细显示
重要度判定:
| 重要度 | 条件 | 行动 |
|---|---|---|
🚨 critical |
必定错误（导出删除、必需参数添加） | 必须修正 |
⚠️ warning |
可能错误（可选参数、类型变更） | 推荐确认 |
ℹ️ info |
影响轻微（注释、文档） | 参考信息 |
详细: references/verify-related-files.md
Step 2: 过去错误模式搜索（记忆增强）
Claude-mem有效时，错误恢复前搜索过去类似错误：
# mem-search 搜索过去错误和解决方案
mem-search: type:bugfix "{错误消息关键词}"
mem-search: concepts:problem-solution "{错误种类}"
mem-search: concepts:gotcha "{相关文件/库}"
显示例:
📚 过去错误解决记录
| 日期 | 错误 | 解决方案 |
|------|--------|-------|
| 2024-01-15 | CORS 错误 | 添加 Access-Control-Allow-Origin 头 |
| 2024-01-20 | 类型错误: undefined | 使用 Optional chaining (?.) |
💡 参考过去解决方案尝试恢复
护栏历史显示:
⚠️ 本项目过去的护栏触发
- 防止测试篡改: 2次
- 防止lint放宽: 1次
💡 禁止通过测试/设置篡改“解决”
注: Claude-mem未设置时，跳过此步骤。
🔧 LSP 功能活用
验证和错误恢复活用LSP（语言服务器协议）提高精度。
构建验证中的LSP活用
构建前检查:
1. 执行LSP Diagnostics
2. 错误: 0件确认 → 执行构建
3. 有错误 → 先修正错误
错误恢复中的LSP活用
| 恢复场景 | LSP 活用方法 |
|---|---|
| 类型错误 | Diagnostics 准确定位位置 |
| 引用错误 | Go-to-definition 追踪原因 |
| import 错误 | Find-references 确定正确路径 |
验证流程
📊 LSP 验证结果
Step 1: Diagnostics
├── 错误: 0件 ✅
└── 警告: 2件 ⚠️
Step 2: 构建
└── 成功 ✅
Step 3: 测试
└── 15/15 通过 ✅
→ 验证完成