maintain-verification-skill

検証スキルを保守する

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

結果

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

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

編集範囲

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

実施手順

0. 対象を特定します。 保守する検証スキルを探します。対象は、本文に起動／操作のセクションと機能マップがあるプロジェクトローカルのスキルです（通常は .cursor/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 を作成せず、結果と検証範囲を正直に報告します。

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