maintain-verification-skill

検証スキルを保守する

機能マップは、アプリが変更された瞬間から古くなり始めます。このスキルは、create-verification-skill スキル（または機能マップを備えたプロジェクト固有の検証スキル）によって生成されたスキルを維持するためのループです。厳密さの単位は個々の文ではなく機能です。つまり、ソースからすべての機能ファイルを網羅し、すべての機能を実際に動かして検証します。ただし、箇条書きのすべてをターミナルで実行する必要はありません。

成果

いずれかを選び、どれを選んだか明記してください。

• clean — すべての機能についてソースと実動作を検証済みで、反映すべき内容はありません。ブランチも PR も作成しません。
• changed — 検証済みのドキュメント、ハーネス、またはマップの修正を含む PR を 1 件作成します。
• blocked — 検証を完了できなかったか、検証済みの修正を安全に反映できませんでした。妨げとなった内容を正確に説明してください。

編集範囲

検証スキルのディレクトリ内（その SKILL.md、features/、およびスキルが所有するハーネススクリプト）のみを編集してください。実行中に製品コードを編集してはいけません。マップに記載された動作をアプリがしなくなっている場合は、ドキュメントの不整合としてマップを修正するか、製品のリグレッションとして報告してください。ドキュメントでごまかしてはいけません。

パス

0. 対象を特定します。 保守する検証スキルを見つけます。対象は、本文に起動と操作のセクション、および機能マップを含むプロジェクトローカルのスキルです（通常は .agents/skills/verify-*/）。候補が複数ある場合は、どれを対象にするか確認します。候補がない場合は、対象を勝手に作らず、停止して代わりに /create-verification-skill を案内します。

1. インデックスを整備します。 機能マップの README を読み、同じ階層のファイルを glob で列挙します。欠落、余分、重複、または無効な項目を修正します。軽量に行い、生成した一覧は作成しません。

2. ソースの確認を並行して行います。 機能ファイルごとに読み取り専用のサブエージェントを 1 つ割り当て、同時に起動します。それぞれがソースから「このユーザー向け機能はどのように動作するか」を説明し、ドキュメントとの食い違いの可能性を引用付きで指摘して、簡潔なライブ検証手順を 1 つ返します。子エージェントはアプリを操作せず、ファイルも編集しません。返答の形式：機能の要約／ソースのエントリーポイント／食い違いの可能性、または「なし」／検証手順 1 つ。

3. 照合します。 すべての機能ファイルについて、要約が返ってきていることを確認します。重複する検証手順を、実用上可能な限り少ないアプリの状態にまとめます。引用された食い違いの可能性を抜き取り確認します。問題がないとされる主張を再検証する必要はありません。最近の変更を調べ、機能マップに載っていないユーザー向けの画面や機能がないか確認します。マップからの欠落と判断するには、具体的なソースパスが必要です。

4. ライブ検証を行います。 ソースに問題がなさそうな場合でも必須です。操作はすべて調整役が担当します。検証スキル独自の起動方式に従います。サーバーや UI では 1 つのインスタンスを長時間起動して順次操作し、短時間で終了する CLI では操作ごとに新しい独立セッションを使います。どちらを使うかはこの手順ではなく、スキルの「起動」セクションに従って決めます。すべての機能を少なくとも 1 回検証し、失敗の有無にかかわらず、検証中は次の 3 つの不変条件を守ります。（1）予期しない動作が起きた後にヘルスチェックをしていないインスタンスを操作しないこと。最初の操作の前に doctor を実行し、セッション単位で運用する場合は新しいセッションごとに doctor を実行します。操作に失敗した後も doctor を実行します。doctor で検出できない失敗（プロセスは正常でも UI が応答しなくなるなど）が起きた場合は、期待どおりに戻ることを願うのではなく、既知の状態にリセットするか再起動します。（2）これまでに取得した証拠は、クリーンアップのたびに残っていることを、想定するのではなく指定された場所で確認すること。（3）操作のために開始したものは、その操作で不要になった時点で残さずクリーンアップすること。失敗した試行の残留物は、セッションが停止している場合、終了した場合、共有されている場合のいずれもクリーンアップします（共有インスタンスの場合は残留物を掃除し、インスタンス自体は終了しません）。スキルの不整合が原因で doctor が失敗した場合は、その不整合をスキルの編集範囲内で修正し、1 回だけ再試行します。修正によって無効になったものだけを再起動し、それ以上は再起動しません。それでも失敗する場合は、検証を blocked とします。機能に到達できない場合は、具体的な前提条件（認証、権限、OS、外部状態）と試した経路が明示されている場合に限り、verified-unreachable とします。その前提条件がマップに記載されていない場合は、ドキュメントの不整合です。トリアージ中に修正したハーネスは、出荷前にライブで再検証します。最終的な終了処理は、その実行の最後の操作（再検証も含む）が終わった後に行い、実行終了後まで残るものがないようにします（証拠はスキルに従って保持します）。

5. トリアージします。 ユーザー視点の説明が誤っている、または不足している場合は、ドキュメントの不整合として修正します。動作しているのにハーネスで操作できない場合は、ハーネスの不足として修正します。ハーネスを修正する場合、生成時と同じヘルパーのルールに従います（スクリプトに実行権限を付与し、呼び出し方法をスキル本文に記載します）。アプリの動作そのものが壊れている場合は、製品の問題です。ユーザー向けに記録し、この PR には含めません。

6. 提出するか、停止します。 変更がある場合は、実証済みの修正を 1 つの PR にまとめます。変更したファイルはすべて、提出前に読み直します。問題がない場合、またはブロックされた場合は、PR を作成せず、結果と検証範囲を正確に報告します。

確認した機能、到達できなかった機能の前提条件、確認済みの不整合、結果を簡潔な実行メモとして一時的な場所に記録します。コミットには含めません。