verify-commands について
verify-commandsは、コマンドラインの受け入れチェックを作成・レビューする開発者向けスキルです。観測可能な失敗シグナル、根拠のあるパス確認、実際には測定しないチェックの回避に重点を置きます。
主な機能
- 01明確な失敗シグナルの定義
- 02リポジトリの根拠に基づくパス確認
- 03測定にならないチェックの検出
- 04代替パスを推測せずにコマンドをレビュー
活用シーン
- 01出荷前の受け入れチェック作成
- 02テストせずに通る可能性のあるコマンドのレビュー
- 03リポジトリのパスとマニフェストの確認
- 04脆弱なシェルパイプやフィルターの特定
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/インストール後、Claude Code で/verify-commandsを入力して読み込まれたか確認します。
詳細
検証コマンド
検証コマンドは受け入れテストです。実行に移す前に、次の問いに答えてください。このコマンドがひそかに何もしていなかったとしたら、出力のどこでそれがわかりますか？ 答えられないなら、それはコマンドであって、チェックではありません。コマンドを修正してください。コマンドのために説明文をでっち上げてはいけません。
失敗の兆候を明記する
実行可能なチェックのそれぞれに、失敗を意味する観測可能な兆候を一行で書いてください。例：non-zero exit、概要行に "0 passed" が含まれる、カバレッジの行がない、stderr に "ECONNREFUSED" が含まれる。「コマンドが失敗する」「エラーが発生する」は言い換えにすぎず、兆候ではありません。TBD、N/A、none は回答の拒否です。短くてもかまいません。non-zero exit だけで十分です。想像した兆候ではなく、ツールが実際に出力する兆候を優先してください。すでに実行したコマンドなら、実際に確認した内容を書いてください。新しいコマンドなら、ツールのドキュメントに記載された出力から兆候を選んでください。コマンドが N 個なら、記述も N 個必要です。
すべてのパスの根拠を示す
新しいコマンドを導き出す前に、このリポジトリですでに成功したコマンドをそのまま引き継いでください。cd の移動先や --prefix の対象は存在しているか、前の手順で作成されている必要があり、対応するマニフェスト（package.json、Makefile、pyproject.toml）が置かれていなければなりません。cd <dir> && npm run <script> より npm --prefix <dir> run <script> を優先してください。呼び出し元の作業ディレクトリに依存しません。ファイルシステムについて推測せず、一覧を確認してください。パスの根拠を示せない場合は、推測せず、その旨を伝えてください。
何も測らずに通るパターン
| 落とし穴 | 通ってしまう理由 | 代わりに |
|---|---|---|
pnpm ls vite | grep -E '^vite@7' | ツリー出力の各行は └── で始まるため、^ に一致しない | アンカーを外すか、(└|├)── vite@7 に一致させる |
npm test | grep '714 passed' | 記憶から思い出した件数であり、学習データ由来で古くなっている | grep -E '[0-9]+ passed' を使うか、先に件数を実行して確認する |
[ "$X" = "$Y" ] に渡す X=$(cmd 2>/dev/null || echo 0) | 入力がないと両方とも 0 になるため、何も確認できていなくても一致してしまう | 失敗を伝播させるか、test -f で確認してから終了する |
指示やコメントに LITERAL が記載されているときに、grep -c 'LITERAL' file == 0 を使う | コードではなくコメントの文字列に反応してしまう | 禁止する内容を文字列そのものではなく、概念で記述する |
同じファイルの別の箇所に PATTERN が正当に追加されたときに、! grep -q PATTERN file を使う | ファイル全体を対象とする否定条件は、複数の領域があると成立しない | 対象を限定する。例：awk '/^def f/,/^def /' file | grep、AST チェック、単体テスト |
| 0 件のテストに一致するテスト名フィルター | 何も検証されないまま終了コード 0 になる | 先にテストを一覧表示し（--collect-only、--list）、その後で指定したテストを実行する |
終了ステータスを判定結果として使う npm test | tail -20 | パイプラインは最後のコマンドのステータスを返すため、npm test が失敗しても tail は 0 を返す | 同じコマンド行の先頭を set -o pipefail; npm test | tail -20 にする（bash、zsh）。以前のツール呼び出しで実行した set は引き継がれない |
アンカーの落とし穴はほかにもあります。npm ls、yarn list、docker ps、kubectl get は、いずれも列やツリーの接頭辞を出力します。|| echo default を使ってよいのは、値が存在しないことをデフォルトとして扱い、その値を不存在の検出を目的とした比較に使わない場合だけです。
他の人のコマンドをレビューする
報告に徹し、確認していない代替パスを提案してはいけません。提案したパスをそのままコピーするだけでは、情報は何も増えません。ディレクトリやマニフェストが見つからない場合は、対象の生のパスを引用してください。動的なパス、グロブ、~、変数は警告の対象であり、具体的なパスを推測してよい理由にはなりません。