maintain-verification-skill

検証スキルを保守する

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

結果

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

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

編集範囲

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

パス

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

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

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

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

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

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

6. 出荷または停止。 変更がある場合：検証済みの修正を1つの PR にまとめます。先に、変更したすべてのファイルを読み直します。変更がない場合、またはブロックされた場合：PR は作成せず、結果とカバレッジを正直に報告します。

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