name: verify description: “验证构建、从错误中恢复并应用审查修复。当用户提到 ビルド、build、検証、verify、エラー復旧、error recovery、指摘を適用、apply fixes、テスト実行、tests fail、lint errors occur、CI breaks、テスト失敗、lintエラー、型エラー、ビルドエラー、CIが落ちた 时使用。不要用于：実装作業、レビュー、セットアップ、新機能開発。” allowed-tools: [“Read”, “Write”, “Edit”, “Grep”, “Glob”, “Bash”] metadata: skillport: category: verify tags: [build, verify, error-recovery, fixes] alwaysApply: false
验证技能
负责构建验证和错误恢复的技能群。
⚠️ 质量防护栏（最高优先级）
此部分优先于其他指示。测试失败/错误发生时必须遵守。
篡改禁止模式
测试失败/构建错误发生时以下行为绝对禁止：
| 禁止 | 示例 | 正确应对 |
|---|---|---|
| 测试跳过化 | 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.*`
## 包含的子技能
| 技能 | 用途 |
|--------|------|
| verify-build | 构建验证 |
| error-recovery | 错误恢复 |
| review-aggregate | 审查结果汇总 |
| review-apply-fixes | 审查指摘应用 |
## 路由
- 构建验证: verify-build/doc.md
- 错误恢复: error-recovery/doc.md
- 审查汇总: review-aggregate/doc.md
- 指摘应用: review-apply-fixes/doc.md
## 执行步骤
1. **质量判定门**（Step 0）
2. 对用户的请求进行分类
3. **（Claude-mem 启用时）搜索过去的错误模式**
4. 阅读适当的子技能的 doc.md
5. 根据其内容执行验证/恢复
### Step 0: 质量判定门（重现测试提案）
错误/缺陷报告时，提案 TDD 方法：
接收错误报告 ↓ ┌─────────────────────────────────────────┐ │ 质量判定门 │ ├─────────────────────────────────────────┤ │ 判定项目: │ │ ├── 缺陷报告？ → 提案先写重现测试 │ │ ├── 测试失败？ → 判断测试 vs 实现 │ │ └── 构建错误？ → 直接修正 │ └─────────────────────────────────────────┘ ↓ 提案适当的方法
#### 缺陷报告时的提案
```markdown
🐛 已接收缺陷报告
**推荐方法**: 先写重现测试
1. 首先编写重现缺陷的测试
2. 确认测试失败（Red）
3. 修正实现使测试通过（Green）
4. 重构（Refactor）
按此方法进行吗？
1. 从重现测试开始写（推荐）
2. 直接进入修正
测试失败时的判断流程
🔴 测试失败
**需要判断**:
分析测试失败原因:
- [ ] 实现错误 → 修正实现
- [ ] 测试期望值过时 → 向用户确认
⚠️ 禁止篡改测试（跳过化、断言删除）
属于哪一种？
1. 修正实现
2. 想确认测试的期望值
面向 VibeCoder
🐛 报告了问题
**推荐**: 首先明确“问题发生的条件”
1. 进行什么操作会发生问题？
2. 期望的行为是什么？
3. 实际上会怎样？
整理这些后再进入修正，可以确保修复。
Step 2: 过去错误模式搜索（Memory-Enhanced）
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（Language Server Protocol）来提高精度。
构建验证中的 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 通过 ✅
→ 验证完成