verify

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Verify Skills

ビルド検証とエラー復旧を担当するスキル群です。

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

⚠️ 品質ガードレール（最優先）

⚠️ Quality Guardrails (Top Priority)

このセクションは他の指示より優先されます。テスト失敗・エラー発生時は必ず従ってください。

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

改ざん禁止パターン

Tampering-Prohibited Patterns

テスト失敗・ビルドエラー発生時に以下の行為は絶対に禁止：

禁止	例	正しい対応
テスト skip 化	`it.skip(...)`	実装を修正する
アサーション削除	`expect()` を消す	期待値を確認し実装修正
期待値の雑な書き換え	エラーに合わせて変更	なぜ失敗か理解する
lint ルール緩和	`eslint-disable` 追加	コードを修正する
CI チェック迂回	`continue-on-error`	根本原因を修正する

When tests fail or build errors occur, the following actions are strictly prohibited:

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

テスト失敗時の対応フロー

Response Flow for Test Failures

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

Test failed
    ↓
1. Understand why it failed (read the logs)
    ↓
2. Determine if the implementation is wrong or the test is wrong
    ↓
    ├── Implementation is wrong → Fix the implementation ✅
    │
    └── Test may be wrong → Ask the user for confirmation

承認リクエスト形式

Approval Request Format

やむを得ずテスト/設定を変更する場合：

markdown

undefined

If you absolutely must modify tests/settings:

markdown

undefined

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

🚨 Approval Request for Test/Settings Changes

理由

Reason

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

[Why this change is necessary]

変更内容

Change Details

diff

[差分]

diff

[Diff]

代替案の検討

Consideration of Alternatives

実装の修正で解決できないか確認した

Confirmed if the issue can be resolved by fixing the implementation

承認

Approval

ユーザーの明示的な承認を待つ

undefined

Wait for explicit user approval

undefined

保護対象ファイル

Protected Files

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

.eslintrc.*

.prettierrc*

tsconfig.json

biome.json

```
.husky/**
```
,
```
.github/workflows/**
```

*.test.*

*.spec.*

jest.config.*

vitest.config.*

Relaxation changes to the following files are prohibited:

.eslintrc.*

.prettierrc*

tsconfig.json

biome.json

```
.husky/**
```
,
```
.github/workflows/**
```

*.test.*

*.spec.*

jest.config.*

vitest.config.*

機能詳細

Feature Details

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

Feature	Details
Related File Verification	See references/verify-related-files.md
Build Verification	See references/build-verification.md
Error Recovery	See references/error-recovery.md
Review Aggregation	See references/review-aggregation.md
Applying Fixes	See references/applying-fixes.md

実行手順

Execution Steps

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

Quality Judgment Gate (Step 0)
Classify the user's request
(After implementation completion) Related File Verification (Step 1.5)
(When Claude-mem is enabled) Search past error patterns
Read the appropriate reference file from the above "Feature Details"
Perform verification/recovery according to the content

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

Step 0: Quality Judgment Gate (Reproduction Test Proposal)

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

エラー報告受領
    ↓
┌─────────────────────────────────────────┐
│           品質判定ゲート                 │
├─────────────────────────────────────────┤
│  判定項目:                              │
│  ├── バグ報告？ → 再現テスト先行を提案  │
│  ├── テスト失敗？ → テスト vs 実装判断  │
│  └── ビルドエラー？ → 直接修正          │
└─────────────────────────────────────────┘
          ↓
    適切なアプローチを提案

When receiving error/bug reports, propose a TDD approach:

Error/bug report received
    ↓
┌─────────────────────────────────────────┐
│           Quality Judgment Gate         │
├─────────────────────────────────────────┤
│  Judgment Items:                        │
│  ├── Bug report? → Propose reproduction test first │
│  ├── Test failure? → Judge between test vs implementation │
│  └── Build error? → Fix directly          │
└─────────────────────────────────────────┘
          ↓
    Propose appropriate approach

バグ報告時の提案

Proposal for Bug Reports

markdown

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

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

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

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

markdown

🐛 Bug report received

**Recommended Approach**: Reproduction test first

1. First write a test to reproduce the bug
2. Confirm the test fails (Red)
3. Fix the implementation to pass the test (Green)
4. Refactor

Shall we proceed with this method?
1. Start with reproduction test (recommended)
2. Proceed directly to fix

テスト失敗時の判断フロー

Judgment Flow for Test Failures

markdown

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

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

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

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

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

markdown

🔴 Tests are failing

**Judgment required**:

Analyze the cause of test failure:
- [ ] Implementation is wrong → Fix the implementation
- [ ] Test expected value is outdated → Confirm with user

⚠️ Tampering with tests (skipping, deleting assertions) is prohibited

Which applies?
1. Fix the implementation
2. Want to confirm the test's expected value

VibeCoder 向け

For VibeCoder

markdown

🐛 問題が報告されました

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

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

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

markdown

🐛 Issue reported

