maintain-verification-skill

検証スキルを保守する

Codex では、このスキルに従う前に、スキルごとの注記を含めてプラットフォームマッピングを読んでください。

GitHub Copilot では、このスキルに従う前に、スキルごとの注記を含めてプラットフォームマッピングを読んでください。

Muse では、このスキルに従う前に、スキルごとの注記を含めてプラットフォームマッピングを読んでください。

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

成果

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

• clean — すべての機能をソースと実動作の両面から確認し、反映すべき変更はありません。ブランチも PR も作成しません。
• changed — 根拠が確認されたドキュメント、ハーネス、またはマップの修正を 1 つの PR で反映します。
• blocked — 検証を完了できなかった、または根拠が確認された修正を安全に反映できませんでした。何が妨げになったのかを具体的に説明してください。

編集範囲

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

パス

0. 対象を特定します。 維持する検証スキルを探します。対象は、本文に起動／操作のセクションと機能マップがある、プロジェクトローカルのスキルです（.claude/skills/verify/、または古いジェネレーターによる .claude/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 が失敗した場合は、ずれとして扱います。編集対象の範囲内で修正し、修正によって無効になったものだけを再起動してから、もう一度だけ試します。それでも失敗した場合に blocked と判定します。機能に到達できない場合、具体的な前提条件（認証、利用資格、OS、外部状態）と試した経路が示されている場合に限り verified-unreachable とします。マップにその前提条件が記載されていなければ、ずれです。トリアージでハーネスを修正した場合は、リリース前に必ずライブで再検証します。最終クリーンアップは、再検証を含む実行の最後の操作が終わってから行い、スキルの規定どおりエビデンスは保持したまま、その実行で開始したものが残らないようにします。

5. トリアージします。 ユーザー視点の説明が誤っている、または不足している場合はドキュメントのずれとして修正します。動作する機能をハーネスで操作できない場合はハーネスの不足として修正します。ハーネスの修正には、生成時と同じヘルパーのルールを適用します（スクリプトに実行権限を付与し、呼び出し方法をスキル本文に記載します）。アプリの動作自体に問題がある場合は製品の問題です。ユーザーへの報告に記録し、この PR の対象からは除外します。

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

カバーした機能、到達不能の前提条件、確認済みのずれ、結果について、簡潔な実行メモを一時的な場所に残します。コミットはしません。