git:20260927.1c00344 to git:20261003.fb65223

- description: Builds and maintains a product's own verification harness inside its repo, a verify CLI, a doctor command, per-worktree isolation, a feature map written from the user's point of view, seed data, and a reproduce-first bug handoff. Use when asked to "build a verification harness", "add a doctor command", "give agents a way to verify this app", "prove every feature still works", or "reproduce this bug report". For one-off browser probes against a fixed UI rule catalogue use ui-verification; for repo-wide module boundaries and lint guardrails use codebase-architecture.

- 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 is what 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.

-

- Builds on Lauren Tan's pstack `create-verification-skill` and `maintain-verification-skill` (MIT): the interview-then-generate method, the outcome-based maintenance loop, and the reproduce-first handoff (pstack's Benny automation) are hers. This skill generalizes that method past one company's Mac-mini and worktree-adapter conventions and adds a machine-checkable proof contract (a feature file every path can be checked or explicitly skipped against, a doctor command with an ordered dependency chain, and named worktree isolation). Credit them; this is not a copy of either file.

- - **IS:** scaffolding a project-local verification harness (Create mode) and running or extending one that already exists (Maintain mode): the verify CLI's contract, the feature-map format, per-worktree isolation and seed data, the cheapest-method ladder up to computer use, scoped proof, and the bug-handoff format.

- - **IS NOT:** ad hoc browser probes against a fixed catalogue of UI rules (`ui-verification`; this skill's `verify` command can call those probes as one check among several), repo-wide module boundaries and enforcement tooling (`codebase-architecture`; this skill's CI wiring follows its enforcement order), pruning an existing test suite (`test-audit`), or a plan for one feature (`planning`).

- Create mode edits the target repo and Maintain mode drives a real running instance of it; both are consequential enough to 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 `disable-model-invocation: true` to the installed copy's frontmatter so this skill runs only when called by name rather than through automatic routing; `disable-model-invocation` is a host extension, not a portable field, so it is not shipped in this source (`agent-skills-creator`'s `references/format-specification.md` explains why). Hosts with an equivalent explicit-invocation setting should apply it the same way.

- Both modes build toward the same three commands, kept inside a skill folder in the target repo (for example `.claude/skills/verify-<app>/` or that host's equivalent project-skill location) so the commands live at one path every session finds the same way, rather than as a script an agent reconstructs from memory each time.

- | `doctor` | One read-only pass answering "is this instance worth driving": toolchain, isolation, ports, database, migrations, seed, build freshness, and whichever driver (browser, computer-use) the harness needs | Changes nothing. Exits non-zero per failure with the exact fix, not just the symptom. Stops naming a check as failed once an earlier one it depends on has already failed, printing `blocked by <id>` instead of a cascade of unrelated-looking failures |

- | `verify` | Runs the checks a feature file lists, cheapest method first, and reports what ran, what it covered, what it skipped, and why | Every path a feature file lists gets a check or a named skip. Nothing merges silently uncovered under a completeness flag; a skip with no reason invalidates the proof, not just that one line |

- `references/create-mode.md`. Interview the repo (surface, run, drive, observe, isolate), scaffold `doctor`, `seed`, `verify`, and a `features/` folder 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.

- Two things this mode owns that a lighter probe skill does not:

-

- - **Scoped proof.** Every path a feature file lists gets checked or gets named as a skip with a reason; a proof that only tried one way into a feature is incomplete even when that one way passed. `references/feature-map-format.md` and the coverage rule in `references/maintain-mode.md`.

- - **Reproduce-first bug handoff.** Reproduce in an isolated instance before doing anything else, then hand off in the format `references/bug-handoff.md` defines: it opens with `Reproduced` or `Reproduced but already fixed on main`, then the root cause, then the specific case no test covers, then the instruction to re-run the repro, write a failing test, then fix.

- | [references/create-mode.md](references/create-mode.md) | Create | Bootstrapping a harness where none exists |

- | [references/maintain-mode.md](references/maintain-mode.md) | Maintain | Running or extending an existing harness, or auditing one for drift |

- | [references/feature-map-format.md](references/feature-map-format.md) | Both | Writing or reading a feature file, or checking the map for completeness |

- | [references/verification-ladder.md](references/verification-ladder.md) | Both | Choosing a method for a path, or deciding whether a native/desktop path finally needs computer use |

- | [references/worktree-isolation.md](references/worktree-isolation.md) | Both | Setting up or checking port, database, and browser-profile isolation, or seeding test accounts |

- - A prompt telling an agent to use its own port does not survive a rushed session; the refusal has to live in the CLI (`doctor` and `verify` hard-fail on the main instance's port or database) or two worktrees eventually collide.

- - A dev-only sign-in shortcut or a fixed test-account secret is a production backdoor the moment it ships enabled. Gate it on development mode and a local database, add a boot check that refuses to start with it on against anything resembling production, and verify the guard itself, not only the feature it shortcuts.

- - `verify --fast` (or its equivalent cli-only mode) is a development convenience, never a merge gate on its own; a run that skipped every browser and computer-use check is not the same proof as a complete one, and reporting it as such is how a broken native path ships unnoticed.

- - A feature file's `id` is load-bearing: verify's history and any proof record reference it. Renaming the id is a breaking change to that history, not a free-form rename.

- - `manual` is a standing task to make a path drivable, not a permanent excuse. It always reports as skipped with a reason, and the reason should shrink over time, not accumulate.

- - `ui-verification`: scoped browser probes against a fixed UI rule catalogue, one finding at a time. This skill's `verify` command can call those probes for the paths they cover; it does not replace them for a rule-by-rule audit.