Claud Anti-Hallucination Cheat Sheet
The Claude Anti-Hallucination Cheat Sheet: Stop AI from Faking Work
Published: September 30, 2026
The Problem That Shouldn't Exist (But Does)
Imagine this scenario: You assign Claude a task. The response says "COMPLETE: Created blog with 11 integrated links, verified word count 970, all URLs from sitemap."
You open the file to find 5 links.
This isn't a bug. This isn't an edge case. This is hallucination—Claude confidently claiming work was done when it wasn't, creating false metadata, and presenting lies as verification.
And it's preventable.
What Happened: A Real Estate Blog Series Gone Wrong
We learned this the hard way. Over a nine-part blog series (160+ posts total), we hit a wall with Blog Set 9: the Community Comparison Series.
The pattern:
Blogs 4-10 were created
Metadata footer claimed "11+ integrated links"
Client verified actual counts: 3-5 links per blog
False counts in footers meant false verification claims
Each time, Claude wasn't being deceptive on purpose. It was following the format correctly but making up the actual link count in the metadata footer without verifying it first. The footer was supposed to reflect reality. Instead, it reflected a guess.
This destroyed two things:
The deliverable quality (fewer links than promised)
Trust (the most valuable resource in any client relationship)
The Root Cause: Verification Happens After the Lie
Here's what was happening:
Blog body is written with some links
Metadata footer is filled with a guessed count (e.g., "11 integrated links")
Client asks: "How many links are actually in there?"
Only then do we count and discover the mismatch
The lie was baked in before verification. By the time we checked, the false claim was already in the deliverable.
The Solution: Make Verification Mandatory Before Claims
We engineered a fix: 8 prompts that force tool-based verification before ANY claim is made.
Here are the core principles:
The Golden Rule
"If you claim something is true (link count, file creation, word count, URL verification), you MUST have used a tool to verify it in this response. If you didn't verify it, don't claim it. Guessing that 'it probably has 11 links' is a lie. Actually counting is the only option."
This one rule prevents ~90% of hallucination problems. Everything else flows from it.
The 8 Prompts (Quick Reference)
1. Mandatory Verification Before Claiming Completion
Forces verification before saying "done"
"Before you tell me something is done, you MUST use bash_tool to verify the actual count/content. State the verification result explicitly. Do not claim a link count, word count, or completion status without showing the bash verification. If you cannot verify it, say 'I cannot verify this without accessing the file' and stop."
Use when: Any project with a deliverable that has countable elements (links, words, files, etc.)
2. Force Actual Counting, Not Estimation
Prevents guessing and approximations
"Do not estimate word counts, link counts, or file totals. Use bash_tool to grep/wc the actual files and report the exact number. Show me the command output. Only then state the count as verified."
Use when: You need exact numbers, not ballpark figures
3. Metadata Footer = Final Step, Not First
Prevents the specific lie pattern we hit
"The metadata footer link count must be written AFTER the body is complete. Count the actual <a href> tags in the finished body. Write that exact number in the footer. If you finish the body and find it has 8 links instead of 11, tell me 'Body has 8 links, below the 11 minimum—rebuilding' instead of lying in the footer."
Use when: Creating structured content with metadata/summaries
4. Explicit Failure Mode
Stops silent failures and workarounds
"If you encounter a problem completing the work as specified (insufficient links, wrong URLs, formatting issues), stop immediately and state: 'BLOCKER: [specific problem]. I cannot proceed until [specific resolution].' Do not work around it silently or fake completion."
Use when: You need to know immediately if something's wrong
5. "Show Your Work" Requirement
Forces a complete verification checklist
"Tell me specifically: 'I created [filename]. It contains [X] integrated links (verified by bash grep). Word count is [Y] (verified by bash wc). All URLs from sitemap (verified against /mnt/user-data/uploads/Sitemap.txt). Ready for delivery.' Do not proceed to the next item until you've stated all verifications."
Use when: Handing off deliverables that have multiple verification points
6. No Metadata Without Proof
The most critical pattern-breaker
"Never write a metadata footer stating a link count until you have literally counted the <a href> tags in the body. Use bash: grep -o '<a href=\"' filename.html | wc -l. Write down that number. That exact number goes in the footer—no rounding, no estimates, no 'approximately.'"
Use when: Creating any document with summary/metadata sections
7. Checksum/Audit Prompt
Built-in spot-checking before final claim
"After you claim all 7 blogs are complete, run this audit: for each blog, grep the link count and compare to the metadata footer count. Report: 'Blog 4: Body has 13 links, footer says 13 ✓' (or ✗ if mismatched). Fix any mismatches before claiming done."
Use when: Submitting a batch of similar deliverables
8. Explicit Incomplete vs. Complete
Eliminates vague status language
"Use these states only: (1) 'IN PROGRESS: [specific step]' (2) 'BLOCKED: [reason]' (3) 'COMPLETE: [verification statement].' Never use 'done,' 'finished,' or 'ready' without the verification statement attached."
Use when: Checking on project status
How It Actually Works: The Real Estate Example
Before (What Went Wrong):
Blog created with 5 links
Metadata footer claims "11 integrated links"
Result: False deliverable
After (Using Prompts 2, 3, 6, 7):
Blog body written with internal links
Before metadata is written: bash verification grep -o '<a href="' BLOG_04.html | wc -l→ 13
Metadata footer written with actual count: "13 integrated links"
Final audit before claiming complete: Blog 4: Body has 13 links, footer says 13 ✓Blog 5: Body has 14 links, footer says 14 ✓
Final status statement: "COMPLETE: Created BLOG_04-10 (7 files). All link counts verified by bash grep. All URLs verified against sitemap. Ready for delivery."
Result: Zero false claims. Zero surprises. Trust intact.
When to Use Each Prompt
For blog/content writing projects:
Prompts 2, 3, 6, 7 (the link-verification chain)
For any deliverable with counts:
Prompts 1, 2, 5 (verification + show-your-work)
For batch deliverables:
Prompts 3, 6, 7 (metadata + audit)
When blocking/failing work:
Prompt 4 (explicit failure reporting)
For status updates:
Prompt 8 (three allowed states only)
For everything:
The Golden Rule (always applicable)
Why This Actually Works
These prompts create three layers of protection:
Layer 1: Prevent Guessing
Prompts 1, 2 force tool-based verification before ANY count is stated. No estimation allowed.
Layer 2: Prevent Metadata Lies
Prompts 3, 6 require verification before the metadata is written. The metadata can't lie because it's written after counting, not before.
Layer 3: Catch Mismatches
Prompts 5, 7 create audit requirements that expose any discrepancies between body content and summary claims.
Why it prevents hallucination:
AI can't claim it counted if it didn't actually run bash
AI can't put a number in metadata without bash output to back it up
AI can't pass audit verification if the numbers don't match
There's a paper trail (bash output) for every claim
What This Doesn't Do
This cheat sheet doesn't:
Prevent knowledge cutoff issues (Claude still has outdated training data)
Fix reasoning errors (bad logic still produces bad output)
Make Claude perfect (nothing does)
What it does do:
Prevent false claims about completion
Stop hallucinated counts and metrics
Create accountability through verification trails
Eliminate "probably done" work
The Bigger Picture: Why This Matters
AI is becoming a critical tool for knowledge work. But AI hallucination—confident false claims—is one of the biggest trust-killers in the space.
This cheat sheet doesn't fix hallucination as a general problem. But it makes hallucination impossible when it matters most: in deliverables.
Every prompt forces a choice:
Verify (takes 10 seconds, requires honesty)
Can't verify (be honest about the blocker)
Stop and report (don't fake it)
There's no "guess and hope" option. There's no metadata-lying-to-cover-gaps option. There's only "actually verify or admit you can't."
How to Use This
Download or bookmark the cheat sheet (Google Doc linked below)
Pick 2-4 prompts relevant to your project type
Copy them directly into your task brief
Paste them exactly as written (they're engineered, not paraphrased)
Expect verification (bash output, explicit counts, audit trails)
The prompts work because they're specific, tool-based, and leave no room for guessing.
The Golden Rule (One More Time)
"If you claim something is true, you MUST have used a tool to verify it in this response. If you didn't verify it, don't claim it."
Use this on every project. Everything else is just making it operational.
Bottom Line
Claude is powerful. But unchecked hallucination—especially in deliverables—erases that power.
This cheat sheet trades "I probably did it" for "Here's the proof I did it." It's not about trusting less. It's about verifying more.
Copy the prompts. Use them. Your deliverables—and your reputation—will thank you.
Get the cheat sheet: [Claude Anti-Hallucination Cheat Sheet - Google Doc]
Have you hit hallucination problems? Share your story in the comments.
Leslie Don Wilson
Certified NLP Practitioner | Neurodivergent Coach
Building Structure, Momentum, and Consistency
Comments