app-verification

アプリケーション検証

製品のリポジトリ内に、すべてのエージェントがその製品を実行し、主張を裏付けるために使うハーネスを構築します。検証 CLI、doctor コマンド、worktree ごとの分離インスタンス、ユーザーの視点で書かれた機能マップ、シードデータとテストアカウント、再現を優先するバグの引き継ぎが含まれます。ハーネスはこのスキルではなく対象リポジトリ内に置かれます。このスキルがハーネスをひな形から作成し、その後保守することで、そのリポジトリを開くすべてのエージェントが、毎回その場しのぎのスクリプトを書くことなく、同じ方法でアプリケーションを実行できるようにします。

• 対象: プロジェクト内に検証ハーネスをひな形から作成する（Create モード）ことと、既存のハーネスを実行または拡張する（Maintain モード）ことです。検証 CLI の契約、機能マップの形式、証跡の記録、worktree ごとの分離とシードデータ、コンピューター操作までの最も低コストな方法の段階的な選択肢、バグ引き継ぎの形式を扱います。
• 対象外: 固定された UI ルールの一覧に対する場当たり的なブラウザー調査（ui-verification。このスキルの verify から、複数のチェックのうちの 1 つとしてその調査を呼び出すことはできます）、リポジトリ全体のモジュール境界とその適用ツール（codebase-architecture。このスキルの CI 組み込みでは、その適用順序に従います）、既存のテストスイートの整理（test-audit）、または 1 つの機能の計画（planning）です。

呼び出し

Create モードは対象リポジトリを編集し、Maintain モードは実際に稼働しているインスタンスを操作します。どちらのモードも、明示的に指定された場合にのみ実行します。より軽量なスキルで対応できるような、「アプリを確認する」といった曖昧なプロンプトから実行してはいけません。対応ホストでは、インストール済みコピーの frontmatter に disable-model-invocation: true を追加してください。これはホスト固有の拡張であり、移植可能なフィールドではないため、このソースには含まれていません（agent-skills-creator の references/format-specification.md に、その理由が説明されています）。同等の明示的な呼び出し設定があるホストでは、同様に適用してください。

目次

• モード
• ハーネスの契約
• Create モード
• Maintain モード
• リファレンス
• 注意点
• 関連スキル
• クレジット

モード

リポジトリの現状に合わせて選び、選んだモードを明示してください。

モード	該当する状況	出力
Create	リポジトリに検証 CLI、doctor コマンド、機能マップがまだない	実際の機能を対象に、エンドツーエンドで一度実証済みの、動作するハーネス。Maintain モードへの引き継ぎも行います
Maintain	ハーネスがすでにあり、このセッションで実行する、機能を追加する、またはバグ報告を調査する必要がある	clean／changed／blocked のいずれかの結果、または再現を優先するバグの引き継ぎ

進捗を追跡するには、これをコピーしてください。

App verification progress:
- [ ] Mode chosen and stated (Create / Maintain)
- [ ] doctor run first, read-only, before any drive
- [ ] Isolation confirmed: own port, own database, own browser profile; refused (not fell back to) the main instance
- [ ] Every path in scope checked or named as a skip with a reason
- [ ] Native/desktop paths, if any, verified with computer use as the last-resort method, not the first
- [ ] Outcome stated: clean / changed / blocked, or a reproduce-first handoff

ハーネスの契約

どちらのモードも、同じ3つのコマンドを作成します。これらは対象リポジトリ内のスキルフォルダー（例：.claude/skills/verify-<app>/、またはホストに相当するプロジェクトスキルの場所）に配置するため、毎回同じパスからコマンドを見つけられます。

コマンド	内容	必須要件
doctor	「このインスタンスを操作する価値があるか」を判断するための、読み取り専用の一括チェックです。ツールチェーン、分離、ポート、データベース、マイグレーション、シードデータ、ビルドの鮮度、およびハーネスが必要とするドライバー（ブラウザー、コンピューター操作）を確認します	何も変更しません。いずれかのチェックに失敗すると、終了コードは0以外になります。失敗ごとに、具体的な修正方法を記載した行を出力します。依存先のチェックがすでに失敗している場合、無関係に見えるエラーが連鎖しないよう、そのチェックでは blocked by <id> を出力します。結果に応じて処理を分岐する呼び出し元向けに --json を提供します
seed	固定のテストアカウントとデモデータを読み込みます	冪等です。2回実行しても安全で、すでにシードデータがあるデータベースに対しても安全に実行できます。ローカルではないデータベース、またはメインインスタンスのデータベースへのシード投入は拒否します
verify	機能マップに変更用として記載されたチェックを、最も低コストな方法から実行し、何を実行し、何を対象とし、何をスキップしたか、またその理由を記録した証跡を書き込みます	機能に記載されたすべてのパスに、チェックまたは名前付きのスキップ理由を割り当てます。チェックに失敗した場合、またはどの機能にも属さないソースファイルが変更された場合、終了コードは0以外になります

