How Do You Tell Claude What a Right Answer Looks Like?
List the conditions a correct answer must meet, in terms that can pass or fail, and ask Claude to verify against them before it finishes. Thinking is far more useful when it has something concrete to check. "Make it good" gives it nothing to test.
[Describe the task.] A correct answer must meet all of these: 1. [testable condition, such as "total cost is under $4,000"] 2. [testable condition, such as "every person gets at least one weekend off"] 3. [testable condition] These are preferences, not requirements: [list them]. Before you finish, verify your answer against conditions 1 to 3. Show a table with each condition, pass or fail, and the specific evidence. If no answer can meet all of them, say which one conflicts and don't quietly drop it.
- "Make it good"
- Pass or fail conditions
- A test that runs
Try it now
- 1Take a task you'd normally judge by feel, and write three conditions you could check without asking anyone.
- 2Paste them into the prompt above, with the task, and send it.
- 3Check Claude's pass or fail table yourself, starting with the condition it found hardest.
- 4You'll know it worked if you can confirm each row in under a minute. If you can't, the condition was too vague, so rewrite it.
Use it when
Use it when a task has hard limits, such as a budget, a word count, a legal requirement, an API contract or a seating plan. It also suits anything you'd otherwise review by checking a list.
Skip it when
Skip it for open-ended brainstorming, where tight tests kill the range you wanted. Also skip adding self-check lines on Opus 5. Anthropic says that model verifies its own work well, and extra verification instructions there add tokens and latency without helping.
Why it works
Anthropic's prompting guide recommends appending "Before you finish, verify your answer against [test criteria]", and says this catches errors reliably, especially for coding and math. The same guide says to prefer general instructions over prescriptive steps, so you describe what must be true and leave the method to Claude. Claude Code's docs make the same point for agents: Claude stops when work looks done, and if it has something that returns pass or fail, it can run it, read the output and fix the problem itself.
Example
You're planning a 2-day offsite for 14 people. The conditions are: under $6,000 total, no session after 5 p.m., the two vegetarian attendees are covered at every meal, and the venue is within 30 minutes of the airport. You paste your venue shortlist. The table makes a miss obvious, and if the budget and the airport rule can't both hold, you've asked Claude to say so instead of bending one.
Going further
In Claude Code, make the test executable. A test file, a build's exit code or a script that diffs output against a fixture all count. The docs recommend reviewing against your spec with a prompt that ends in report gaps that affect correctness and skip style, because a reviewer asked to find problems will always find something. To check that Claude's work is what you asked for, the fresh subagent matters: Anthropic says it helps because it hasn't seen your reasoning.
Common mistakes
- Writing "high quality" or "professional" as a condition. Claude can't fail those, so they don't test anything.
- Mixing preferences with requirements, so Claude trades away something you needed in order to keep something you only liked.
- Not telling Claude what to do when conditions conflict. It may quietly relax one and still report success.
- Accepting the pass or fail table without checking it. It's Claude's own claim about its own work.
Sources
Checked 6 November 2026. Products change often, so confirm details with the vendor.