create-verification-skill

Generates a project-local verification skill that drives an app and captures behavioral evidence.

Updated Sep 2, 2026
One-click install
npx skills add https://github.com/jnyross/pstack-muse --skill create-verification-skill-jnyross
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: create-verification-skill
Source: https://github.com/jnyross/pstack-muse/tree/main/skills/create-verification-skill
Command: npx skills add https://github.com/jnyross/pstack-muse --skill create-verification-skill-jnyross

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Projects often lack a scripted way to prove that real user-facing behavior works. This Skill interviews a repository and generates a project-local verification skill that launches the app, drives it the way a user would, and captures evidence of correct behavior. ## Core Features & Use Cases - Repo Interview: Identifies the app's surface (web UI, CLI/TUI, API, desktop), launch commands, driving harnesses (Playwright, CDP, tmux/PTY, HTTP), and observable evidence sources directly from the codebase. - Skill Generation: Writes a complete verify-<app> skill with Launch, Doctor, Drive, Evidence, Cleanup, and Helpers sections grounded in real selectors and commands from the repo. - Feature Map Seeding: Creates a maintained feature map with one file per user-facing feature, following the example structure in references/feature-map-example/. - Self-Verification: Runs the generated skill end to end once — launch, doctor, drive one feature, capture evidence, clean up — before handing it over. - Use Case: A repo with a web app and CLI has no automated UI proof. Invoke this Skill to produce a verify-<app> skill that launches the app on a disposable data directory, drives key features through a browser harness, and stores screenshots and ARIA snapshots as proof. ## Quick Start Ask the agent to create a verification skill for this repository so the app's user-facing behavior can be driven and proven end to end.

Frequently Asked Questions about create-verification-skill

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I create a verification skill for my repository?

Invoke the create-verification-skill workflow, which interviews your codebase for its user surface, launch command, driving harness, and evidence sources. It then writes a project-local verify-<app> skill with Launch, Doctor, Drive, Evidence, Cleanup, and Helpers sections.

What app types can a generated verification skill drive?

It supports web UIs, CLIs and TUIs, desktop apps, APIs, mobile apps, and libraries. The generator prefers existing harnesses like Playwright or Cypress specs, then falls back to generic recipes such as browser/CDP for web, tmux/PTY for terminals, and plain HTTP for services.

What is the feature map in a verification skill?

The feature map is a maintained directory with one Markdown file per user-facing feature, seeded from routes, commands, menus, or docs. Each file describes sub-features, user entry points, exact driving commands with observable results, and gotchas.

Does the generated verification skill get tested before delivery?

Yes. The workflow requires running the generated skill end to end once: launch, doctor check, driving one mapped feature, capturing evidence, and cleaning up. A generated skill that was never executed is treated as a draft, not a deliverable.

What counts as valid evidence when verifying app behavior?

Evidence must capture the user action and the resulting state, such as screenshots, ARIA snapshots, terminal transcripts, response bodies, or exit codes. Proofs must exercise real user paths and verify side effects like files written or rows inserted, not internal setters or test-only endpoints.

When should I not generate a verification skill for a repo?

If the checkout does not build or start as-is, fix or report that first, because a skill written against a broken base teaches wrong steps. Also avoid driving shared instances that cannot run side by side, since that risks corrupting the user's session.