maintain-verification-skill

検証スキルの保守

機能マップは、アプリに変更が加わるとすぐに古くなります。このスキルは、/create-verification-skill で生成されたスキル（または機能マップを含むプロジェクト固有の検証スキル）を保守するためのループです。厳密さの単位は機能であり、文の一つひとつではありません。ソースからすべての機能ファイルを網羅し、すべての機能を実際に検証します。ただし、箇条書きのすべてをターミナルで実行する必要はありません。

プラットフォームに関する注意。 Codex や Claude 以外のランタイムでは、以下の機能ごとの並列ソースリーダーは spawn_agent によるファンアウトに対応します。また、プロジェクト固有のスキルは .claude/skills/ ではなく、使用しているランタイムのスキル保存場所にあります。詳しくは codex-tools.md を参照してください。

成果

次のいずれかを選び、どれを選んだかを明記します。

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

編集範囲

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

パス

0. 対象を特定します。 維持する検証スキルを探します。対象は、本文に起動／操作のセクションと機能マップがあるプロジェクトローカルのスキルです（通常は .claude/skills/verify-*/）。候補が複数ある場合はどれかを尋ねます。候補がない場合は、対象を勝手に作らず、そこで止めて /create-verification-skill を案内します。

1. インデックスの整合性を保ちます。 機能マップの README を読み、同じ階層にあるファイルを glob で列挙します。欠落、余分、重複、または参照先が存在しないエントリーを修正します。軽量に行い、生成された一覧は作りません。

2. ソース調査の並行実行。 機能ファイルごとに読み取り専用のサブエージェントを1つ割り当て、同時に起動します。それぞれがソースから「このユーザー向け機能はどのように動作するか」を説明し、引用箇所を示しながら、ドキュメントとの食い違いが疑われる点を指摘し、実際の検証用レシピを1つ簡潔に返します。子エージェントはアプリを操作せず、ファイルも編集しません。返す形式：機能の概要／ソースの主要箇所／食い違いの疑い、または該当なし／レシピ1つ。

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

4. 実機検証を行います。 ソースに問題がなさそうな場合でも必須です。操作はすべてコーディネーターが担当します。検証スキル独自の起動方法に従います。サーバーや UI では1つのインスタンスを長時間維持して順次操作し、短時間で終了する CLI では操作ごとに新しい分離セッションを使用します（どの方法にするかはこのスキルではなく、スキルの Launch セクションで決まります）。すべての機能を少なくとも1回は試し、失敗の種類にかかわらず、検証全体を通じて次の3つの不変条件を守ります：（1）予期しない動作をした後にヘルスチェックしていないインスタンスは操作しません。最初の操作の前に doctor を実行し、セッション単位の場合は新しいセッションごとに doctor を実行し、操作が失敗した後にも doctor を再実行します。正常なプロセスでも doctor では検知できない失敗（UI のフリーズなど）が起きた場合は、期待せずに既知の状態へリセットするか、再起動します。（2）それまでに取得したエビデンスは、クリーンアップのたびに保持されていることを、想定せずに指定された場所で確認します。（3）操作によって開始したものが、その操作で不要になった後も残らないようにします。失敗した試行の残留物は、セッションが停止中、終了済み、共有中のいずれであってもクリーンアップします（共有インスタンスではインスタンス自体ではなく、残留物をクリーンアップします）。スキルのドリフトが原因で doctor が失敗した場合はドリフトとして扱い、編集範囲内で修正してから1回だけ再試行します。修正によって無効になったものだけを再起動し、それ以上は再起動しません。そのうえで検証パスを blocked とします。機能に到達できない場合、具体的な前提条件（認証、利用資格、OS、外部状態）と試した手順を示した場合に限り、verified-unreachable として記録できます。その前提条件がマップに記載されていない場合はドリフトです。トリアージでハーネスを修正した場合は、出荷前に実機で再検証します。最終的な終了処理は、この実行の最後の操作（再検証を含む）が終わってから行い、スキルに従ってエビデンスを保持しつつ、実行中に開始したものが何も残らないようにします。

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

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

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