maintain-verification-skill

name	maintain-verification-skill
description	Periodic pass that keeps a project's verification skill and feature map honest: parallel source readers per feature, one live session driving every feature, at most one PR of proven corrections. Use for /maintain-verification-skill or "audit the verify skill".
license	MIT
metadata	{"tags":"cursor,maintenance,testing,verification","groups":"verification","invocation":"user","source":"https://github.com/cursor/plugins@195d9359bdc2890f83745df69927528ad4538406:pstack/skills/maintain-verification-skill"}

Maintain a verification skill

A feature map rots the moment the app changes. This skill is the upkeep loop for a skill generated by /create-verification-skill (or any project-local verification skill with a feature map). The unit of rigor is the feature, not every sentence: cover every feature file from source and exercise every feature live, without terminalising every bullet.

Outcomes

Pick one, and say which:

• clean. Every feature got source and live coverage; nothing worth shipping. No branch, no PR.
• changed. One PR ships proven doc, harness, or map corrections.
• blocked. Coverage could not finish or a proven fix could not ship safely. Say exactly what blocked it.

Edit scope

Only edit the verification skill's own directory (its SKILL.md, features/, and any harness scripts it owns). Never edit product code during a run: a behavior the map describes that the app no longer does is either doc drift (fix the map) or a product regression (report it, don't paper over it in docs).

Pass

0. Locate the target. Find the verification skill to maintain: the project-local skill whose body has launch/drive sections and a feature map (usually .cursor/skills/verify-*/). Several candidates → ask which one; none → stop and point at /create-verification-skill instead of inventing a target.

1. Index hygiene. Read the feature map README and glob its sibling files. Fix missing, extra, duplicate, or dead entries. Lightweight; no generated inventory.

2. Source wave. One read-only subagent per feature file, launched concurrently. Each explains "how does this user-facing feature work?" from source, flags likely doc drift with citations, and returns one concise live-verification recipe. Children never drive the app and never edit files. Return shape: feature summary / source entry points / likely drift or none / one recipe.

3. Reconcile. Every feature file has a returned summary. Merge overlapping recipes into as few app states as practical. Spot-check cited drift; don't re-prove clean claims. Sweep recent churn for user-facing surfaces missing from the map; require a concrete source path before calling one missing.

4. Live pass. Required even when source looks clean. The coordinator owns all driving; follow the verification skill's own launch model: one long-lived instance driven serially for servers and UIs, or a fresh isolated session per drive for short-lived CLIs (the skill's Launch section decides, not this one). Exercise every feature at least once, and hold three invariants throughout the pass, whatever the failure: (1) never drive an instance you haven't health-checked since it last did something surprising; doctor before the first drive, on each fresh session where sessions are the unit, and after any failed drive; where doctor can't see the failure (a wedged UI state on a healthy process), reset to a known state or relaunch rather than hoping; (2) evidence captured so far survives every cleanup and is checked at its named location, not assumed; (3) nothing a drive started outlives that drive's usefulness; failed-iteration residue is cleaned whether the session is stuck, exited, or shared (for a shared instance, clean the residue, not the instance). A doctor failure caused by skill drift is drift: fix it under edit scope and retry once; restart whatever the fix invalidated, nothing more, before calling the pass blocked. A feature that can't be reached is verified-unreachable only with the concrete prerequisite (auth, entitlement, OS, external state) and the route attempted; if the map omits that prerequisite, that's drift. Any harness fix from triage gets re-driven live before it ships. Final teardown happens after the last drive of the run, including those re-proofs, so nothing outlives the run (evidence stays, per the skill).

Keep concise run notes (features covered, unreachable prerequisites, confirmed drift, outcome) in a scratch location; don't commit them.