doctor と verify は別々のコマンドです。前者は読み取り専用のトリアージ、後者は実行と報告を行います。統合すると、毎回、時間のかかる処理の後ろに読み取り専用の高速チェックが隠れてしまいます。

作成モード

references/create-mode.md。リポジトリを調査し（画面、実行、操作、観察、分離）、上記の契約に従って doctor、seed、verify と機能マップをひな形から作成します。最初の機能ファイルを書く前に分離を設定し、主要な3〜5個の機能にシードデータを用意してから、完了とする前に、生成したハーネスを最初から最後まで実証します。一度も実行されていないハーネスは成果物ではなく、下書きです。

保守モード

references/maintain-mode.md。毎回、最初の操作の前と、操作に失敗した後に、まず doctor を実行します。結果を1つ選び、どれかを明示してください。clean（変更する必要はありませんでした）、changed（ハーネス自体に対して、実証済みの修正を1つのPRまたはコミットにまとめました。プロダクトコードは変更しません）、または blocked（妨げとなったものを具体的に明記します）。保守の実行中に実際のプロダクトのバグが見つかった場合は報告します。ハーネス内で回避するような修正を、黙って加えてはいけません。

このモードが担当する、より軽量なプローブスキルにはないものは2つあります。対象を絞った証明（記載されたすべてのパスをチェックするか、理由を添えてスキップし、その内容を証跡ファイルに記録します。references/maintain-mode.md）と、再現を優先するバグの引き継ぎです。その1行目は、必ず Reproduced、Reproduced but already fixed on main、または Could not reproduce のいずれかにします（references/bug-handoff.md）。

参考資料

条件に該当する場合のみ読み込みます。

参考資料	モード	読むタイミング
references/create-mode.md	作成	ハーネスが存在しない状態から初期構築する場合、または doctor や verify の構成を変更する場合
references/maintain-mode.md	保守	既存のハーネスを実行または拡張する場合、証明記録の読み書きを行う場合、またはハーネスのドリフトを監査する場合
references/feature-map-format.md	両方	機能ファイルの読み書き、機能 ID の名前変更、またはマップの網羅性チェックを構築する場合
references/verification-ladder.md	両方	パスの検証方法を選ぶ場合、パスを manual と指定する場合、またはネイティブ／デスクトップのパスでコンピューター操作が必要か判断する場合
references/worktree-isolation.md	両方	ポート、データベース、環境ファイル、ブラウザープロファイルの分離を設定または確認する場合、あるいはテストアカウントとサインイン用ショートカットを用意する場合
references/reusable-checks.md	両方	繰り返し使える API リクエスト、シナリオアサーション、確認付きクリーンアップ、またはキャプチャアダプターを追加する場合
references/bug-handoff.md	保守	バグ報告を調査する場合

注意点

• 開発専用のサインイン用ショートカットや固定のテストアカウントのシークレットは、有効な状態でリリースされた時点で本番環境へのバックドアになります。追加する前に無効化を徹底し、references/worktree-isolation.md に従ってガードを検証してください。
• verify --fast（CLI のチェックのみ）は開発上の利便機能であり、単独でマージ判定に使うものではありません。ブラウザーとコンピューター操作のチェックをすべて省略した実行は、完全な検証と同じ証明にはならず、どのモードで実行したかは証明記録に記載されます。
• 2つ目の機能マップを作成した時点で、2つのマップはドリフトし始めます。アプリごとに正規のマップを1つだけ維持してください。より軽量なプローブスキルでもルートやコンポーネントを追跡している場合は、並行するマップを増やさず、このマップを参照してください。

関連スキル

• ui-verification：固定された UI ルールカタログに基づき、対象を絞ったブラウザープローブを一度に1件ずつ実行します。このスキルの verify は、対象パスに対してこれらのプローブを呼び出せますが、ルールごとの監査においてプローブの代わりにはなりません。
• codebase-architecture：リポジトリ全体のモジュール境界、CI ガードレール、およびこのスキル独自の CI 配線が従う適用順序を扱います。
• test-audit：永続的なテストスイート全体を整理します。ここで扱う機能マップとは別の資産です。差分内の新しいテストをゲートする作業は tidy です。
• planning：1つの機能に対する計画を作成します。新機能の計画から、最終的な機能ファイルが始まります。

保守のみ：evals/evals.json には、このスキルを変更する人向けの動作シナリオとルーティング用プロンプトが含まれています。検証の実行中に読み込まれることはありません。

クレジット

Lauren Tan の pstack create-verification-skill および maintain-verification-skill（MIT）を基にしています。インタビュー後に生成する手法、成果ベースの保守ループ、再現を優先する引き継ぎは彼女によるものです。このスキルでは、その手法を特定の企業の慣習にとどまらない形に一般化し、機械で検証可能な証明コントラクトを追加しています。彼女への謝辞を記載してください。いずれのファイルのコピーでもありません。