These are not theory. Every one of these came out of a real session where I got a bad answer, figured out why, and wrote the fix into the prompt so I never pay for that mistake twice. Copy them as they are, run them, then change the last 10 percent to fit you. Don't build the house. Paint it.
How to use these. Paste the prompt first, then your task. Where you see [brackets], put your own thing in. If a prompt tells Claude to stop and wait, let it — that one pause saves you five retries.
The 12 prompts
01Check before you tell me
Half my wasted credits came from Claude telling me something was live, installed, or expired when it wasn't. It was working from notes, not from looking. This stops that.
Before you tell me that anything is live, deployed, installed, expired, connected, or broken — go check it directly first. Fetch the URL, run the command, read the actual file. Then tell me what you found AND how you checked. If you cannot check it, say 'unverified' — do not guess.
02Verified vs. assumed
The answer looks the same whether Claude knows it or thinks it. Make it show its hand.
At the end of every answer, split what you said into two lists: VERIFIED (you checked a primary source or ran it, and you say which) and ASSUMED (you inferred it or worked from memory). Do not hand me step-by-step instructions built on something in the assumed list without flagging it.
03Check the premise, not just the output
Claude will triple-check the thing it built and never check whether it should have built it. This is the one that would have saved me a whole day.
Before you recommend a path, check the premises behind it against the current state of my systems and the current docs — not your memory. What platform is this actually on? Does that setting still exist? Has the rule changed? Tell me what you checked. Then recommend.
04Read the room first
Every new session starts blind. I keep a folder of daily logs. Making Claude read them first means it stops redoing yesterday.
Before we start: read [my notes folder / the last 3 daily logs / the project README] and tell me in five lines what has already been done, what's still open, and what you would NOT redo. Then wait for me.
05Paint the house, don't build it
This is the whole video. Start from the closest thing that already works.
Before you build anything new, find the closest existing thing that already does 80% of this — something I already have, a tool, a template, a proven approach — and show it to me. Tell me what the last 20% would take. Only if nothing exists do we build from scratch, and you say so.
06Show me the bigger play
I asked for a faster way to edit a video. The bigger play was a tool, a video series, and a lead magnet. Same code. Ask for the bigger play every time.
I'm about to ask you for something small. Do it — but first tell me, in three lines, the bigger version of this: how it becomes leverage, an audience, or a product instead of a one-time task. Call it out if I'm thinking too small. Then do the small thing.
07One double-click, not twelve steps
I'm not living in a terminal. If it takes a list of commands, I won't run it next month.
Don't give me a list of terminal steps. Give me one file I can double-click that does the whole thing, checks what it needs first, tells me plainly if something's missing and how to fix it, and prints what it did at the end. Assume I'll run it again in six months having forgotten everything.
08Options first, then I pick, then you build
Letting Claude pick everything and then fixing it one at a time is the most expensive way to work. Make it lay the options out, pick once, rebuild once.
Don't decide for me on the things that are taste. Lay out every option side by side where I can see them all at once, mark the one you'd pick and why, and wait. I'll choose. Then rebuild everything from my choices in one pass, no more questions.
09Where does this go?
"Write that down" used to mean four different places and Claude guessed wrong. Now it asks.
When I say 'write that down', 'save that', or 'remember that' — ask me which place I mean before writing anywhere: your memory, my files, the live site, or my phone reminders. If it's obvious from context, say which one you're using in your reply so I can catch it.
10Straight talk
Fluff costs credits too. Every 'Great question!' is tokens I paid for.
Be direct. Skip the fluff, no sugarcoating, no filler, no padded responses. Don't tell me what you're about to do — do it and tell me what happened. If I'm wrong, say so in one sentence and say why. If it's done, say done.
11End of day
The log is how tomorrow's session isn't a stranger. Two minutes at the end saves twenty at the start.
We're done for today. Write the daily log: what we worked on, what got decided (and why), what's open, and the single next move. Be honest about what didn't ship. Save it where my other logs are, dated. Don't pad it.
12Turn it into a skill
The third time you explain the same job to Claude, you're paying to teach it something it should already know. Skill it.
We just finished [task] and it worked. Turn the way we did it into a reusable skill: one line on when to use it, the steps in order, the checks before it's done, and the mistakes we hit and how to avoid them. Under 300 words. Next time I'll just say the skill's name.
The 3 skills
Save each one as SKILL.md in a folder named after the skill. Claude loads it when the task matches the description.
verify-before-asserting
---
name: verify-before-asserting
description: Use before stating that anything is live, deployed, installed, expired, connected, or broken.
---
1. Identify the claim you are about to make about the state of a system.
2. Check it directly: fetch the live URL, run `which`/`--version`, decode the token, read the actual file or dashboard. Notes and memory are leads, never facts.
3. State the finding AND the method in one line: 'Live — fetched the URL, 200, contains X.'
4. If you cannot check, say UNVERIFIED and what would verify it. Never fill the gap with a guess.
5. Never build step-by-step instructions on an unverified claim without flagging it first.
review-then-swap
---
name: review-then-swap
description: Use whenever there are several candidate outputs and the choice is taste — thumbnails, GIF picks, titles, layouts.
---
1. Generate all candidates in one pass. Never present them one at a time.
2. Put them side by side in one view (a page, a grid, a table) where the current pick is clearly marked.
3. Mark the one you would pick and give one line of reasoning. Then stop and wait.
4. When the picks come back, rebuild everything from them in ONE pass with no further questions.
5. Keep the alternates within reach (a bin, a folder) so a later swap costs one drag, not a re-run.
end-of-day-log
---
name: end-of-day-log
description: Use when the session is wrapping up, or when the user says 'done', 'wrap up', 'that's it for today'.
---
1. What we worked on — one paragraph, concrete: files, pages, tools, decisions.
2. Decisions made and WHY — the reasoning is the part tomorrow forgets.
3. Open threads — what is not done, what is blocked and by what.
4. The single next move — one thing, not a list.
5. Straight talk — say what did not ship. Do not pad.
6. Save it dated, in the same folder as the previous logs, in the same format.
That's the pack. Run them. Then go finish something. — Bo