7 min · +120 XP
Check that it really works
How to make Claude prove the result, and a five-minute test you can do yourself.
By the end of this lesson
You will be able to get evidence from Claude that a tool works and to find the usual problems yourself in five minutes.
When Claude writes "Done", it means the work looks finished to Claude. Without a check, that is the only signal it has, and small mistakes wait for you to find them. So ask for evidence, and then spend five minutes trying the tool yourself.
How to ask Claude to check
“Run it and tell me what you saw.”
The quickest check: Claude starts the tool and reports what happened.
“Write a small test for adding and deleting an expense, run it, and show me the result.”
Claude writes the test, runs it and shows passed and failed.
“Open the page, take a screenshot and compare it with what I asked for.”
This needs a way to open a browser; if Claude cannot, it will say so.
“List what you checked, and separately list what you did not check.”
The second list shows you where to look yourself.
Check it yourself in five minutes
A manual test for any tool
0/6When you find a problem
- 1Write three things: what you did, what you expected, what happened. "I typed 12,50 and pressed Add. I expected 12.50. The total grew by 12."
- 2Ask Claude to fix the cause and to check the fix the same way.
- 3Then repeat the step of the test that failed.
“I typed 12,50 and pressed Add. I expected 12.50. The total grew by 12. Fix the cause, then check the fix the same way and show me.”
Replace the three sentences with what you did, what you expected and what happened.
›What a "test" is
A test is a small piece of code that uses your tool automatically and checks the answer, for example "add an expense of 10 and make sure the total is 10". Claude writes and runs tests for you. You do not need to read them; it is enough to see that they pass.
The docs' first best practice is to give Claude a check it can run: tests, a build exit code, a linter, a screenshot compared with a design. Ask it to address root causes rather than suppress errors. For a session-long gate, set /goal with one measurable end state Claude's own output can demonstrate, for example /goal all tests in tests/ pass and the build succeeds. The bundled /verify skill builds and runs the app to confirm a change against the running program; for a second opinion, /code-review reviews the current diff for correctness bugs.
Claude says: "Done ✓ The tool is ready." What is the most useful next message?
Which manual check most often finds a real problem in a small tool that stores data?
Facts checked against the official Claude Code docs October 24, 2026 · source
Author
Evgenii Arsentev
PhD · Chief Executive Officer, digital health