check-work

When to use this

Fire when any of these are true:

• You're about to tell the user a task is done, fixed, passing, or ready.
• You've finished a non-trivial change and are about to hand back, open a PR, or move to the next task.
• You've closed out a [[test-driven-development]] cycle or a [[debug]] fix and want to confirm nothing else moved.

This is the agent reviewing its own work for completeness before claiming done. It's not running the app to observe behaviour — that's the built-in run / verify skill, which this can call — and it's not an external review, which is the code-reviewer agent. It's the honesty pass you run on yourself first.

The rule

Before you say it's done, check that it is done. Re-read the original request, confirm every part is covered, run the checks, and read your own diff as a stranger would. Evidence before claims — never report "passing" you haven't watched pass.

Why

The most common real failure isn't broken code — it's partial work reported as complete. The model does four of the five things asked, forgets the fifth, and says "done", because by the end of a task the original request has scrolled out of focus and the last thing implemented feels like the whole thing. Re-reading the request from the top catches this, and nothing else does.

The second failure is claiming a state you didn't verify — "tests pass", "the type errors are fixed" — from assumption rather than from a run you watched. Assumptions are wrong often enough that an unverified claim is a coin flip you're asking the user to trust. Running the check costs seconds; being wrong costs the user's trust and a round-trip.

The third is the litter of finished work: a stubbed return you meant to replace, a console.log, a commented-out block, a TODO. Each is small; together they're the difference between work that's done and work that looks done. Reading the diff once, cold, surfaces them while they're still cheap to remove.

How to apply

1. Re-read the original request. Go back to what the user actually asked — every clause, every "and also". List the concrete requirements. This is the step that catches partial completion; don't do it from memory.
2. Check coverage against that list. For each requirement, point to where it's satisfied. Anything you can't point to isn't done — finish it or flag it explicitly. Don't quietly drop scope.
3. Run the checks that exist. Tests, typecheck, lint, build — whatever the repo has. Watch the output; read it, don't assume it. A claim of "passing" must be backed by a run you saw. If a check can't be run, say so rather than implying it passed. Use run / verify when the proof requires exercising the actual app.
4. Scan the diff for litter. Leftover stubs and placeholder returns, debug logging, commented-out code, TODO/FIXME you introduced, unrelated churn. Remove what shouldn't ship.
5. Read the diff as a stranger. One pass over the whole change with fresh eyes: does it do only what was asked? Any change you can't justify, any file touched for no reason, any obvious edge case missed? You're looking for the thing you'd be embarrassed a reviewer caught.
6. Report honestly. State what you did, what you verified and how (the commands you ran, the output you saw), and what you did not check or could not. An honest "done, but I couldn't run the integration tests" beats a confident "done" that wasn't.

Foot-guns

• Claiming done from memory. Saying "complete" without going back to the request. The request is the spec; if you don't re-read it, you're grading your own recollection, and recollection drops the last requirement first.
• Reporting unverified state. "Tests pass" you didn't run, "no type errors" you didn't check. If you didn't watch it, you don't know it. Run it or don't claim it.
• Silent scope-dropping. Doing the easy 80% and presenting it as the whole, leaving the hard part unmentioned. If you're cutting scope, say so out loud and let the user decide.
• Shipping the scaffolding. Debug prints, loosened config, and commented experiments that rode along. The diff scan exists for exactly these.
• Skimming your own diff. Glancing instead of reading. The bugs you ship are the ones in code you were too close to read properly — slow down for one cold pass.
• Over-checking trivia. Running a full self-review on a one-line typo fix. Match the rigour to the change; this is for non-trivial work, not every keystroke.