| name | verification-and-review |
| description | The mandatory pre-delivery pass — requirements sweep, execution proof, self-review of the diff as a stranger's, and a fixed edge-case probe. Trigger this every time you are about to say "done", "fixed", "implemented", or "passing"; before committing, opening a PR, or handing work back to the user; and after the LAST edit of any change (a passing run before the final tweak proves nothing). Do NOT trigger while still diagnosing a failure (use debugging-methodology) or while still writing (use implementation-standards) — this skill is the exit gate. |
Verification and Review
No success claim without executed evidence. This pass is the difference between "done" and
"probably done" — and only one of those is a word you're allowed to use.
Step 1: Requirements sweep
- Re-read the ORIGINAL request, not your memory of it. On long tasks your recollection has
drifted; the text hasn't.
- List every stated requirement AND every process instruction ("no new deps", "one file at a
time", "don't touch the schema"). Process instructions carry equal weight.
- Check each against the deliverable. Every unmet item gets one of exactly three labels in
your final message: fixed now, deferred (with reason), or pushed back (with
reason). Silently dropped is not a label.
Step 2: Execution proof
- Run the thing: test suite, build, lint, or the actual entry point. Read the output — all of
it, not the exit code alone.
- Cite actual output for every load-bearing claim: "ran
cargo test — 42 passed, 0 failed",
never "tests should pass now".
- Partial verification is reported as partial: "unit tests pass; integration tests not run
(need live DB) — run
make itest to verify."
- If you fixed anything during this pass, RE-RUN after the last edit.
- If you cannot execute (no env, no creds), say exactly that and hand over the command to run.
Step 3: Edge probe
For every function/handler you wrote or changed, answer "what happens when" for each item.
Write one-word answers; test the ones answered "breaks" or "unsure":
- Empty: empty string / list / file / zero rows. (The most commonly unhandled case.)
- Boundary: exactly at the limit, one below, one above; first/last element; re-derive
every
< vs <= deliberately.
- Absent vs. empty:
None/missing key is a different case from ""/[]/0 — check both.
- Duplicates / repeats: same item twice in input; function called twice (idempotent where
it must be?).
- Malformed: wrong type, truncated file, invalid UTF-8, unexpected extra fields.
- Encoding / special chars: unicode (emoji, CJK, RTL), quotes and HTML/SQL metacharacters
reaching a renderer or query, spaces in paths.
- Time: naive vs aware datetimes, DST, midnight/year boundaries — if code touches time at all.
- Scale: the loop at n=10⁶ — hidden O(n²) or per-item I/O?
- Concurrency: two simultaneous callers — shared mutable state? check-then-act races?
non-atomic read-modify-write?
Step 4: Review the diff as a stranger's
- Read the FULL diff top to bottom in one pass without fixing anything — collect notes, fix
after. Fixing while reading blinds you to structural problems.
- Per hunk ask: Would I understand this cold? Does it exceed the task (drive-by edits,
unrequested refactors — remove them)? Is anything here a guess presented as fact?
- Hunt the signature failure modes specifically: API calls never verified against
docs/source, requirements quietly narrowed, success claims without a run.
- Cleanup check: debug prints gone, TODOs owned, scaffolding removed, no leftover
instrumentation.
Step 5: Report
- Lead with the outcome in the first sentence; the reader should know the state of the world
after one paragraph.
- Include: verification evidence, unmet/deferred items, assumptions made, limitations with
trigger + remedy ("handles files up to memory; switch to streaming past ~1 GB"), the exact
command for the user to verify themselves.
- Bad news goes at the TOP, with actual output — "2 of 14 tests fail — both pre-existing on
main, verified by stashing my changes" — never buried after successes.
- Omit: process narration, restated diffs, rejected options (unless the call was close),
filler.
Worked example — weak vs. correct claim
Weak: "I've implemented the export feature and it should now handle all the cases correctly."
Correct: "Export implemented in export.py (+ test_export.py, 6 tests). Ran
pytest tests/test_export.py — 6 passed. Edge probe: empty dataset → header-only CSV (tested);
unicode names → tested; >1 GB datasets NOT handled (loads into memory) — flag if needed.
Assumed ISO-8601 dates; say the word for locale formatting. Deferred: XLSX output (not
requested)."
Done when
Every requirement from the original message is labeled fixed/deferred/pushed-back; the final
verification run happened AFTER the last edit and its actual output is cited in your report;
the edge probe has a written answer per item for each new function; and the diff contains
nothing you couldn't justify to a reviewer line by line.
