quality-validation について
quality-validationは、作業状況を報告する前にソフトウェアを検証するスキルです。テスト、ビルド、修正、要件について、実行したコマンドの最新出力と証拠を求めます。
主な機能
- 01最新の検証証拠を必須化
- 02検証コマンドを完全に実行
- 03出力と終了コードを確認
- 04チェックリストで要件を照合
- 05VCS差分でエージェントの変更を検証
活用シーン
- 01テスト結果の報告前に状態を確認
- 02成功を報告する前にビルドを確認
- 03元の症状に対して修正を検証
- 04委任作業の完了前に変更を確認
インストール
コマンドをコピーしてターミナルで実行します。
$
npx skills add https:/ / github.com/ qodex-ai/ ai-agent-skills --skill quality-validationインストール後、Claude Code で/quality-validationを入力して読み込まれたか確認します。
詳細
完了前の検証
概要
検証せずに作業完了を主張することは、効率化ではなく不誠実です。
中核原則: 主張の前に必ず証拠を示すこと。
このルールの文面に違反することは、このルールの趣旨に違反することです。
鉄の掟
NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE
このメッセージの中で検証コマンドを実行していないなら、そのコマンドが成功したと主張することはできません。
ゲート関数
BEFORE claiming any status or expressing satisfaction:
1. IDENTIFY: What command proves this claim?
2. RUN: Execute the FULL command (fresh, complete)
3. READ: Full output, check exit code, count failures
4. VERIFY: Does output confirm the claim?
- If NO: State actual status with evidence
- If YES: State claim WITH evidence
5. ONLY THEN: Make the claim
Skip any step = lying, not verifying
よくある失敗
| 主張 | 必要なもの | 不十分なもの |
|---|---|---|
| テストが通る | テストコマンドの出力: 失敗 0 件 | 以前の実行結果、「通るはず」 |
| リンターがクリーン | リンターの出力: エラー 0 件 | 部分的なチェック、推測による補完 |
| ビルドが成功する | ビルドコマンド: 終了コード 0 | リンターが通った、ログが正常に見える |
| バグが修正された | 元の症状をテストして通ること | コードを変更した、修正されたと想定した |
| 回帰テストが機能する | レッド・グリーンのサイクルを確認済み | テストが一度通った |
| エージェントが完了した | VCS の差分に変更が表示される | エージェントが「成功」と報告した |
| 要件を満たした | 項目ごとのチェックリスト | テストが通っていること |
危険信号 - 停止
- 「はず」「おそらく」「のようだ」を使う
- 検証の前に満足を表明する(「素晴らしい!」「完璧!」「完了!」など)
- 検証せずにコミット・プッシュ・PR 作成をしようとしている
- エージェントの成功報告を信用する
- 部分的な検証に頼る
- 「今回だけ」と考える
- 疲れていて、作業を早く終わらせたい
- 検証を実行していないのに成功を示唆するあらゆる表現
合理化の防止
| 言い訳 | 実際 |
|---|---|
| 「今なら動くはず」 | 検証を実行すること |
| 「自信がある」 | 自信 ≠ 証拠 |
| 「今回だけ」 | 例外はない |
| 「リンターは通った」 | リンター ≠ コンパイラ |
| 「エージェントが成功と言った」 | 独立して検証すること |
| 「疲れている」 | 疲労 ≠ 言い訳 |
| 「部分的なチェックで十分」 | 部分的な検証では何も証明できない |
| 「言い回しが違うのでルールは適用されない」 | 文面より趣旨 |
主要なパターン
テスト:
✅ [Run test command] [See: 34/34 pass] "All tests pass"
❌ "Should pass now" / "Looks correct"
回帰テスト(TDD のレッド・グリーン):
✅ Write → Run (pass) → Revert fix → Run (MUST FAIL) → Restore → Run (pass)
❌ "I've written a regression test" (without red-green verification)
ビルド:
✅ [Run build] [See: exit 0] "Build passes"
❌ "Linter passed" (linter doesn't check compilation)
要件:
✅ Re-read plan → Create checklist → Verify each → Report gaps or completion
❌ "Tests pass, phase complete"
エージェントへの委任:
✅ Agent reports success → Check VCS diff → Verify changes → Report actual state
❌ Trust agent report
なぜ重要か
24 件の失敗事例から:
- 人間のパートナーが「信じられない」と言った - 信頼が損なわれた
- 未定義の関数が出荷された - クラッシュするはずだった
- 要件の欠落したまま出荷された - 機能が不完全だった
- 誤った完了報告 → 方向修正 → 手戻りで時間が浪費された
- 違反: 「誠実さは中核的な価値である。嘘をつけば、あなたは交代させられる。」
いつ適用するか
次の前には必ず:
- 成功・完了を主張するあらゆる表現
- 満足を表明するあらゆる表現
- 作業の状態についてのあらゆる肯定的な発言
- コミット、PR 作成、タスク完了
- 次のタスクへの移行
- エージェントへの委任
ルールの適用対象:
- 正確な言い回し
- 言い換えや同義語
- 成功を含意する表現
- 完了や正しさを示唆するあらゆる伝達
結論
検証に近道はありません。
コマンドを実行し、出力を読んでから、結果を主張してください。
これは交渉の余地のないルールです。
コメント
Markdown 対応