verify

検証

作業が完了したように見えても、その証拠が必要な場合にこのスキルを使用します。

目的は、完了を祝うことではありません。証拠に基づいて変更を受け入れられるかどうかを判断することです。

このスキルは、完了をどのように判断するかを定める唯一の情報源です。次の2つの方法で使用します。

• implement の完了ゲートとして使用します。implement による構築が終わると、独立した検証担当がこのスキルに従って受け入れ基準を判断します。
• implement の後に、ユーザーが追加の確証、ランタイム QA、または差分に対する独立した完了監査を求める場合、単独の検証として使用します。

どちらの場合も、目的とルールは同じです。証拠から判断し、修正は行いません。

このスキルで行うこと

verify は次の4つの質問に答えます。

1. 何が変更されましたか？
2. 何が壊れた可能性がありますか？
3. 実際に何を確認しましたか？
4. どのようなリスクが残っていますか？

このスキルの使用中は、コード、コンテンツ、設定を変更しないでください。verify は読み取り専用です。証拠と判定を報告し、見つかった問題を修正するものではありません。検証でバグが見つかった場合は、ファイル、行、失敗するケースを具体的に説明し、修正のために implement またはユーザーに引き渡してください。

検証レベル

実際のリスクをカバーできる最小限のレベルを使ってください。必要な場合にのみ、より広い範囲に進みます。

レベル1．静的チェック

変更によって構文、型、リンタールール、コンテンツの解析、またはビルドに問題が生じる可能性がある場合に使用します。

例：

• npm run lint
• npm run typecheck
• npm test
• npm run build
• verify:content など、プロジェクト固有のバリデーター

レベル2．動作チェック

人の主観だけに頼らず、テストまたは調査で期待される動作を確認できる場合に使用します。

例：

• 純粋なロジックの単体テスト
• データ読み込みや API 動作の統合テスト
• スモークスクリプト
• 移行またはシードの検証
• 生成された出力ファイルの確認

レベル3．ランタイム QA

結果が実際のアプリ、ブラウザー、API、データベース、ログ、または外部サービスの設定に左右される場合に使用します。

例：

• ローカルまたはデプロイ済みのルートを開く
• 変更したフローをクリックする
• 表示テキストと状態を確認する
• コンソールまたはネットワークのエラーを調べる
• API エンドポイントを呼び出す
• データベースの行数または件数を確認する
• スクリーンショット、DOM、ログ、またはコマンドの証拠を取得する

ブラウザー QA には playwright-cli を使用してください。インストールされていない場合は、先にインストールするか（https://github.com/microsoft/playwright-cli を参照）、プロジェクトで設定されているブラウザーツールを使用してください。

レベル 4．敵対的なサブエージェントレビュー

変更を生み出したのと同じコンテキストでは、その変更を信頼して評価できない場合に使用します。変更が大規模である場合や、自信満々の誤った「合格」のリスクが高い場合が該当します。目的は、自己検証バイアスを打ち破ることです。変更を書いておらず、その前提も共有していない新しいエージェントのほうが、だまされにくくなります。

次のいずれかに当てはまる場合に限り、レベル 4 を実施してください。

• 差分が大きい、または多くのファイルにまたがっている（大まかな目安：5 ファイル以上、または変更行数が 200 行以上）
• 変更がセキュリティ、認証、金銭、データ移行、または破壊的な操作に関わる
• レベル 1～3 は合格したものの、結果がまだ不安定に感じられる、または単一の判断が大きな意味を持つ
• ユーザーが、深いレビュー、独立したレビュー、または敵対的なレビューを明示的に求めている

小規模でリスクの低い変更（一行の修正、文言の微調整、lint の整理）では、レベル 4 を実施しないでください。些細な差分に懐疑派の評議会を招集するのは無駄です。

実施方法：

1. これから「合格」と判断する対象を、それぞれ明確な主張として定義します。例：「新しい認証ガードは期限切れのトークンを拒否する」「このマイグレーションは元に戻せる」。
2. 重要度の高い主張ごとに、Task ツールで独立した懐疑派サブエージェントを起動します。各エージェントに主張、関連するファイルや差分、すでに収集した証拠を渡し、主張を確認するのではなく、反証するよう指示します。別々の主張を検証する懐疑派は並行して実行します（1 回のメッセージで複数の Task 呼び出しを行います）。
3. 各懐疑派は、refuted または not_refuted と具体的な理由を返します。反証として認められるのは、具体的な失敗ケース、ファイル、行、または再現手順を示している場合だけです。具体例のない「リスクがあるかもしれない」は反証に数えません。
4. 多数決で判断します。主張ごとに奇数の懐疑派（1 人または 3 人）を起動し、具体的な反例が見つからず、過半数が not_refuted を返した場合に限り、その主張を維持します。具体的かつ再現可能な反証があれば、票数にかかわらず、その主張は不合格となります。

