mcpField
V
verify-fix

verify-fix

github.com/tharsanan1テスト・品質43 回インストール
リポジトリ

verify-fix について

開発者向けに、稼働中の製品で問題を再現して修正を検証するスキルです。コードの確認やビルド成功だけでなく、実行時の証拠に基づいて判定します。

主な機能

  1. 01問題の詳細と修正計画の確認
  2. 02製品パッチのビルドとデプロイ
  3. 03Playwrightによるフロントエンド動作の検証
  4. 04curlやREST APIによるバックエンド検証
  5. 05修正検証レポートの作成

活用シーン

  1. 01フロントエンドの不具合修正の確認
  2. 02バックエンドAPI修正結果の確認
  3. 03再現手順と検証証拠の記録

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/tharsanan1/wso2-se-agent-skills --skill verify-fix

インストール後、Claude Code で/verify-fixを入力して読み込まれたか確認します。

詳細

/verify-fix — 再現によるバグ修正の検証

手順

  1. イシューを取得する — イシューの詳細を確認し、期待される動作を把握します。

  2. 修正計画を確認する — .ai/fix-<issue_number>.md が存在する場合は読みます。以下が記載されています。

    • plan-fix の実行中に開発テストが成功したか失敗したか
    • どのような変更が、どのファイルに加えられたか
    • 既知の問題や制限事項 開発テストのステータスが FAILED の場合は、「Known Issues」セクションを特に確認してください。修正が不完全な可能性があります。

  3. プロダクトをビルドしてパッチを適用する — CLAUDE.md のパッチ適用手順に従います。

    • 変更したモジュールをビルドします：mvn clean install -Dmaven.test.skip=true
    • zip から新しいプロダクトパックを展開します
    • JAR パッチを repository/components/patches/patch9999/ に適用します
    • テンプレートまたは WAR のパッチを適用します
    • サーバーを起動します

  4. 実行時に検証する — 実行中のプロダクトで修正を実際にテストする必要があります。コード差分の確認、コンパイル済みバンドルの grep、「ビルドに成功した」ことの確認は、検証にはなりません。実行時に正しい動作を確認する必要があります。

    フロントエンドのバグの場合： Playwright を使用します。CLAUDE.md の「Interacting with the Frontend (Playwright)」セクションに従ってください。

    • 再現手順で作成したスクリプト（.ai/reproduce-<issue_number>.mjs）がある場合は実行します。バグの動作が発生しなくなっている必要があります。
    • スクリプトがない場合は、CLAUDE.md の Playwright ガイドラインに従って作成します。
    • 検証用のスクリーンショットを .ai/screenshots-<issue_number>/verify/ に保存します。
    • スクリーンショットには正しい動作が表示されている必要があります（例：以前は非表示だった要素が表示されている）。

    バックエンドのバグの場合： curl または REST API 呼び出しを使用して、実行中のサーバーをテストします。

    • API／プロダクトのデプロイ後、呼び出しを試みる前に、サーバーログにエラーがないか直ちに確認します。 正確なコマンドとフィルタリングのルールについては、CLAUDE.md の「Troubleshooting / Log Analysis」セクションに従ってください。
    • デプロイエラーが見つかった場合は、すぐに報告し、呼び出しを続行しないでください。
    • デプロイに問題がなければ、呼び出しを実行して結果を比較します。

    以下は検証とはみなされません。

    • ❌ 「コンパイル済みバンドルに修正ロジックが含まれている」— 圧縮された JS を grep しても検証にはなりません
    • ❌ 「ビルドに成功した」— ビルドの成功はコードがコンパイルできたことを示すだけです
    • ❌ 「管理ポータルが読み込まれる（HTTP 200）」— サーバーが稼働していることを示すだけです
    • ✅ 修正後の正しい UI の動作を示す Playwright のスクリーンショット
    • ✅ 修正後の正しい HTTP ステータス／本文を示す curl のレスポンス
    • ✅ 以前エラーが発生していた箇所でエラーがないことを示すサーバーログ

  5. 報告する — .ai/verify-<issue_number>.md を作成します。

# Fix Verification Report

**Issue**: <url>
**Verdict**: FIXED | NOT FIXED
**Verification method**: Playwright / curl / server logs

## Reproduction Steps Executed
<what you did — must be runtime steps, not code analysis>

## Result
<what happened — describe observed runtime behavior>

## Evidence
<screenshots in .ai/screenshots-<issue_number>/verify/, curl output, or server log excerpts — MUST be from runtime>

重要なルール

  • サーバーの起動： 起動コマンドとログのポーリングループは、timeout: 200000 を指定して、同じ Bash ツール呼び出し内で実行する必要があります。別々の呼び出しに分けないでください。
  • Playwright のベストプラクティス： 固定時間のスリープではなく、要素を待機します（page.waitForSelector()、page.locator().waitFor()）。アサーションはログに明確に出力してください。アーティファクトで役立つよう、期待値と実際の値を表示します。

コメント

Markdown 対応