1仕組みと動作原理
これは「ジェネレーター」スキルです。直接検証を行うのではなく、リポジトリ向けにプロジェクトローカルなスキル（.cursor/skills/verify-<app>/）を生成し、後続のエージェントが「コールドスタート・人間の説明なし」で実アプリケーションを操作して証拠を収集できるようにします。
pstack/skills/create-verification-skill/SKILL.md
Every serious project needs a scripted way to drive the real app and prove behavior: launch it, exercise a feature the way a user would, and capture evidence. This skill generates that as a project-local skill (`.cursor/skills/verify-<app>/`) tailored to the repo.
読者の位置づけが明示的に固定されています: 'You write the generator's output for the next agent, not for a human: it will be read cold, mid-task, by an agent that has never seen the app.'——生成物は初見のエージェントに向けた操作マニュアルとなります。
ユーザーではなくまずリポジトリにインタビューします。5つの質問（Surface/Run/Drive/Observe/Isolate）はすべてコードベースから自己回答することを優先し、観察できない場合のみ人間に質問します。既存のハーネス（Playwright/Cypress/expect/PTY/curl/デバッグポート）は汎用レシピより優先されます。
pstack/skills/create-verification-skill/SKILL.md
Answer these from the codebase and only ask the user what you cannot observe
Driveの質問では段階的な選択肢が提示されます: 'Existing harnesses first — Playwright/Cypress specs, expect scripts, PTY helpers, curl-able endpoints, a debug port. Only then pick a generic recipe: browser/CDP for web and Electron, a tmux/PTY harness for CLI/TUI, plain HTTP for services.'
生成物には必須の6セクション構造（Launch/Doctor/Drive/Evidence/Cleanup/Helpers）があり、各セクションの内容はインタビューの実証に基づく必要があり、プレースホルダーは禁止されています。frontmatterが欠落するとスキルが登録されないため、必須とされています。
pstack/skills/create-verification-skill/SKILL.md
Write `.cursor/skills/verify-<app>/SKILL.md` with YAML frontmatter (`name: verify-<app>` and a `description` that names the app, the surface, and when to reach for it — without frontmatter the skill never registers) and these sections, each grounded in what the interview actually found (no placeholders left)
Doctorの定義は読み取り専用のヘルスチェックです: 'one read-only check that answers "is this instance worth driving?" — process up, right version/build, port owned by us, auth valid.'。Helpersは同梱スクリプトを実行可能にし、呼び出し方法を本文に明記することが求められます: 'A helper the reader has to reverse-engineer is not a helper.'
証拠基準とモックの境界はハードルールとして明文化されています。内部セッターやテスト専用エンドポイントではなく実際のユーザー経路を通ること、アクションと結果状態の両方をキャプチャすること、副作用（ファイル書き込み/行挿入/メッセージ送信）と可視面を併せて検証すること、モックは本番境界で外部システムが隔離されている場合のみ許可されること、dry-run/テストモードは名前を鵜呑みにせず実際にスキップされることを実証することが求められます。
pstack/skills/create-verification-skill/SKILL.md
exercise the real user path, not internal setters or test-only endpoints; capture the action and the resulting state, not just the final screen; verify side effects (files written, rows inserted, messages sent) alongside what's visible; mocks only where a production boundary already isolates the external system
dry-runに関する原文の警告: 'some dry-runs still touch the network or open a browser.'——観察（ファイル/ネットワーク/git refs）を通じてスキップ動作を検証する、典型的な非盲信設計です。
フィーチャーマップのシード化: features/README.mdインデックス + ユーザー機能ごとのファイル（routes/commands/menus/docsから最初の3〜5個）を生成し、references/feature-map-example/の形式に倣い、固定の4つのH2（Sub-features / How to get to it (user POV) / Driving it with <harness> / Gotchas）をユーザー視点で記述します。
pstack/skills/create-verification-skill/SKILL.md
Follow the shape in [`references/feature-map-example/`](references/feature-map-example/), with a README index and one file per feature.
フィーチャーマップはリポジトリの「継続的に維持される検証ソース」として位置づけられています: 'a proof that drives one convenient entry point is incomplete when the map lists others.'——都合の良いエントリポイントだけをテストすることを防ぎます。
納品ゲート = エンドツーエンドの実証: 生成後は生成されたスキルを自ら一度実行（launch→doctor→1機能の駆動→証拠収集→cleanup）しなければなりません。失敗した試行でもプロセスやポートの残留を防ぐためにcleanupを実行する必要があります。実行されていない生成物は単なる下書きに過ぎません。
pstack/skills/create-verification-skill/SKILL.md
A generated skill that was never executed is a draft, not a deliverable.
クリーンアップの規律: 'Never kill by process name; kill what you started. Cleanup removes instances and scratch state, never the evidence'——さらに 'After cleanup, confirm the evidence still exists at the named location — a cleanup that eats the proof fails this step.'
隔離規律の内蔵: InterviewのIsolateの質問で2インスタンスの並行実行能力を評価します。安全な並行実行が不可能な場合は、ユーザーの本番セッション汚染を防ぐため、生成スキルに「共有インスタンスでの二重駆動拒絶」を明記しなければなりません。
pstack/skills/create-verification-skill/SKILL.md
If not, say so in the generated skill: refusing to double-drive a shared instance beats corrupting the user's session.
「ユーザーデータを破壊するくらいなら実行を拒否する」ことを最優先とします。feature-map-exampleのベースライン前提条件（例: NOTES_DATA_DIR=/tmp/notes-verify-$RUN_ID）が具体的な適用形態を示しています。
2コア機能
01任意の言語/フレームワーク/プラットフォームに対応したリポジトリインタビュー（Surface/Run/Drive/Observe/Isolateの5問、自己回答優先）
02frontmatter付きverify-<app>プロジェクトスキルの生成（6セクション構造、プレースホルダーゼロ）
03フィーチャーマップのシード化（READMEインデックス + 機能ごと1ファイル + 4つの固定H2 + ユーザーPOV）
04実経路での証拠収集基準（アクション+状態+副作用の3点セット、モック/dry-run境界の明示化）
05エンドツーエンド実証ゲート: 生成スキルを自ら完全に1回パスして初めて納品とみなす
06隔離とクリーンアップの規律（共有インスタンスの二重駆動拒絶、自分が起動したものをkill、証拠はクリーンアップ対象外）
07メンテナスサイクルの接続（/maintain-verification-skillへの引き継ぎ）
3外部依存関係
| Kind | Dependency / Endpoint |
|---|---|
| cli | 无固定第三方 CLI；harness 按仓库访谈结果选定（Playwright/Cypress/expect/curl/tmux/PTY/browser CDP 等，均为宿主工具或仓库既有依赖） |
4推奨統制措置と判定根拠
安全運用のための推奨統制措置
Agent 向け
作業ディレクトリを限定
管理者向け
操作ログを保持
判定根拠（ファイルパスと抜粋）
- 本地工作目录: ファイルI/Oおよび成果物出力: 生成物をプロジェクトローカルに書き込み: .cursor/skills/verify-<app>/SKILL.md、features/README.mdおよび機能ごと1ファイル。必須
監査ノート： 。接触面 = ローカルリポジトリの読み書きおよびローカルプロセス: インタビューでコードを読み取り、生成物をプロジェクトの.cursor/skills/verify-<app>/に書き込み、エンドツーエンド実証でリポジトリ自身のコマンドを起動してホストハーネス経由でアプリを駆動し、cleanupで自身が作成したインスタンス/足場をクリーンアップ（自分が起動したものをkill、任意の削除はなし）。組み込みスクリプトなし、外部ネットワーク送信なし、クレデンシャル読み取りなし。注意事項: リポジトリが提供する起動コマンドに対する信頼境界および実アプリ操作時のデータ隔離（スキルに規律内蔵）は、いずれもホスト権限の制約下にあるローカル操作です。
5二重目の独立検証
- [ok] 纯 prompt 生成器、无自带脚本 — 目录仅 SKILL.md + references/feature-map-example/{README,create-note,search}.md；skill 自身无可执行代码。
- [ok] 五问访谈与『先仓库后用户』 — 'Answer these from the codebase and only ask the user what you cannot observe' 原文在；五问标题逐字齐全（含 Isolate 双实例题）。
- [ok] 生成技能六段结构 + frontmatter 必写 — Launch/Doctor/Drive/Evidence/Cleanup/Helpers 六段均以 '- **X:**' 形式存在；'without frontmatter the skill never registers' 原文在。
- [ok] 证据标准/mock/dry-run 边界 — 真实用户路径、副作用核验、mock 边界句逐字存在；'some dry-runs still touch the network or open a browser.' 原文在。
- [ok] feature map 契约（四 H2 + 用户 POV + 3-5 起步） — 四 H2 名称原文在；example 三个文件均按 README→功能文件的索引关系组织，create-note.md 与 search.md 各含四 H2 与 Preconditions。
- [ok] 端到端实证门禁与清理纪律 — 'A generated skill that was never executed is a draft, not a deliverable.'、'Never kill by process name; kill what you started.'、'a cleanup that eats the proof fails this step' 均逐字存在。
- [ok] 外部依赖清单（动态 harness） — 无固定第三方；harness 列表（Playwright/Cypress/expect/curl/debug port/tmux/PTY/CDP/HTTP）是候选配方而非强制依赖，已在条目中限定表述。
- [ok] 无凭证/无固定外发 — 全文无密钥/token/env 读取指令；Interview 提及 env vars/auth 仅作为『要记录的运行前提』，不是采集动作。
6結論
最適な用途： UI/CLI/サービスの振る舞いをスクリプトで証明する必要があるあらゆるリポジトリ（Web/デスクトップ/CLI/API/ライブラリ）、特にマルチエージェント並行、無人実行、新規エージェント引き継ぎプロジェクトに最適。受け入れプロセスを「口頭での主張」から「再実行可能な証拠」にアップグレードしたいチームに適合。poteto-modeファミリーの「納品前にまず証明」の規律と自然に連携。
不向きな用途： フィーチャーマップを維持するつもりのない使い捨てスクリプトシナリオ（アプリの変更に合わせてマップを更新しないと誤った手順を教えることになる）、検証成果物をエージェントのコールドリードではなく人間向けにフォーマットする必要があるチーム（生成物の文体はエージェント向け）、実アプリの起動が許可されていない環境やハーネスがない環境（純粋な静的解析タスクは別手法を選択すべき）、実行時の外部ツール使用が厳しく禁止されている環境ではエンドツーエンド実証ゲートを満たせない可能性があります。
Install Agent-Ready
① Verified Mirror 2026-09-09
Option A · Direct DownloadDownload create-verification-skill.tar.gz
sha256:
Option B · Copy Guide for Agentb679c7c74e03480f…Agent はこの JSON ガイドから自動的にダウンロードして検証します。
② Upstream GitHub
GitHub Repo ↗
Pinned to commit df3fb154fb.