agent-verify は何をしますか？
構築したものを、それを偽造できる最も安価なメカニズムで検証可能にしなさい。デフォルトでCLI経由で検証する。モデルは約20トークン（PASS / FAIL: line）を読むべきであり、DOMダンプやスクリーンショットを決して読んではいけない。
唯一のルール
機能が間違っていることを証明できる、最も軽量なメカニズムを使いなさい。それができない場合にのみ、より重い手段にエスカレーションする。
インプロセスアサート → CLI / curl + exit code → DBテスト（TAP） → ヘッドレスブラウザ（視覚のみ、最後の手段）
最も安価 最も高価
エージェントが構築するものの90%（ロジック、データ、API契約、フロー）はブラウザなしで検証可能です。ブラウザはピクセル用に取っておきましょう。
ループ（機能ごと）
- 一度検出する。
scripts/detect-stack.shを実行する。テスタランナーとスタックを数行で表示する。新しいフレームワークを押し付けない — 既存のものを使う。 - 機能を構築する。
- スタックのインプロセス / CLIプリミティブを使って、1つのトークン最小限のチェックを書く（
reference/stacks/を参照）。チェックはPASSまたは単一のFAIL:行を出力しなければならない — ダンプは絶対にしない。 VERIFICATION_MAP.mdに1行追加する：feature | command | pass-signal。これが次回エージェントが読み取る契約である。scripts/verify.sh [feature]を実行し、結果だけを読む。 編集 → 検証 → 結果に基づいて繰り返す。ログには基づかない。
やってはいけないこと
- ロジック、データ、APIレスポンスをチェックするためにPlaywrightやブラウザに手を出してはいけない。これこそが、このスキルが止めようとしているトークン漏れである。
- TDDの儀式を規定してはいけない。手順ではなく、どのチェックがこの機能を証明するかを表面化しなさい。（手順だけをターゲットコンテキストなしで行うと、測定可能な形で逆効果になる —
reference/patterns.mdを参照。） - 生の出力をコンテキストに返してはいけない。サンドボックス内でフィルタリングし、結果だけを表面化しなさい。（
console.log(result)であって、1万行のデータではない。） - チェックを増やしてはいけない。1機能につき、1つの高速で決定論的なチェック。
VERIFICATION_MAP.mdは短く保つ — 短いマップは長いマップよりも性能が良い。
出力契約（常に）
PASS auth-login
FAIL create-invoice: expected 201, got 500
終了コード 0 = すべて合格。非ゼロ = 何かが失敗した。モデルに必要なのはこれだけである。
ブラウザが避けられない場合
純粋に視覚的なUI（レイアウト、スタイリング、ビジュアルリグレッション）の場合に限り、そして最後の手段としてのみ。その場合でも、1回のヘッドレス実行で、PASS/FAILまたは差分判定を返す — 完全なスクリーンショットやDOMをコンテキストに決して入れない。reference/stacks/nextjs.md を参照。
ファイル
scripts/detect-stack.sh— スタックとランナーを表示する、トークン最小限。scripts/verify.sh— マッピングされたチェックを実行し、PASS/FAILと失敗行のみを出力する。VERIFICATION_MAP.md— 短い機能→コマンドマップ（エージェントが管理する）。reference/stacks/— コピペ用レシピ：FastAPI（インプロセスTestClient）、Supabase（シード＋リセット＋pgTAP）、Next.js（ルートハンドラー＋最終手段のビジュアル）。reference/patterns.md— トークン最小限の検証パターンとその根拠となるエビデンス。reference/anti-patterns.md— フレーキーテスト、誤ったPASS、過剰エンジニアリングガード。templates/— マップ、FastAPIテスト、Supabaseシードの出発点。