Finish the Job

"Done" is a claim about reality, not about effort. The gap between "I made the edits" and "the thing works" is where most user trust is lost. This skill is the checklist for closing that gap — and for reporting honestly when it can't be closed.

1. The evidence hierarchy

Every completion claim sits somewhere on this ladder. Know where yours sits, and say so:

1. Observed behavior — you ran the app/feature and watched it do the right thing
2. A new test written for this change passes — and fails without the change
3. Pre-existing tests pass — proves you broke nothing they cover, not that the feature works
4. It compiles / type-checks — proves spelling, roughly
5. "I read the code carefully" — this is a guess wearing a suit

Push each change as high up the ladder as the environment allows, then report the rung you actually reached: "verified by running X and observing Y" vs. "compiles and existing tests pass; I could not exercise the SSO path locally." Both are honest; only the labeling makes them so.

2. Hostile self-review

Re-read the complete diff (git diff, not your memory of it) as a reviewer who believes you are wrong. You wrote this code with a theory in mind; the reviewer's job is to attack the theory. Hunt specifically for:

• Off-by-one and boundary conditions; empty, null, and zero-length inputs
• Error paths: what happens when the call fails, the file is missing, the input is malformed? Does cleanup still run?
• Every caller of every function you changed — do their assumptions still hold?
• Concurrency: can this run twice at once? Is shared state mutated?
• The thing the user mentioned in passing ("it sometimes runs on Windows") that the happy path ignores
• Diff against the nearest sibling: put your new code next to the most similar existing code in the repo. Different exception type on invalid input? Skipped a shared validation helper? Different docstring or test shape? Each divergence is either deliberate (say why in the report) or a bug. Watch especially for tests you wrote that assert awkward behavior (empty input producing junk output) — such a test doesn't cover the edge case, it enshrines the bug.

3. Run the narrowest loop that exercises YOUR change

Passing tests that never execute the changed lines prove nothing — a green suite is only meaningful if the diff is inside its reach. Run the new/changed tests first, then the relevant suite. For a bugfix, confirm the regression test fails when the fix is reverted; a test that passes either way is decoration.

If verification is possible but slow, run it in the background and finish the review pass meanwhile — don't skip it because it's slow.

4. Leave the campsite clean

Before the final report, sweep the diff for construction debris: debug prints, dead code, commented-out experiments, scratch files, TODO markers you meant to resolve, overly generous logging. The diff should read as if written deliberately, in one pass, by someone who knew where they were going. Also check: did you duplicate an existing helper? Did you build something more general than the task needed? Deletion is the highest-value edit available at this stage.

Then check the repo's own definition of done: if a CONTRIBUTING file or PR template exists, its obligations — changelog entry, version bump, regression test, docs update — are part of the change, not optional extras. Nobody will list them in the task; the repo already did.

5. Report so the reader can trust it

Structure the final message for a teammate who stepped away and is catching up:

• First sentence: the outcome. What now works, or what failed. Not the journey.
• What changed and where, with clickable path:line references.
• How it was verified — the actual commands and what they showed, and the evidence rung (section 1) you reached.
• What was NOT verified, known limitations, and anything you descoped. If you stopped early or something failed, that is the headline, not a footnote buried under a success narrative.

Complete sentences, technical terms spelled out, no arrow-chain shorthand. If the user has to re-read the summary, its brevity saved nothing.

6. Never expand "done" silently

If the task shrank along the way — a case punted, a platform skipped, a migration deferred — the report must say so at the top. A reader who discovers descoping on their own stops trusting every future "done."