Create Verification Skill
Create a project-local verify-<app>/ skill in the repository's configured skill location so a future agent can launch, inspect, drive, and prove one application surface without prior conversation context.
Discover the verification contract
Inspect the repository before asking the user:
- Surface. Identify the independently driven surface the user touches: web UI, CLI or TUI, desktop app, API, mobile app, or library. Generate one skill for that surface when it needs distinct controls.
- Launch. Find the repository's authoritative start command, prerequisites, readiness signal, and teardown path.
- Doctor. Define one read-only check that confirms the intended build, process, endpoint, authentication, and isolated state are safe to drive.
- Drive. Prefer an existing harness. Otherwise use stable semantic controls through the current harness's browser/UI tools, exact CLI prompts through a PTY-capable harness, or HTTP requests for a service.
- Evidence. Identify observable proof: actions and resulting UI state, terminal output and exit status, response bodies, logs, or persisted side effects.
- Isolation. Determine how runs separate ports, profiles, data directories, accounts, and cleanup. State when concurrent driving is unsafe.
If launch or doctor cannot complete, return blocked and do not claim the generated skill is proven. Product repair is outside this generator unless the user requests it.
Generate
Create a valid skill with a verify-<app> name matching its directory and a description that names the app, surface, and invocation condition. Include these sections:
- Launch gives exact startup, readiness, and teardown instructions.
- Doctor gives the read-only preflight.
- Drive uses real commands or stable controls from the repository.
- Evidence requires the initiating action, observable result, and material side effects.
- Cleanup removes only processes and scratch state created by the run while preserving evidence.
- Features points to
features/README.md and its feature recipes.
Load references/feature-map.md when writing the feature map. Add executable helpers only when they remove repeated or fragile work, and document their invocation in the generated skill.
Prove the skill
- Validate frontmatter and every relative reference.
- Follow the generated launch and doctor instructions.
- Drive one mapped feature through its real user path.
- Capture the named evidence and verify material side effects.
- Run cleanup after successful and failed attempts.
- Confirm the evidence remains after cleanup.
Completion
The generated skill is complete when a cold reader can follow it without placeholders, one mapped feature passes end to end, cleanup leaves no owned runtime residue, and the proof artifacts survive at the documented path. Report the generated skill path and the feature exercised.
1---2name: create-verification-skill3description: Create and prove a project-local skill for driving a real application surface.4---56# Create Verification Skill78Create a project-local `verify-<app>/` skill in the repository's configured skill location so a future agent can launch, inspect, drive, and prove one application surface without prior conversation context.910## Discover the verification contract1112Inspect the repository before asking the user:13141. **Surface.** Identify the independently driven surface the user touches: web UI, CLI or TUI, desktop app, API, mobile app, or library. Generate one skill for that surface when it needs distinct controls.152. **Launch.** Find the repository's authoritative start command, prerequisites, readiness signal, and teardown path.163. **Doctor.** Define one read-only check that confirms the intended build, process, endpoint, authentication, and isolated state are safe to drive.174. **Drive.** Prefer an existing harness. Otherwise use stable semantic controls through the current harness's browser/UI tools, exact CLI prompts through a PTY-capable harness, or HTTP requests for a service.185. **Evidence.** Identify observable proof: actions and resulting UI state, terminal output and exit status, response bodies, logs, or persisted side effects.196. **Isolation.** Determine how runs separate ports, profiles, data directories, accounts, and cleanup. State when concurrent driving is unsafe.2021If launch or doctor cannot complete, return `blocked` and do not claim the generated skill is proven. Product repair is outside this generator unless the user requests it.2223## Generate2425Create a valid skill with a `verify-<app>` name matching its directory and a description that names the app, surface, and invocation condition. Include these sections:2627- **Launch** gives exact startup, readiness, and teardown instructions.28- **Doctor** gives the read-only preflight.29- **Drive** uses real commands or stable controls from the repository.30- **Evidence** requires the initiating action, observable result, and material side effects.31- **Cleanup** removes only processes and scratch state created by the run while preserving evidence.32- **Features** points to `features/README.md` and its feature recipes.3334Load [`references/feature-map.md`](references/feature-map.md) when writing the feature map. Add executable helpers only when they remove repeated or fragile work, and document their invocation in the generated skill.3536## Prove the skill37381. Validate frontmatter and every relative reference.392. Follow the generated launch and doctor instructions.403. Drive one mapped feature through its real user path.414. Capture the named evidence and verify material side effects.425. Run cleanup after successful and failed attempts.436. Confirm the evidence remains after cleanup.4445## Completion4647The generated skill is complete when a cold reader can follow it without placeholders, one mapped feature passes end to end, cleanup leaves no owned runtime residue, and the proof artifacts survive at the documented path. Report the generated skill path and the feature exercised.