Verify CLI Run

Prove the command did what it said

A command exited 0 and printed ✓ done. You have learned that the tool reached its own success branch. You have not learned that anything happened.

This is the whole problem with verifying a CLI: the two things everybody checks are both the tool describing itself. The exit code is chosen by the same code that did the work. The output is written by it. When a tool is wrong about what it did, it is wrong on both, in agreement. That is exactly why their agreement proves nothing.

This skill needs no tools installed. It is four rules and some git.

The rule that decides everything

Evidence for a consequence must not come from the thing that performed the action.

Grade every fact before you use it:

Everything in the bottom three rows is real information and none of it is proof. Use it to explain a verdict, never to reach one.

1. Name the consequence BEFORE you run

This is the method. An expectation written after you see the output can be talked into agreeing with whatever happened; one written in advance can only be met or missed.

Write it down in one line, in the transcript, before the command:

EXPECT: dist/index.js is rewritten, and no file outside dist/ changes.
EXPECT: src/utils.ts gains a function called parseConfig.
EXPECT: the migration creates 3 files under migrations/ and nothing else.

A consequence you cannot state in advance is one you cannot verify. If you cannot name one, say so and stop. That is an honest no-fault, not a pass.

2. Snapshot before

In a git repo. This is the good case, and it is one line:

git status --porcelain > /tmp/before.txt

git status --porcelain is a near-perfect evidence channel: structured, cheap, and independent of the tool. Git's index records what landed on disk, not what the tool meant to do.

Not in a git repo, or the paths are outside it:

find <declared-root> -type f -newermt '1970-01-01' -exec shasum -a 256 {} + | sort > /tmp/before.txt

Three rules for the roots you declare:

• Exclude node_modules, .git/objects and large build caches unless they are the subject. Hashing a full node_modules is tens of thousands of files.
• Declare them explicitly. A tool can write anywhere; you are watching a list you chose.
• Anything outside that list is a blind spot, and you will report it in step 6 rather than pretend it did not happen.

3. Check whether it is already true

The commonest false green in CLI work: dist/index.js exists, so "the build produced dist/index.js" passes, on a no-op rebuild that did nothing at all.

Before running, check whether your expected consequence already holds. If it does, the command cannot prove it. Either pick a consequence the command changes, or delete the artifact first and say that you did.

4. Run it, and capture separately

<the command> > /tmp/out.txt 2> /tmp/err.txt; echo "exit=$?"

Keep the exit code. You are not going to use it as proof. You are going to use it to explain the verdict, and to notice when it disagrees with the filesystem.

Two things worth knowing:

• Exit codes wrap: sh -c 'exit 256' exits 0. A large code is not always what you think.
• 130 is a SIGINT, 137 is usually a kill. Those are facts about how the run ended, not about whether it worked.
• Some tools exit 0 when they declined to do anything. AI coding CLIs do this routinely.

5. Diff, and read the diff as the evidence

git status --porcelain > /tmp/after.txt; diff /tmp/before.txt /tmp/after.txt
git diff -- <the paths you expected to change>

Now answer your step-1 expectation against this and nothing else.

Two checks worth making every time, because they cost nothing:

• Nothing else changed. A build that also rewrote a lockfile, or a formatter that reformatted a file nobody asked about, is a finding.
• Content, not just existence. A file that exists is weaker than a file that contains what you expected. But note the asymmetry: whether a file appeared is decided by the filesystem; what is inside it was written entirely by the tool. Existence is stronger evidence than content.

6. Reach a verdict, one of four

Not two. The two extra values are the point: they are the ones that stop ignorance being rounded towards good news.

unknown is not a failure and must never be reported as one. "I could not see" and "it is broken" send somebody in opposite directions: one says look again, the other says go and fix something.

And say what bought the yes. "dist/index.js changed on disk" is a verdict. "The build said it succeeded" is not, and if that is all you have, the honest answer is unknown.