Verify CLI Run
Prove that a command-line tool actually did what it said, instead of trusting its exit...
Install
npx skills add reticlehq/reticle --skill verify-cli-run -g -a claude-code -y- Repository
- reticlehq/reticle1.3k
- Category
- Writing
- Updated
- 3d ago
- License
- Apache-2.0
- Context cost
- Mediumabout 2,409 tokens
- Runs scripts
- No, instructions only
What it does
Prove that a command-line tool actually did what it said, instead of trusting its exit code and its output. Snapshots the filesystem before and after, names the expected consequence in advance, and returns one of four verdicts with what could not be seen. Use after running a build, a migration, a scaffolder, a formatter, a codegen step, or an AI coding CLI; when a command printed success and you are about to report "done"; when you are about to write "exit code 0, so it worked"; or when a tool claims it edited files. Needs nothing installed.
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:
| What you have | Grade | Can it prove the command worked? |
|---|---|---|
| Files on disk, before vs after | consequence | Yes. The filesystem decided whether the write landed, not the tool |
| An API answering when you ask it afterwards | consequence | Yes. Another party, answering you rather than the tool |
| Exit code | presence | No. The tool chose it |
| stdout / stderr | context | No. The tool wrote it |
The tool's own --verbose report | context | No |
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.
