SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillsverify

verify

Testing & quality

View repository

Updated 10-15 17:33

About this skill

Verify Skills

This is a group of skills responsible for build verification and error recovery.

⚠️ Quality guardrails (highest priority)

This section takes precedence over other instructions. Always follow it when tests fail or errors occur.

Tampering-prohibited patterns

When a test failure or build error occurs, the following actions areabsolutely prohibited：

Prohibited Example Correct response
Skipping tests it.skip(...) Fix the implementation
Deleting assertions expect() delete Check the expected values and fix the implementation
Carelessly rewriting expected values Change to match the error Understand why it failed
Relaxing lint rules eslint-disable add Fix the code
Bypassing CI checks continue-on-error Fix the root cause

Response flow when tests fail

テストが失敗した
    ↓
1. なぜ失敗しているか理解する（ログを読む）
    ↓
2. 実装が間違っているか、テストが間違っているか判断
    ↓
    ├── 実装が間違い → 実装を修正 ✅
    │
    └── テストが間違い可能性 → ユーザーに確認を求める

Approval request format

If you unavoidably need to change tests/settings:

## 🚨 テスト/設定変更の承認リクエスト

### 理由
[なぜこの変更が必要か]

### 変更内容
```diff
[差分]

Considering alternatives

  • Confirmed whether it can be resolved by fixing the implementation

Approval

Wait for the user's explicit approval


### 保護対象ファイル

以下のファイルの緩和変更は禁止：

- `.eslintrc.*`, `.prettierrc*`, `tsconfig.json`, `biome.json`
- `.husky/**`, `.github/workflows/**`
- `*.test.*`, `*.spec.*`, `jest.config.*`, `vitest.config.*`

## 機能詳細

| 機能 | 詳細 |
|------|------|
| **関連ファイル検証** | See [references/verify-related-files.md](references/verify-related-files.md) |
| **ビルド検証** | See [references/build-verification.md](references/build-verification.md) |
| **エラー復旧** | See [references/error-recovery.md](references/error-recovery.md) |
| **レビュー集約** | See [references/review-aggregation.md](references/review-aggregation.md) |
| **指摘適用** | See [references/applying-fixes.md](references/applying-fixes.md) |

## 実行手順

1. **品質判定ゲート**（Step 0）
2. ユーザーのリクエストを分類
3. **（実装完了後）関連ファイル検証**（Step 1.5）
4. **（Claude-mem 有効時）過去のエラーパターンを検索**
5. 上記の「機能詳細」から適切な参照ファイルを読む
6. その内容に従って検証/復旧実行

### Step 0: 品質判定ゲート（再現テスト提案）

エラー/バグ報告時に、TDD アプローチを提案:

Error report received ↓ ┌─────────────────────────────────────────┐ │ Quality assessment gate │ ├─────────────────────────────────────────┤ │ Assessment items: │ │ ├── Bug report? → Propose reproduction test first │ │ ├── Test failure? → Decide test vs implementation │ │ └── Build error? → Fix directly │ └─────────────────────────────────────────┘ ↓ Propose an appropriate approach


#### バグ報告時の提案

```markdown
🐛 バグ報告を受け付けました

**推奨アプローチ**: 再現テスト先行

1. まずバグを再現するテストを書く
2. テストが失敗することを確認（Red）
3. 実装を修正してテストを通す（Green）
4. リファクタリング（Refactor）

この方法で進めますか？
1. 再現テストから書く（推奨）
2. 直接修正に進む

Decision flow when tests fail

🔴 テストが失敗しています

**判断が必要です**:

テスト失敗の原因を分析:
- [ ] 実装が間違っている → 実装を修正
- [ ] テストの期待値が古い → ユーザーに確認

⚠️ テストの改ざん（skip化、アサーション削除）は禁止です

どちらに該当しますか？
1. 実装を修正する
2. テストの期待値について確認したい

For VibeCoder

🐛 問題が報告されました

**推奨**: まず「問題が起きる条件」を明確にしましょう

1. どんな操作をすると問題が起きますか？
2. 期待する動作は何ですか？
3. 実際にはどうなりますか？

これを整理してから修正に進むと、確実に直せます。

Step 1.5: Related file verification (after implementation is complete)

After implementation is complete, before committing, check files related to the edited files:

編集ファイルを取得
    ↓
┌─────────────────────────────────────────┐
│           関連ファイル検証               │
├─────────────────────────────────────────┤
│  変更パターンを分析:                     │
│  ├── 関数シグネチャ変更 → 呼び出し元確認 │
│  ├── 型/interface変更 → 実装箇所確認    │
│  ├── export削除 → import文確認         │
│  └── 設定変更 → 関連設定ファイル確認    │
└─────────────────────────────────────────┘
    ↓
  修正漏れ候補を警告

Output example:

📋 関連ファイル検証

✅ 編集済み: 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 で詳細表示

Severity determination:

Severity Condition Action
🚨 critical Will definitely cause an error (removing an export, adding a required argument) Must fix
⚠️ warning May cause an error (optional arguments, type changes) Recommended to check
ℹ️ info Minor impact (comments, documentation) Reference information

Details: references/verify-related-files.md

Step 2: Search past error patterns (Memory-Enhanced)

If Claude-mem is enabled, search for similar past errors before error recovery:

# mem-search で過去のエラーと解決策を検索
mem-search: type:bugfix "{エラーメッセージのキーワード}"
mem-search: concepts:problem-solution "{エラーの種類}"
mem-search: concepts:gotcha "{関連ファイル/ライブラリ}"

Table example:

📚 過去のエラー解決履歴

| 日付 | エラー | 解決策 |
|------|--------|-------|
| 2024-01-15 | CORS エラー | Access-Control-Allow-Origin ヘッダー追加 |
| 2024-01-20 | 型エラー: undefined | Optional chaining (?.) を使用 |

💡 過去の解決策を参考に復旧を試行

Displaying guardrail history:

⚠️ このプロジェクトでの過去のガードレール発動

- テスト改ざん防止: 2回
- lint 緩和防止: 1回

💡 テスト/設定の改ざんによる「解決」は禁止です

Note: If Claude-mem is not configured, this step is skipped.

🔧 Utilizing LSP features

In verification and error recovery, LSP (Language Server Protocol) is utilized to improve accuracy.

Utilizing LSP in build verification

ビルド前チェック:

1. LSP Diagnostics を実行
2. エラー: 0件を確認 → ビルド実行
3. エラーあり → 先にエラーを修正

Utilizing LSP in error recovery

Recovery scenario How to utilize LSP
Type error Identify the exact location with Diagnostics
Reference error Trace the cause with Go-to-definition
import error Identify the correct path with Find-references

Verification flow

📊 LSP 検証結果

Step 1: Diagnostics
  ├── エラー: 0件 ✅
  └── 警告: 2件 ⚠️

Step 2: ビルド
  └── 成功 ✅

Step 3: テスト
  └── 15/15 通過 ✅

→ 検証完了

Details: docs/LSP_INTEGRATION.md