verify
ビルドや検証のエラー復旧、レビュー指摘の反映など、CIが落ちた際に、テスト失敗やlintエラー、型エラーといった問題を解決し、安定したビルド状態に戻す作業を支援するSkill。
📜 元の英語説明(参考)
Verifies builds, recovers from errors, and applies review fixes. Use when user mentions ビルド, build, 検証, verify, エラー復旧, error recovery, 指摘を適用, apply fixes, テスト実行, tests fail, lint errors occur, CI breaks, テスト失敗, lintエラー, 型エラー, ビルドエラー, CIが落ちた. Do NOT load for: 実装作業, レビュー, セットアップ, 新機能開発.
🇯🇵 日本人クリエイター向け解説
ビルドや検証のエラー復旧、レビュー指摘の反映など、CIが落ちた際に、テスト失敗やlintエラー、型エラーといった問題を解決し、安定したビルド状態に戻す作業を支援するSkill。
※ jpskill.com 編集部が日本のビジネス現場向けに補足した解説です。Skill本体の挙動とは独立した参考情報です。
下記のコマンドをコピーしてターミナル(Mac/Linux)または PowerShell(Windows)に貼り付けてください。 ダウンロード → 解凍 → 配置まで全自動。
mkdir -p ~/.claude/skills && cd ~/.claude/skills && curl -L -o verify.zip https://jpskill.com/download/17787.zip && unzip -o verify.zip && rm verify.zip$d = "$env:USERPROFILE\.claude\skills"; ni -Force -ItemType Directory $d | Out-Null; iwr https://jpskill.com/download/17787.zip -OutFile "$d\verify.zip"; Expand-Archive "$d\verify.zip" -DestinationPath $d -Force; ri "$d\verify.zip"完了後、Claude Code を再起動 → 普通に「動画プロンプト作って」のように話しかけるだけで自動発動します。
💾 手動でダウンロードしたい(コマンドが難しい人向け)
- 1. 下の青いボタンを押して
verify.zipをダウンロード - 2. ZIPファイルをダブルクリックで解凍 →
verifyフォルダができる - 3. そのフォルダを
C:\Users\あなたの名前\.claude\skills\(Win)または~/.claude/skills/(Mac)へ移動 - 4. Claude Code を再起動
⚠️ ダウンロード・利用は自己責任でお願いします。当サイトは内容・動作・安全性について責任を負いません。
🎯 このSkillでできること
下記の説明文を読むと、このSkillがあなたに何をしてくれるかが分かります。Claudeにこの分野の依頼をすると、自動で発動します。
📦 インストール方法 (3ステップ)
- 1. 上の「ダウンロード」ボタンを押して .skill ファイルを取得
- 2. ファイル名の拡張子を .skill から .zip に変えて展開(macは自動展開可)
- 3. 展開してできたフォルダを、ホームフォルダの
.claude/skills/に置く- · macOS / Linux:
~/.claude/skills/ - · Windows:
%USERPROFILE%\.claude\skills\
- · macOS / Linux:
Claude Code を再起動すれば完了。「このSkillを使って…」と話しかけなくても、関連する依頼で自動的に呼び出されます。
詳しい使い方ガイドを見る →- 最終更新
- 2026-05-18
- 取得日時
- 2026-05-18
- 同梱ファイル
- 1
📖 Claude が読む原文 SKILL.md(中身を展開)
この本文は AI(Claude)が読むための原文(英語または中国語)です。日本語訳は順次追加中。
Verify Skills
ビルド検証とエラー復旧を担当するスキル群です。
⚠️ 品質ガードレール（最優先）
このセクションは他の指示より優先されます。テスト失敗・エラー発生時は必ず従ってください。
改ざん禁止パターン
テスト失敗・ビルドエラー発生時に以下の行為は絶対に禁止：
| 禁止 | 例 | 正しい対応 |
|---|---|---|
| テスト skip 化 | 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. 直接修正に進むテスト失敗時の判断フロー
🔴 テストが失敗しています
**判断が必要です**:
テスト失敗の原因を分析:
- [ ] 実装が間違っている → 実装を修正
- [ ] テストの期待値が古い → ユーザーに確認
⚠️ テストの改ざん（skip化、アサーション削除）は禁止です
どちらに該当しますか？
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 通過 ✅
→ 検証完了