Builds, inside a product's own repository, the harness every agent uses to run that product and prove a claim about it: a verify CLI, a doctor command, an isolated instance per worktree, a feature map written from the user's point of view, seed data and test accounts, and a reproduce-first bug handoff. The harness lives in the target repo, not in this skill; this skill scaffolds and then maintains it, so every agent that opens that repo runs the app the same way instead of writing a throwaway script each session.

Create mode edits the target repo and Maintain mode drives a real running instance of it; both run only when named, not from a loose "check the app" prompt a lighter skill might serve better. On a host that supports it, add to the installed copy's frontmatter. It is a host extension, not a portable field, so it is not shipped in this source ('s explains why). Hosts with an equivalent explicit-invocation setting should apply it the same way.

Pick by what exists, and say which you picked.

clean

changed

blocked

Copy this to track progress:

App verification progress:
- [ ] Mode chosen and stated (Create / Maintain)
- [ ] doctor run first, read-only, before any drive
- [ ] Isolation confirmed: own port, own database, own browser profile; refused (not fell back to) the main instance
- [ ] Every path in scope checked or named as a skip with a reason
- [ ] Native/desktop paths, if any, verified with computer use as the last-resort method, not the first
- [ ] Outcome stated: clean / changed / blocked, or a reproduce-first handoff

Both modes build toward the same three commands, kept inside a skill folder in the target repo (for example or that host's equivalent project-skill location) so the commands live at one path every session finds the same way.

doctor

blocked by <id>

--json

seed

verify

and are separate commands: one is read-only triage, the other drives and reports. Merging them hides the read-only fast check behind the slow one every time.

. Interview the repo (surface, run, drive, observe, isolate), scaffold , , and the feature map per the contract above, wire isolation before writing the first feature file, seed the top three to five features, then prove the generated harness end to end before calling it done. A harness nobody has run is a draft, not a deliverable.

. Run first, every session, before the first drive and after any failed one. Pick one outcome and say which: (nothing needed changing), (one PR or commit of proven corrections to the harness itself, never to product code), or (name exactly what blocked it). A maintenance run that finds a real product bug reports it; it does not quietly patch around it inside the harness.

Two things this mode owns that a lighter probe skill does not: scoped proof (every listed path checked or skipped with a reason, recorded in the proof file; ) and the reproduce-first bug handoff, whose first line is exactly , or ().

Load only when the condition applies.

doctor

verify

manual

Maintenance only: holds the behavioural scenarios and routing prompts for anyone changing this skill. It never loads during a verification run.

Builds on Lauren Tan's pstack and (MIT): the interview-then-generate method, the outcome-based maintenance loop, and the reproduce-first handoff are hers. This skill generalizes that method past one company's conventions and adds a machine-checkable proof contract. Credit them; this is not a copy of either file.