verify について
verifyは、UIや動作の変更を完了とする前に、実行結果で確認するためのスキルです。問題の再現、影響範囲全体の確認、検証内容と未確認事項の報告を支援します。
主な機能
- 01編集前の問題再現
- 02再読み込み後の実行結果確認
- 03追加したコントロールのテスト
- 04再発時の原因調査
- 05確認内容と未検証項目の報告
活用シーン
- 01実装後のUI変更の検証
- 02実行中のアプリでの問題再確認
- 03追加コントロールの反応確認
- 04テストできない変更の報告
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/インストール後、Claude Code で/verifyを入力して読み込まれたか確認します。
同梱ファイルagents/openai.yamlLICENSE
詳細
検証
このスキルでは、変更を完了と呼べるタイミングを判断します。ビルドの成功ではなく、実行結果から得られる証拠を求めます。
ビルドは証拠にならない
型チェック、Lint の成功、ビルドの成功だけでは、見た目や動作に関する変更が機能することは示せません。結果を開かずに「修正しました」と言うのは指摘事項です。結果を開いて、不完全な状態を報告するのは指摘事項ではありません。
UI または動作を変更したら、「完了」と返答する前に実行してください。ユーザーが「まだです」「何も変わっていません」「自分でテストしてください」と言った場合は、直ちに実行してください。変更内容は scope に従います。外部アプリとの一致は match に従います。
1. まず問題を確認する
編集する前に、アプリ、ページ、または出力を開き、症状を見つけてください。ブラウザー、スクリーンショット、またはコンピューター操作を使います。説明だけをもとに編集するのは verify-reproduce-first です。実行結果を確認できない場合は、何が妨げになっているかを伝えてください。
2. ユーザーが見る場所を確認する
再読み込みするか、ホットリロードが適用されたことを確認してから、同じ場所を見てください。証拠としてビルドの成功を示すのは verify-build-is-not-proof です。追加した各コントロールを一度クリックしてください。反応しないコントロールは verify-click-new-controls です。
編集した行だけでなく、画面全体を確認してください。両端までスクロールし、変更に関係する各状態を開いてください。編集した要素だけを確認するのは verify-whole-surface です。
3. 同じ問題が再度報告されたら原因を見つける
ユーザーから同じ問題が再度報告されたら、同じ値の調整を続けないでください。動作していた最後のコミットとの差分を確認するか、計算済みスタイルを読み取るか、原因を検索してください。1つのプロパティを3度目に推測で変更するのは verify-root-cause-on-repeat です。
4. 確認した内容を報告する
何を、どのように確認したか、ユーザーがどこで確認できるかを伝えてください。ルート、ウィンドウ、メニューの経路、またはフォルダーを示します。「これで動くはずです」は verify-say-where です。可能な場合は、ユーザーのために結果を開いてください。出力パスだけを示すのは verify-open-the-result です。
確認できなかった項目とその理由を明記してください。未確認の項目があるのに「完了」とするのは verify-name-the-gap です。
対になる例
各チェックには対になる例があります。問題のある行の隣に、それを置き換える行を示します。
| ルール | 問題のある例 | 置き換え例 |
|---|---|---|
verify-reproduce-first | バグ報告だけをもとに編集する | 画面を開いてバグを確認してから編集する |
verify-build-is-not-proof | 「型チェックが通ったので修正済みです」 | 「Settings を再読み込みし、トグルが保持されることを確認しました」 |
verify-click-new-controls | ハンドラーのない新しい「Add Condition」ボタン | 一度クリックして行が表示されることを確認する |
verify-whole-surface | 編集した行だけを確認する | パネル全体を両端までスクロールして確認する |
verify-root-cause-on-repeat | 同じ padding を3度目に調整する | 動作していた最後のコミットとの差分を確認してから修正する |
verify-say-where | 「これで動くはずです」 | 「Library を開き、保存項目を右クリックして Hide を選択してください」 |
verify-open-the-result | 返信に ~/Downloads/clips と出力する | ユーザーがフォルダーを開けるようにする |
verify-name-the-gap | エクスポートを一度も実行していないのに「完了」とする | 「未検証：エクスポート。署名済みビルドが必要です」 |
報告
重大度。 実行結果を確認せずに「完了」とする場合、または新しいコントロールが何も実行しない場合は HIGH です。同じ問題の再報告に対してまた推測で変更する場合、または変更を確認できる場所を返信に記載しない場合は MEDIUM です。変更を確認したものの、どのように確認したかを返信に記載しない場合は LOW です。
形式。 根本原因ごとに1件の指摘を記載し、該当するファイルがない場合は依頼内容を引用します。
file:line - [rule-id] what is wrong
request 2 - [rule-id] what is wrong
続けて Rule | Count | Severity の概要を記載します。HIGH が1つでも残っている場合は Block、それ以外は Approve とします。開いて確認していない変更を Approve にしてはいけません。実行できなかったチェックはすべて Not verified と記載してください。