| name | test |
| description | Proves that a code change meets its acceptance criteria. Uses focused automated checks and a real browser for browser-facing work. Use to test or verify a diff, branch, PR, URL, or user flow. |
| user-invocable | true |
| argument-hint | <task, acceptance criteria, diff, branch, PR, URL, or flow> |
Test
Prove the behavior that matters. A passing build or a source-code reading can support the proof, but neither proves a user-visible flow.
Process
- Read the task, its source design when present, changed code, existing tests, and repository instructions. Acceptance criteria come from the task or approved design. Preserve their wording and
AC-n or INV-n IDs. Never rewrite criteria to match the code.
- Map every acceptance criterion, cited invariant, and affected failure path to proof by ID. Test changed behavior and behavior a refactor must preserve.
- If automated tests cannot exercise the affected behavior, explain why and give other evidence.
- Add or update focused tests where proof is missing. Assertions should fail when the changed behavior breaks.
- Assert behavior a user or caller can observe unless the test targets a documented internal contract. Keep setup and assertions no more complex than the scenario.
- Run the narrowest checks that exercise the changed behavior and affected interfaces. Run wider checks when shared behavior or interfaces changed.
- When browser-rendered behavior changes, start the documented app and check the required flows and affected failures in a real browser.
- Check desktop and mobile when layout or responsive styles changed.
- Check keyboard use when interactions changed.
- Check console errors and failed requests during every flow.
- Capture evidence. Reading source is not browser proof.
- Report each
AC-n, INV-n, or task criterion as pass, fail, or unverified. Include the command, browser flow, or other evidence.
Return
Report each criterion in this shape:
Criterion: <ID or exact wording>
Result: Pass / Fail / Unverified
Evidence: <command, browser flow, or artifact>
Gap: <what remains unknown, or None>
Lead with failures and unverified criteria. Do not hide them below passing checks.
Boundaries
- Do not weaken assertions to make a change pass.
- Do not fix unrelated failures.
- If required browser tooling is unavailable, report the check as blocked unless the user explicitly accepts a manual exception.
