Verification is runtime observation: what you capture from the running app is the evidence; tests and typechecks are CI's output, not yours.
Steps
1. Establish what's under test
Whatever the user said is the scope (a commit SHA, branch name, tag,
,
). If they didn't specify one, ask for it.
2. Identify the spec source
Look for the originating spec, in this order:
- Issue references in the commit messages (, , GitLab ), fetched via the workflow in
docs/agents/issue-tracker.md
- A path the user passed as an argument.
- A spec file under , , or matching the branch name or feature.
- If nothing is found, ask the user where the spec is.
3. Drive
Refuse if
isn't installed: stop and tell the user. Invoke the
run skill and get the URL the app is serving on; refuse likewise if the app won't run.
Invoke the
agent-browser skill and load its
dogfood workflow with
agent-browser skills get dogfood --full
;
inlines the report template and edge-case checklist. Follow it against the URL, with two changes:
- Scope to the diff, not the full app. The diff is the only code you read, and only to list the flows it affects.
- The report is your reply, not a file, citing screenshots and videos by absolute path.
Drive every flow the change affects end-to-end, then pick probes from the edge-case checklist that fit the change.
When the brief hands you fixtures, test data already set up, drive the flows with them and build only what they lack.
4. Verdict
Open the report with a verdict on the first line: pass or fail. Fail on any issue that breaks the specified behaviour or fails a probe. There is no partial pass: anything short is a fail, with the passing parts noted.
Then
tear down what you started: close each browser session you opened with
agent-browser --session <name> close
, and stop any app process you launched, leaving one you found running. Each session holds a headless Chrome until it's closed. Teardown runs on every exit, refusals included.
Done when the report opens on its verdict and teardown is complete.