サブエージェントにも以下の証拠ルールが適用されます。懐疑派には、実際に実証した反証だけを報告し（ケースを実行した、該当行を読んだなど）、想像で述べた反証は決して報告しないよう伝えてください。サブエージェントの未検証の主張は、あなた自身の主張と同様に証拠にはなりません。

懐疑的な検証が延々と続かないようにしてください。具体的な反例がない場合、既定の判定は not_refuted とするよう懐疑派に指示します。目的は、曖昧な疑いを理由に承認を保留することではなく、実際の問題を見つけることです。

ワークフロー

1. git status --short を実行し、変更されたファイルを特定します。
2. 関連する差分またはファイルを読みます。記憶に頼らないでください。
3. 意図する動作を 1～2 文で述べます。
4. 変更によって生じる主なリスクを列挙します。
5. リスクをカバーするレベル 1、2、3 のチェックを選びます。
6. チェックを実行します。まず対象を絞ったチェックを優先してください。
7. チェックが失敗した場合、その失敗が今回の変更によるものか、既存の問題か、無関係なものかを判断します。
8. UI またはランタイムに変更がある場合は、実際のルートまたはランタイムの対象を調べます。
9. 変更が大規模、または重要度が高い場合（レベル 4 の条件を参照）、判断を確定する前に、重要な主張について敵対的な懐疑派サブエージェントを起動します。
10. 実際に収集した証拠だけを報告します。
11. 未確認の事項を明記します。

証拠ルール

• コマンドは、実際に実行された場合にのみ証拠となります。
• ブラウザチェックは、ルート、状態、観察した結果を明示した場合にのみ証拠となります。
• データベースチェックは、対象環境とクエリ・結果を明示した場合にのみ証拠となります。
• スクリーンショットは、パスまたはキャプチャした画面を明示した場合にのみ証拠となります。
• 「問題なさそう」は、それだけでは証拠になりません。
• 省略したチェックを隠さないでください。実施しなかった理由を説明してください。

エラー処理

チェックに失敗した場合：

• 重要なエラー行を引用するか、要約してください
• 現在の変更に関連しているように見えるかどうかを伝えてください
• 関連していない場合は、対象範囲外であることを示すファイルまたはコマンドを挙げてください
• 関連している場合は、失敗したファイル／行／ケースを示して Fail として報告してください。implement またはユーザーが修正できるようにし、ここでは修正しないでください
• ブロックされている場合は、停止してブロッカーを明確に報告してください

より範囲の狭い失敗で問題を説明できている場合、広範なチェックを繰り返し実行しないでください。

判定ルール

判定は、完了したように見えるかではなく、実際にチェックした内容を反映する必要があります。

• すべての受け入れ基準について、そのリスクに応じたレベルの確かな証拠がある場合にのみ Pass としてください。ランタイム、ブラウザー、API、またはデータベースの動作に依存する基準は、コードが正しく見えるだけでは満たされず、その動作を実際に試した場合にのみ満たされます。
• 基準が未チェックのまま、またはコードを読むことでしか確認できない場合、判定は最大でも Partial です。実際の前提条件（認証済みセッションや認証情報の不足など）によって実行できなかった場合は Blocked としてください。
• 未チェックの基準を Pass に含めないでください。Not Checked の項目や、スキップしたランタイム基準がある場合、判定は Pass 未満となります。判定を切り上げず、未チェックの項目を明示してください。

出力形式

## Verdict

Pass | Partial | Fail | Blocked

## Checked

- ...

## Evidence

- Command:
- Result:
- Runtime:
- Result:

## Adversarial Review

(Include only when Level 4 ran. Omit otherwise.)

- Claim:
- Skeptics: N run, M refuted
- Outcome: held | broken (with the concrete counterexample)

## Failed Or Blocked

- ...

## Not Checked

- ...

## Remaining Risk

- ...