The sentence that breaks everything

What it is and why it matters

The sentence that breaks everything is the one you toss off: “fix the login”, “make the page faster”, “add payments”. Claude Code takes it seriously and does something. The problem is that it decides on its own what “fixed” means, what it's allowed to touch and when it's done.

It isn't a flaw in the AI. It just can't read your mind. Anthropic's own prompting guide puts it simply: treat it like a brilliant colleague who just started and doesn't know your rules or your project. The more precisely you say what you want, the better the result.

That's why before every request I fill in a three-line template: what has to happen, what must not change, how we check it. It doesn't take long. It saves me from the worst part, which is finding out once the work is done that it rewrote something that worked. The same AI gives you a different result when the request is clear. It isn't magic: it's being clear with someone who can't read your mind.

The three-line template

Here it is. Copy it and fill in the brackets. One line per part is enough.

What has to happen: [the result you want to see, in your own words]
What must not change: [files, pages or features it must not touch]
How we check it: [how you know it works: a test, a click, a piece of data that has to show up]

What has to happen

The result you want to see, not the way to get there. Write it in your own words, the way you'd say it out loud. “When I press Save, the note shows up in the list” works better than “fix the saving bug”, because it says what the person using the app should see. If you know where it happens, which page, which button, write it down: that way Claude doesn't have to guess.

What must not change

The boundaries: files, pages or features that have to stay as they are. To fix one thing, Claude sometimes “improves” other things nearby that nobody asked for. If you tell it where to keep its hands off, it has a clear limit. It's the line almost everyone skips, and I come back to it further down.

How we check it

How you know it works: a test, a click, a piece of data that has to show up. This line is for you and for Claude. If it has a check it can run by itself, like a test that passes or fails, it can try, read the result and correct itself before telling you it's done. Without one, the only signal is that the work “looks done”, and the checking is on you.

Two examples to copy

Example 1: a button that doesn't save

What has to happen: when I press the Save button on the Notes page, it has to create a row in the notes table in the database.
What must not change: don't touch the login and don't change the page's design.
How we check it: tell me exactly how to test it, step by step, and if you can, write a test that verifies it.

Look at the third line. You don't need to know how to write a test: I ask Claude to tell me how to try it and, if it can, to write the test itself. You don't have to know how it's checked. You just have to insist that there's a way.

Example 2: a slow page

What has to happen: the pricing page has to open in less than two seconds, on a phone too.
What must not change: the prices, the texts and the payment stay exactly the same.
How we check it: measure the loading time before and after, and show me the two numbers.

Here the check is one number before and one after. If Claude tells you “it's faster now” without the two numbers, you don't know if it's true. And the middle line protects what you don't want to see changed by mistake while it optimizes: prices, texts, payment.

Three tips for using it in Claude Code

1. If you don't know how to check it, stop

If you can't answer “how do we check it”, you don't know yet what you want. It happens, and it's better to notice before than after. Instead of starting the work, ask for help figuring it out:

Help me figure out how to verify this, don't write any code.

For bigger jobs I use Claude Code's plan mode. Claude reads the files and proposes a plan, but doesn't change anything until you approve it. You enter it by pressing Shift+Tab until “plan mode on” shows up at the bottom, or by typing /plan in front of your message. That's where I paste the template and ask:

Read the template below and propose a plan. Tell me which files you plan to touch, confirm you won't touch the ones I ruled out, and explain how we'll do the check in the last line.

[paste the filled-in template here]

For a small change you don't need the plan: if you can describe it in one sentence, like fixing a typo in some text, just ask for it directly.

2. Don't skip the middle line

“What must not change” is the part everyone skips, and it's the one that saves your login, your payments and your real data. The things it must never touch I also write in CLAUDE.md, the file in the project folder that Claude Code reads at the start of every session. For example this line:

Don't change the login, the payments or user data without asking me first.

Careful, though: CLAUDE.md is an instruction, not a lock. Claude treats it as context, not as a hard block. That's why, when a request gets close to those parts, I still write them in the template.

3. At the end, ask for the report

When it's done, always ask:

Tell me what you changed and what you didn't touch.

Then compare the answer with the template. If it touched something from the middle line, or the check from the third line is missing, you see it right away. When that happens I don't move on, I ask:

Show me the proof for the last line of the template: the test with its result, or the exact steps for me to try it.

Common mistakes

• Describing the code instead of the result, like “change that function”: write what the person using the app should see and leave the how to Claude.
• Leaving “what must not change” empty because it seems obvious: write at least login, payments and real data whenever the work gets close to them.
• A vague check like “make sure it works”: ask for something you can see or measure, meaning a test that passes, a click, a number.
• Putting three requests in the same template: one template, one thing, and you ask for the others afterwards, one at a time.
• Trusting “done” without a report: ask what it changed and what it didn't touch, and compare it with the template.

Checklist

• I wrote the result in my own words
• I wrote down what it must not touch
• I know how I'll check that it works
• The template asks for one thing only
• For a big job I asked for a plan first
• At the end I asked what it changed and what it didn't

Frequently asked questions