検証スキルの保守

アプリが変わった時点で、機能一覧は古くなり始める。このスキルは、/create-verification-skillで作った検証スキル（または機能一覧を持つプロジェクト専用の検証スキル）を保つための点検である。厳密さの単位は機能で、文ごとではない。すべての機能ファイルをソースで確かめ、すべての機能を実際に動かすが、箇条書きを1つずつ端末で確かめることまではしない。

結果

次のどれかを選び、どれかを明言する。

• clean: すべての機能をソースと実操作で確かめ、直すべきものがなかった。ブランチもPRも作らない。
• changed: 証明できた文書、操作手段、機能一覧の修正がある。
• blocked: 確認が終わらなかった、または証明できた修正を安全に反映できなかった。何に阻まれたかを正確に書く。

編集してよい範囲

検証スキル自身のディレクトリ（SKILL.md、features/、スキルが持つ補助スクリプト）だけを編集する。製品コードは編集しない。一覧に書いてある振る舞いをアプリがもうしていないなら、文書のずれ（一覧を直す）か、製品の退行（報告し、文書でごまかさない）のどちらかである。

手順

0. 対象を特定する。 起動と操作の節と機能一覧を持つプロジェクト専用のスキル（通常は.claude/skills/verify-*/）を探す。候補が複数あればどれかを聞く。なければ止まり、対象をでっち上げずに/create-verification-skillを案内する。

1. 索引の整理。 機能一覧のREADMEを読み、同じディレクトリのファイルと照合する。抜け、余分、重複、リンク切れを直す。軽い作業にとどめ、一覧を自動生成しない。

2. ソースの確認。 機能ファイルごとに、その機能がソース上でどう動くかを読み、ずれていそうな記述を出典付きで挙げ、実操作での確認手順を1つ書き出す。この段階ではアプリを操作せず、ファイルも編集しない。自分で順に読む。ユーザーがサブエージェントの利用を明示した場合は、機能ごとに読み取り専用のサブエージェントを並列に起動し、各自に「機能の要約、ソースの入口、ずれの候補（なければなし）、確認手順1つ」を返させる。

3. 突き合わせ。 すべての機能ファイルに要約があることを確かめる。重なる確認手順は、なるべく少ないアプリの状態にまとめる。指摘されたずれは抜き取りで確かめ、問題なしとされたものを証明し直すことはしない。最近の変更から、一覧にない利用者向けの機能を探す。一覧にないと言うには、具体的なソースのパスが要る。

4. 実操作。 ソースに問題がなさそうでも必ず行う。操作はすべて自分が行う。起動のやり方は検証スキルの起動の節に従う（サーバーやUIなら長く動かす1つのインスタンスを順に操作し、短時間のCLIなら操作ごとに分離したセッションを使う）。すべての機能を1回以上動かし、何が起きても次の3つを守る。

   1. 予想外のことが起きたあとに診断していないインスタンスは操作しない。最初の操作の前、セッションが単位なら新しいセッションごと、操作が失敗するたびに診断する。診断で見えない失敗（プロセスは健全だがUIが固まっている）なら、望みをかけずに既知の状態へ戻すか、起動し直す。
   2. それまでに取った証拠は、どの片付けのあとにも、指定の場所に残っていることを実際に確かめる。
   3. 操作で起動したものを、役目が終わったあとに残さない。セッションが固まっても、終了しても、共有されていても、失敗した回の残骸は片付ける。共有のインスタンスなら、インスタンスではなく残骸を片付ける。

   スキルのずれが原因で診断が失敗したら、それはずれである。編集してよい範囲で直して1回だけやり直す（直したことで無効になったものだけを起動し直す）。それでもだめならblockedとする。たどり着けない機能は、具体的な前提（認証、権限、OS、外部の状態）と試した経路を書いた場合だけ「到達不能を確認」とする。一覧にその前提が書かれていなければ、それもずれである。手順5の振り分けで直した操作手段は、反映する前に実操作で確かめ直す。最後の片付けは、その確かめ直しを含む最後の操作のあとに行い、証拠を残して他は何も残さない。

5. 振り分け。 利用者視点の説明が間違っている・欠けている → 文書のずれとして直す。動いている振る舞いを操作手段で動かせない → 操作手段の不足として直す（補助スクリプトは実行権限を付け、呼び出し方をスキル本文に書く）。アプリの振る舞いが実際に壊れている → 製品の不具合としてユーザーに報告し、今回の修正には含めない。

6. 反映するか止める。 changedなら、変更したファイルをすべて読み直してから差分を示す。ブランチ作成とコミットはCLAUDE.mdのGitの規則に従い、承認されたらPRを1つにまとめる。cleanやblockedなら、結果と確認範囲をそのまま報告する。

実行の記録（確認した機能、到達できなかった前提、確認したずれ、結果）は.tmp/に短く残し、コミットしない。