check-if-done

Check if it is actually done

!sh -c 'for p in "$CLAUDE_PLUGIN_ROOT/scripts" "$HOME/.claude/skills/multi/scripts" "./.claude/skills/multi/scripts"; do [ -x "$p/probe.sh" ] && { "$p/probe.sh"; echo "scripts-dir: $p"; exit 0; }; done; echo "probe: NOT FOUND — locate scripts/probe.sh in this plugin and run it yourself"'

A model that just wrote code is the worst possible judge of whether that code works. It compares the task to its own summary of what it did, the two match, and it says done. Nothing was verified — the check was a memory of an intention.

So this skill does two things a normal review does not:

1. Someone who did not write it looks at it — Codex, OpenCode, and a sub-agent that has never seen this conversation.
2. Nothing is called done without an executed command behind it. Not "the tests should pass" — the command, its output, its exit code.

$SCRIPTS is whatever the probe printed as scripts-dir:.

First: what was promised?

Everything here is a comparison, so you need both sides. In this order:

1. What the user named — a plan file, a spec, an issue, a PR description. Read it.
2. This session — what was asked for and what you said you did. Write it down as an explicit list before you go further; a promise you keep only in your head is one you will grade yourself on generously.
3. Nothing? Then say so and stop: "nothing to check against — point me at a plan or tell me what this was supposed to do." Do not substitute a code review. There is already a skill for that, and silently becoming it is how a completion check turns into theatre.

Then resolve the other side: what actually changed. git diff, the branch, the files you touched. Say both out loud in one line before launching anything:

Promised: <where it came from — plan.md, the issue, what we did this session>
Changed:  <concrete paths or range>

Launch the outside reviewers

They are free and slow to start, so they go first and run in the background while you do the real work below.