name: verify description: “构建验证、错误恢复、审查修复的应用。当用户提到构建验证、错误恢复、应用审查修复、测试失败、lint错误或CI中断时使用。不要用于：实现工作、审查、设置或新功能开发。” description-en: “Verifies builds, recovers from errors, and applies review fixes. Use when user mentions build verification, error recovery, applying review fixes, test failures, lint errors, or CI breaks. Do NOT load for: implementation work, reviews, setup, or new feature development.” description-ja: “ビルド検証、エラー復旧、レビュー修正の適用。Use when user mentions build verification, error recovery, applying review fixes, test failures, lint errors, or CI breaks. Do NOT load for: implementation work, reviews, setup, or new feature development.” 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. **质量判定门**（步骤0）
2. 对用户的请求进行分类
3. **（实作完成后）相关文件验证**（步骤1.5）
4. **（Claude-mem 启用时）搜索过去的错误模式**
5. 从上述“功能详细”中阅读适当的参考文件
6. 按照其内容执行验证/恢复

### 步骤0: 质量判定门（再现测试提案）

错误/缺陷报告时，建议TDD方法：

接收错误报告 ↓ ┌─────────────────────────────────────────┐ │ 质量判定门 │ ├─────────────────────────────────────────┤ │ 判定项目: │ │ ├── 缺陷报告？ → 建议先行再现测试 │ │ ├── 测试失败？ → 判断测试 vs 实作 │ │ └── 构建错误？ → 直接修正 │ └─────────────────────────────────────────┘ ↓ 建议适当的方法


#### 缺陷报告时的提案

```markdown
🐛 接收缺陷报告

**推荐方法**: 先行再现测试

1. 首先编写再现缺陷的测试
2. 确认测试失败（Red）
3. 修正实作使测试通过（Green）
4. 重构（Refactor）

按此方法进行吗？
1. 从再现测试开始写（推荐）
2. 直接进行修正

测试失败时的判断流程

🔴 测试失败

**需要判断**:

分析测试失败原因：
- [ ] 实作错误 → 修正实作
- [ ] 测试期望值过时 → 向用户确认

⚠️ 禁止篡改测试（跳过化、断言删除）

属于哪种？
1. 修正实作
2. 确认测试期望值

对VibeCoder的指导

🐛 报告问题

**推荐**: 首先明确“问题发生的条件”

1. 进行什么操作会引发问题？
2. 期望行为是什么？
3. 实际发生了什么？

整理后再进行修正，能确保修复。

步骤1.5: 相关文件验证（实作完成后）

实作完成后、提交前，检查编辑文件的相关文件：

获取编辑文件
    ↓
┌─────────────────────────────────────────┐
│           相关文件验证                   │
├─────────────────────────────────────────┤
│  分析更改模式：                         │
│  ├── 函数签名更改 → 确认调用方          │
│  ├── 类型/接口更改 → 确认实现位置       │
│  ├── export删除 → 确认import语句       │
│  └── 设置更改 → 确认相关设置文件        │
└─────────────────────────────────────────┘
    ↓
  警告可能遗漏的修正

输出例子:

📋 相关文件验证

✅ 已编辑: 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详细显示

重要性判定:

重要性	条件	行动
`🚨 严重`	必会出错（export删除、必须参数添加）	必须修正
`⚠️ 警告`	可能出错（可选参数、类型更改）	建议确认
`ℹ️ 信息`	影响轻微（注释、文档）	参考信息

详细: references/verify-related-files.md

步骤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 验证结果

步骤1: Diagnostics
  ├── 错误: 0件 ✅
  └── 警告: 2件 ⚠️

步骤2: 构建
  └── 成功 ✅

步骤3: 测试
  └── 15/15 通过 ✅

→ 验证完成

详细: docs/LSP_INTEGRATION.md