Hubbestaiskill.com

Home / All Skills / Workflow & Core Tools / create-verification-skill

Workflow & Core Tools · cursor/plugins

create-verification-skill

Generate a project-local verification skill that drives your app the way a user does — any language, framework, or platform. Use for /create-verification-skill, "make a control skill for this repo", or when a project has no scripted way to prove UI/CLI/service behavior.

L2 Local · Restricted workspaceV1 Commit-PinnedWrite FileDual-pass Audit

Author cursorGitHub cursor/plugins ↗Stars 7221License 仓库根无统一 LICENSE（GitHub API license 为 null）；该 skill 随 pstack 插件分发，插件自带 pstack/LICENSE（MIT，Copyright (c) 2026 Lauren Tan）Commit df3fb154fb

Control levels describe skill capabilities and suggested control measures; they do not represent quality or safety certifications, nor do they dictate usability. Usage decisions rest entirely with users and administrators. Different agent hosts apply varying constraints; do not assume hosts provide automatic protection. Third-party skill copyrights belong to their original authors. Use at your own risk.

1How It Works & Mechanism

This is a 'generator' skill: instead of running verifications directly, it generates a project-local skill (.cursor/skills/verify-<app>/) for the repository so subsequent agents can drive the real application and collect evidence 'cold, with no human walkthrough'.

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.

The target audience is explicitly pinned down: '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.'—the generated artifact is an operational runbook for an unfamiliar agent.

Interview the repository before asking the user: prioritize self-answering all five questions (Surface/Run/Drive/Observe/Isolate) from the codebase, asking a human only when observations fail; existing harnesses (Playwright/Cypress/expect/PTY/curl/debug port) take precedence over generic recipes.

pstack/skills/create-verification-skill/SKILL.md

Answer these from the codebase and only ask the user what you cannot observe

Progressive options are defined for the Drive question: '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.'

The generated artifact enforces a mandatory six-section structure (Launch/Doctor/Drive/Evidence/Cleanup/Helpers); every section must be backed by empirical interview findings with zero placeholders allowed; missing frontmatter prevents skill registration and is strictly required.

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 is defined as a read-only health check: 'one read-only check that answers "is this instance worth driving?" — process up, right version/build, port owned by us, auth valid.'; Helpers requires self-contained scripts to be executable and invocation details written into the body: 'A helper the reader has to reverse-engineer is not a helper.'

Evidence criteria and mock boundaries are codified into hard rules: must follow real user paths rather than internal setters/test-only endpoints; capture both action and result state; verify side effects (written files/inserted rows/sent messages) alongside visible surfaces; mocks are permitted only when production boundaries isolate external systems; dry-run/test modes must be empirically proven to skip operations rather than trusted by name alone.

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

The dry-run cautionary note from the original text: 'some dry-runs still touch the network or open a browser.'—verifying skipped behavior via observation (files/network/git refs) is an anti-credulity design pattern.

Seed the feature map: generate a features/README.md index + one file per user feature (initial batch of 3-5 from routes/commands/menus/docs), mirroring references/feature-map-example/, with four fixed H2s (Sub-features / How to get to it (user POV) / Driving it with <harness> / Gotchas), written from a user POV.

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.

The feature map is positioned as the repo's 'maintained verification source of truth': 'a proof that drives one convenient entry point is incomplete when the map lists others.'—preventing agents from testing only the most convenient entry point.

Delivery gate = end-to-end empirical verification: after generation, you must execute the generated skill yourself (launch → doctor → drive one feature → gather evidence → cleanup); failures during iteration must also execute cleanup to avoid leaking processes/ports; unrun generated artifacts are merely drafts.

pstack/skills/create-verification-skill/SKILL.md

A generated skill that was never executed is a draft, not a deliverable.

Cleanup discipline: 'Never kill by process name; kill what you started. Cleanup removes instances and scratch state, never the evidence'—and 'After cleanup, confirm the evidence still exists at the named location — a cleanup that eats the proof fails this step.'

Built-in isolation discipline: the interview's Isolate question evaluates parallel dual-instance viability; if safe concurrency is not possible, the generated skill must explicitly include 'refuse to drive a shared instance concurrently' to avoid polluting real user sessions.

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.

