create-verification-skill
Create a verification skill
Create a project-local skill that launches the real app, drives one user path, records evidence, and cleans up its own state. Tailor it to the repository. Do not leave placeholders.
Subagents may communicate with each other, but no agent may communicate with a person. Repeat that sentence verbatim in every child prompt. Put the same exact sentence in the generated SKILL.md and in every child-agent or drive prompt the generated skill creates. The generated skill must forbid agents from sending messages, invitations, email, notifications, comments, replies, or published content to real people. Verify communication features only against isolated local sinks, fake accounts, fixtures, intercepted transports, or disposable test services that cannot reach a person. If no such target exists, mark the path unreachable and stop before the action.
1. Interview the repository
Answer these from source and documentation. Ask the user only for facts the workspace cannot reveal.
- What does a user touch: web UI, mobile app, desktop app, CLI, service, or library?
- How does the app start locally? Record the exact command, readiness signal, ports, environment, data, and authentication needs.
- What existing harness can drive it? Prefer repository-owned browser tests, PTY helpers, HTTP clients, mobile automation, or debug interfaces.
- What proof can the run capture? Use screenshots, accessibility snapshots, terminal transcripts, response bodies, logs, exit codes, or stored state.
- Can concurrent runs isolate ports, profiles, and data directories? If not, tell the generated skill to refuse a shared instance.
If the checkout does not start, fix the local baseline only when that is within the user's request. Otherwise report the blocker instead of writing instructions against a broken app.