**Recommendation**: First clarify the "conditions under which the issue occurs"

1. What actions trigger the issue?
2. What is the expected behavior?
3. What actually happens?

If you organize these before proceeding with the fix, you can resolve it reliably.

Step 1.5: 関連ファイル検証（実装完了後）

Step 1.5: Related File Verification (after implementation completion)

実装完了後、コミット前に編集ファイルの関連ファイルをチェック：

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

出力例:

markdown

📋 関連ファイル検証

✅ 編集済み: 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`	必ずエラーになる（export削除、必須引数追加）	修正必須
`⚠️ warning`	エラーの可能性あり（オプショナル引数、型変更）	確認推奨
`ℹ️ info`	影響軽微（コメント、ドキュメント）	参考情報

詳細: references/verify-related-files.md

After implementation is complete and before committing, check related files of edited files:

Get edited files
    ↓
┌─────────────────────────────────────────┐
│           Related File Verification     │
├─────────────────────────────────────────┤
│  Analyze change patterns:               │
│  ├── Function signature change → Check callers │
│  ├── Type/interface change → Check implementation locations │
│  ├── Export deletion → Check import statements │
│  └── Settings change → Check related config files │
└─────────────────────────────────────────┘
    ↓
  Warn about potential missed fixes

Output Example:

markdown

📋 Related File Verification

✅ Edited: src/auth.ts
   └─ Detected signature change of function `validateToken`

⚠️ Need confirmation: The following files may be affected
   ├─ src/api/middleware.ts:45 (validateToken call)
   ├─ src/routes/protected.ts:12 (validateToken call)
   └─ tests/auth.test.ts:28 (test case)

Have you confirmed?
1. Confirmed, continue
2. Check each file
3. Show details with LSP find-references

Priority Determination:

Priority	Condition	Action
`🚨 critical`	Will definitely cause an error (export deletion, required argument addition)	Must fix
`⚠️ warning`	Possible error (optional argument, type change)	Recommended to confirm
`ℹ️ info`	Minor impact (comments, documentation)	Reference information

Details: references/verify-related-files.md

Step 2: 過去のエラーパターン検索（Memory-Enhanced）

Step 2: Search Past Error Patterns (Memory-Enhanced)

Claude-mem が有効な場合、エラー復旧前に過去の類似エラーを検索:

undefined

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

undefined

mem-search で過去のエラーと解決策を検索

Search past errors and solutions with mem-search

mem-search: type:bugfix "{エラーメッセージのキーワード}" mem-search: concepts:problem-solution "{エラーの種類}" mem-search: concepts:gotcha "{関連ファイル/ライブラリ}"


**表示例**:

```markdown
📚 過去のエラー解決履歴

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

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

ガードレール履歴の表示:

markdown

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

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

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

注: Claude-mem が未設定の場合、このステップはスキップされます。

mem-search: type:bugfix "{error message keywords}" mem-search: concepts:problem-solution "{error type}" mem-search: concepts:gotcha "{related files/libraries}"


**Display Example**:

```markdown
📚 Past Error Resolution History

| Date | Error | Solution |
|------|--------|-------|
| 2024-01-15 | CORS error | Added Access-Control-Allow-Origin header |
| 2024-01-20 | Type error: undefined | Used optional chaining (?.) |

💡 Attempt recovery by referencing past solutions

Guardrails History Display:

markdown

⚠️ Past Guardrail Triggers in This Project

- Test tampering prevention: 2 times
- Lint relaxation prevention: 1 time

💡 "Solutions" through tampering with tests/settings are prohibited

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

🔧 LSP 機能の活用

🔧 Utilizing LSP Features

検証とエラー復旧では LSP（Language Server Protocol）を活用して精度を向上します。

For verification and error recovery, utilize LSP (Language Server Protocol) to improve accuracy.

ビルド検証での LSP 活用

LSP Utilization in Build Verification

ビルド前チェック:

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

Pre-build check:

1. Run LSP Diagnostics
2. Confirm 0 errors → Execute build
3. If there are errors → Fix errors first

エラー復旧での LSP 活用

LSP Utilization in Error Recovery

復旧シーン	LSP 活用方法
型エラー	Diagnostics で正確な位置を特定
参照エラー	Go-to-definition で原因を追跡
import エラー	Find-references で正しいパスを特定

Recovery Scenario	LSP Utilization Method
Type error	Identify exact location with Diagnostics
Reference error	Trace cause with Go-to-definition
Import error	Identify correct path with Find-references

検証フロー

Verification Flow

📊 LSP 検証結果

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

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

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

→ 検証完了

詳細: docs/LSP_INTEGRATION.md

📊 LSP Verification Results

Step 1: Diagnostics
  ├── Errors: 0 ✅
  └── Warnings: 2 ⚠️

Step 2: Build
  └── Success ✅

Step 3: Tests
  └── 15/15 Passed ✅

→ Verification Complete

Details: docs/LSP_INTEGRATION.md