| name | verify-path |
| description | Gate any "this is done" claim behind actual evidence using the PATH walkthrough method (Primary flow, Alternate paths, Transitions, Happy+Hostile testing), since the founder cannot read the code to verify it themselves. Run this before presenting any feature as complete, and before /ship-checklist. |
Verify (PATH walkthrough)
The founder cannot read the diff you produced. A confident-sounding "done"
is not evidence — it's a claim. Your job in this skill is to actually
produce the evidence, in a form the founder can judge without reading code:
a PASS/FAIL report they can act on.
This skill is one layer of the Verification Engine (alongside agent-led TDD
and the 3-Layer Review) and is what bin/verify-gate.sh checks for before
letting a "done" claim reach the founder — treat that hook as the enforcement
mechanism and this skill as the actual work it's enforcing.
What to do
Walk through the feature using all four PATH dimensions. Don't skip any —
each catches a different class of bug:
-
P — Primary flow. Walk the single most important user action from
start to finish, exactly as a real user would. State each step and its
result.
-
A — Alternate paths. Deliberately try what happens with wrong inputs,
empty fields, the back button, a page refresh mid-flow. Non-technical
founders won't think to try these; you have to.
-
T — Transitions. Confirm state persists correctly moving between
pages/steps — does data survive a refresh? Does the right thing render
after a redirect?
-
H — Happy + Hostile. Test once as a cooperative user, then once
actively trying to break it (double-submit a form, submit while offline,
paste something absurd into a text field).
Then, produce evidence, not narration
- If automated tests exist for this feature, run them and report actual
PASS/FAIL counts — not "tests look good."
- If they don't exist yet, write them now, following the project's
established test setup, then run them.
- If the change is visual/UI, capture a screenshot (via the Playwright MCP
server if configured) rather than describing what it should look like.
- If an LSP server is configured (Claude Code only), treat its diagnostics as
a free pre-check — don't report "done" if there are unresolved errors it
flagged, even if you haven't run the full test suite yet.
Report format
Give the founder a short PASS/FAIL summary per PATH dimension, plain
English, no jargon:
Primary flow: PASS — user can create and view a schedule end-to-end
Alternate paths: FAIL — submitting an empty shift crashes the page
Transitions: PASS
Happy + Hostile: PASS — double-submit correctly shows "already saved"
Not done yet — 1 failure above. Fixing now.
Only say "done" when every dimension is PASS and you have the evidence to
back it, not before.
