maintain-verification-skill

検証スキルを保守する

太字またはバッククォートで示されているスキル名、あるいは /<name> として実行されるスキルは、このスキルのディレクトリと同じ階層にある ../<name>/SKILL.md ファイルです。接頭辞なしで示されている原則名は ../principle-<name>/SKILL.md です。そのファイルを読み、従ってください。ほとんどの pstack スキルはユーザー専用であるため、スキルツールから読み込むことはできません。すべての delegate_task 呼び出しでは、../poteto-mode/SKILL.md の Subagents セクションにあるデフォルト設定に従ってください。

機能マップは、アプリが変更された瞬間に古くなります。このスキルは、/create-verification-skill で生成されたスキル（または機能マップを持つプロジェクトローカルの検証スキル）を維持するための作業ループです。厳密さの単位は機能であり、文章の一つ一つではありません。すべての機能ファイルをソースに基づいて確認し、すべての機能を実際に操作して検証しますが、箇条書きの一つ一つを端末で検証する必要はありません。

成果

次のいずれかを選び、どれを選んだか述べてください。

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

編集範囲

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

手順

0. 対象を特定します。 保守する検証スキルを探します。対象は、起動／操作のセクションと機能マップを含むプロジェクトローカルのスキル（通常は verify-*/）です。.agents/skills/、.claude/skills/、~/.agents/skills/、~/.claude/skills/ を確認し、同じ実パスに解決されるエントリは一つとして数えます。候補が複数ある場合は、どれを対象にするか尋ねます。候補がない場合は、対象を勝手に作らず /create-verification-skill を案内して終了します。

1. インデックスを整えます。 機能マップの README を読み、同階層のファイルを glob で列挙します。欠落、余分な項目、重複、参照切れを修正します。軽微な作業にとどめ、生成されたインベントリは作成しません。

2. ソース確認を行います。 機能ファイルごとに子タスクを一つ作成し、mode: "async" で同時に起動します。title には機能名を含め、各機能の子タスクには波の中での再試行時にも同じ値を使う clientRequestId を一つ割り当て、target は指定しません。これにより親モデル上で実行されます。子タスクに渡すのは簡潔な依頼のみとし、その中に機能ファイルの絶対パス、「read-only: inspect only, no writes, no git commands」、以下の返却形式、「Do not delegate」を記載します。各子タスクはソースから「このユーザー向け機能はどのように動作するか」を説明し、引用箇所を示してドキュメントの乖離の可能性を指摘し、簡潔な実操作による検証手順を一つ返します。子タスクはアプリを操作せず、ファイルも編集しません。返却形式は「機能の概要 / ソースのエントリーポイント / 乖離の可能性またはなし / 検証手順一つ」です。ターンを終了し、完了通知が届くまで待ちます。

3. 結果を照合します。 すべての機能ファイルについて概要が返ってきていることを確認します。検証手順が重複している場合は、実用上可能な限り少ないアプリ状態にまとめます。引用された乖離はスポットチェックします。問題がないとされた主張を再検証する必要はありません。直近の変更を確認し、機能マップにないユーザー向け画面や機能がないか調べます。マップに欠落があると判断するには、具体的なソースパスを必ず確認してください。

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

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

6. 出荷するか、停止する。 変更がある場合は、検証済みの修正を 1 つの PR にまとめ、変更したファイルをすべて再読してから、gh pr create で PR を作成し、直ちにその URL を link_pull_request で登録してください。クリーンまたはブロックの場合は PR を作成せず、結果と検証範囲を正確に報告してください。

対象機能、到達できなかった機能の前提条件、確認済みのドリフト、結果を簡潔な実行メモにまとめ、スクラッチ領域に保存してください。コミットしないでください。