verification-before-completion
「終わった」と言う前に証拠を要求する。主張ごとに何を走らせるかの表がある
npx skills add obra/superpowers/verification-before-completion入れる前にこのスキルがすること・注意点・SKILL.md の原文を確かめてください。解析は安全性の判定ではありません。
- インストール
- 260,210
- 実用度
- 73
- GitHub star
- 313,505
- 最終更新
- 2026/11/4
頼み方の例
そのままコピーして使えますverification-before-completionを使って、この作業が終わったかを確かめてください。主張ごとに、それを証明するコマンドと実際の出力を並べて見せてください。コミットはまだしないでください。
対象のファイルや状況は、ご自身の作業に合わせて置き換えてください。
このスキルがすること
SKILL.md の記述から機械的に抽出- 外部通信・シェル実行・ファイル操作の記述は見つかりませんでした
これは安全性の判定ではありません。 SKILL.md にそう書かれているという事実だけを並べています。実際に問題があるかは使い方と文脈で決まるため、当サイトでは断定しません。導入前に SKILL.md の原文を確認してください。
SKILL.md の規模
いつ使うか
「終わった」「直った」「通った」と言おうとしているとき、その前です。
本文は、コミット・PR の作成・タスクの完了・次のタスクへ移る前・エージェントに任せる前にも必ず通せ、としています。決まった言い回しだけでなく、言い換えや「成功した」と含意する言い方すべてに当てはまる、とも書かれています。
中核の原則が 1 行です。
主張より前に証拠。常に。
そして「この規則の文言に違反することは、規則の精神に違反する」。
鉄の法則
新しい検証の証拠なしに、完了の主張は無い
続けて「このメッセージの中で検証のコマンドを走らせていないなら、通ると主張することはできない」。
「このメッセージの中で」が効きます。セッションの前半で通った、は証拠になりません。
関門の関数が 5 段で決まっている
どんな状態を主張する前にも、この 5 段を通します。
- 特定この主張を証明するコマンドは何か
- 実行完全なコマンドを、新しく、全部
- 読む出力を全部。終了コードを確認。失敗の数を数える
- 検証出力は主張を裏づけているか
- そのあとで初めて主張する
最後に 1 行あります。「どの段を飛ばしても、それは検証ではなく嘘である。」
★主張ごとに「何が証拠になるか」の表がある
ここが最も実用的な部分です。足りないものまで書いてあります。
| 主張 | 必要なもの | 足りないもの |
|---|---|---|
| テストが通る | テストの出力。失敗 0 | 前回の実行、「通るはず」 |
| 静的解析が綺麗 | 解析の出力。エラー 0 | 部分的な確認、外挿 |
| ビルドが成功 | ビルドの終了コード 0 | 静的解析が通ったこと、ログが良さそう |
| 不具合が直った | 元の症状を試す。通る | コードを変えた、直ったと仮定 |
| 回帰テストが効く | 赤→緑の輪を確認 | テストが 1 回通る |
| エージェントが完了した | 差分に変更が出ている | エージェントが「成功」と報告 |
| 要件を満たした | 1 行ずつのチェックリスト | テストが通ること |
「静的解析が通ったこと」はビルドの証拠にならないという行が正確です。別表にも「静的解析はコンパイラではない」とあります。
「エージェントが成功と報告」も証拠にしない。差分を見て、変更が実際にあることを確かめる。
止まるべき兆候が 8 つ
- 「〜のはず」「おそらく」「〜のようだ」を使っている
- 検証の前に満足を表明している（「完璧！」「できました！」）
- 検証なしにコミット・プッシュ・PR に進もうとしている
- エージェントの成功報告を信じている
- 部分的な検証に頼っている
- 「今回だけは」と考えている
- 疲れていて、作業を終わらせたい
- 検証を走らせずに成功を含意するどんな言い方
「疲れていて終わらせたい」が入っているのが率直です。
言い訳を 8 個潰している
- もう動くはず検証を走らせよ
- 自信がある自信は証拠ではない
- 今回だけ例外は無い
- 静的解析が通った静的解析はコンパイラではない
- エージェントが成功と言った独立に検証せよ
- 疲れている疲労は言い訳ではない
- 部分的な確認で足りる部分は何も証明しない
- 言葉が違うから規則は当てはまらない文言より精神
回帰テストの確認手順が具体的
「回帰テストを書きました」だけでは足りない、として手順が並びます。
- 書く
- 走らせる通る
- 修正を戻す
- 走らせる必ず落ちる
- 戻す
- 走らせる通る
修正を一度戻して、テストが落ちることを確かめる。これをしないと、そのテストは何も見張っていない可能性があります。
使わないほうがいいとき
検証のコマンドが無い対象
検証のコマンドが無い対象には使えません。テストもビルドも無いなら、証拠にするものがありません。
探索の段階
探索の段階では邪魔になります。何かを試している最中に「証拠を出せ」と言われると進みません。
別のスキルの担当
失敗するテストを書く側は別です。そちらは test-driven-development です。
原因の調査には向きません。systematic-debugging がその担当で、あちらの第 4 段階からこのスキルが呼ばれます。
レビューの依頼とは別です。requesting-code-review は別のエージェントに見てもらう工程です。
- test-driven-development失敗するテストを書く側
- systematic-debugging原因の調査。第 4 段階からこのスキルを呼ぶ
- requesting-code-review別のエージェントに見てもらう工程
注意点
SKILL.md の解析では、外部通信・ファイル書き換えの記述は見つかっていません。同梱ファイルは 0 件です（2026-10-09 確認）。
実際にはテストやビルドを走らせる
ただし実際にはテストやビルドを走らせます。検証のコマンドを実行するのがこのスキルの仕事です（スキルを入れる前に確認すること）。
時間と計算資源を使います。主張のたびに完全なコマンドを新しく走らせる指定なので、テストが遅いプロジェクトでは待ち時間が積み上がります。
回帰テストの確認では修正を一時的に戻す
言い方まで縛られる
言い方まで縛られます。「完璧！」のような満足の表明も止まる兆候に入っています。報告が淡々とした形になります。
証拠があることと正しいことは別
証拠があることと正しいことは別です。テストが通っても、テストが間違っている可能性は残ります。このスキルが保証するのは主張と出力が一致していることだけです。
ライセンス
ライセンス: MIT。再配布や商用利用の前に公開元の表記を確認してください。
インストール数の推移
日次で記録9月18日 〜 11月7日（49日分）
インストール数と 1 日あたりの増加は Skillselion が に集計した値です。上流の更新は数日おきなので、前日比ではありません。GitHub star と最終更新は に GitHub から取得しました。
併用すると強いスキル
よくある質問
前に通ったのでは駄目ですか
駄目です。「このメッセージの中で検証のコマンドを走らせていないなら、通ると主張することはできない」と明記されています。
緑の結果は、それが走った木についてしか証明しません。
静的解析が通れば十分ではないですか
足りません。表に「静的解析が通ったこと」はビルドの証拠として不十分だと明記されています。別表にも「静的解析はコンパイラではない」とあります。
サブエージェントの報告は信じられますか
独立に検証する指定です。「エージェントが完了した」の証拠は差分に変更が出ていることで、報告そのものではありません。
回帰テストはどう確かめますか
修正を一度戻して、テストが落ちることを確かめます。書いて通っただけでは、そのテストが何を見張っているか分かりません。
赤→緑の輪を 1 周させる手順が本文にあります。
報告が固くなりませんか
なります。「完璧！」のような満足の表明も止まる兆候です。主張のたびにコマンドと出力が並ぶ形になります。
読みにくいと感じたら、依頼文で報告の形を指定してください。
対応しているエージェントはどれですか
Claude Code と Codex です。公開元は群の入口（using-superpowers）に実行環境ごとの補足ファイルを置き、writing-skills では Claude Code・Codex・Copilot CLI・Gemini CLI の置き場所まで書き分けています。
当サイトは公開元が明記しているものだけを表示しています（指標の意味と限界）。