Prioritizes 'prefer refusal over corrupting user data'; feature-map-example illustrates this concretely with baseline preconditions (e.g., NOTES_DATA_DIR=/tmp/notes-verify-$RUN_ID).

2Core Capabilities

01Repository interviewing for any language/framework/platform (5 questions: Surface/Run/Drive/Observe/Isolate, prioritizing self-answering)

02Generating verify-<app> project skills with frontmatter (six-section structure, zero placeholders)

03Feature map seeding (README index + one file per feature + four fixed H2s + user POV)

04Real-path evidence collection standards (trio of action + state + side effects, explicit mock/dry-run boundaries)

05End-to-end empirical delivery gate: generated skill must run completely end-to-end once before being considered delivered

06Isolation and cleanup discipline (refuse shared-instance dual-driving, kill what you started, keep evidence safe from cleanup)

07Maintenance lifecycle integration (handoff to /maintain-verification-skill)

3External Dependencies

Kind	Dependency / Endpoint
cli	无固定第三方 CLI；harness 按仓库访谈结果选定（Playwright/Cypress/expect/curl/tmux/PTY/browser CDP 等，均为宿主工具或仓库既有依赖）

4Recommended Governance & Evidence

Suggested Controls for Safe Operation

For Agent Runtime

Restrict working directory

For Administrators

Retain operation logs

Evidence & Triggers (File Paths & Excerpts)

本地工作目录: File I/O and artifact output: Writes generated artifacts locally to the project: .cursor/skills/verify-<app>/SKILL.md, features/README.md, and one file per feature; required

Audit Notes: . Surface area = local repository read/write and local processes: reads code during the interview, writes generated artifacts to project .cursor/skills/verify-<app>/, starts the repo's own commands during end-to-end verification and drives the app via host harnesses, and cleans up instances/scaffolding it created (kill what you started, no arbitrary deletions); contains no embedded scripts, performs no outbound network calls, and reads no credentials. Notes: Trust boundaries for repository-provided startup commands and data isolation when driving real apps (enforced via built-in skill discipline) are all local operations governed by host permissions.

5Second-Pass Verification

[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 仅作为『要记录的运行前提』，不是采集动作。

6Verdict & Scenarios

Engineers 'proof of behavior' into a reusable repository asset: the generated verify-<app> + feature map enables any subsequent agent to cold-start and drive real application verification by the book.

Anti-credulity verification philosophy: real user paths, side-effect verification, strict mock boundaries, and observable dry-run validation directly elevate the credibility of verification results.

Cleanup and isolation discipline baked into the delivery gate, preventing common incidents of 'verified successfully but left behind lingering processes, bound ports, and dirty data'.

Zero built-in dependencies: interviews adapt to any stack/platform; generated artifacts only rely on existing repo harnesses or host generic recipes without third-party vendor lock-in.

Templates as concrete examples: feature-map-example uses a complete Notes implementation (including driver commands and gotchas) to demonstrate the contract, enforcing generation quality far better than abstract schemas.

Best for: Suited for any repository that needs scripted proof of UI/CLI/service behavior (web/desktop/CLI/API/libraries), especially projects with multi-agent concurrency, unattended runs, or newly onboarded agents; ideal for teams seeking to upgrade acceptance processes from verbal assertions to re-runnable empirical evidence; naturally aligns with the poteto-mode family's 'prove it before delivery' discipline.

Not for: Not suitable for throwaway script scenarios where maintaining a feature map is not intended (the map must stay fresh alongside app changes, or it will teach incorrect steps); not suitable for teams where verification artifacts must be formatted for human review rather than cold-read by agents (the generated artifact is explicitly written for agents); not suitable for environments where running the real app is forbidden or lacks a harness (pure static analysis tasks should use other approaches); may fail the end-to-end empirical delivery gate in environments with strict runtime prohibitions against external tools.

Install Agent-Ready

① Verified Mirror 2026-09-09

Option A · Direct DownloadDownload create-verification-skill.tar.gz

sha256: b679c7c74e03480f…

Option B · Copy Guide for Agent

Agents automatically download and verify mirrors from this JSON guide.

② Upstream GitHub

GitHub Repo ↗

Pinned to commit df3fb154fb.