1 Word Makes Claude Follow Rules Better

You told Claude to never use ellipses, and it obeyed. Then it handed back a script full of dashes, which were just as bad.

After your prompt you add one word (and the reason why) to fix these type of bad outputs.

⛔ “NEVER use ellipses.”

✅ “Never use ellipses because your response will be read aloud by a text-to-speech engine and it will not know how to pronounce them.”

A bare command covers only the situation it names. “Don’t use ellipses” bans three dots. It says nothing about dashes, asides, or the abbreviation “e.g.”, so Claude stays free to use all of them, and often does.

A reason covers the situations you never named. Anthropic’s prompt engineering documentation says it plainly:
“Providing context or motivation behind your instructions, such as explaining to Claude why such behavior is important, can help Claude better understand your goals and deliver more targeted responses. Claude is smart enough to generalize from the explanation.”

“Because it’s important” contains zero information, and Claude can do nothing with it. A working because has three parts.

#1 Name where the words are going. The destination does more work than any adjective. “Because this goes out in my email newsletter” tells Claude more about format, length, and tone than three paragraphs of style notes.

#2 Name the failure you are preventing. “Because a wrong number here costs me a client” gives Claude a picture of what bad looks like. Once it can see the failure, it starts spotting other roads that lead there.

#3 Keep it true. A made-up reason spreads a made-up principle across everything Claude writes. If the honest reason is taste, say taste: “because I find them fussy” is a real reason, and Claude will work with it.

If the reason would help a smart new hire make a judgment call you did not anticipate, it will help Claude.

Every pair below follows the same move: the bare rule you were probably going to write, then the version with the reason attached.

⛔ “Write short sentences.”

Write short sentences because most of my readers open these on their phones and skim while doing something else.

The reason also gets you short paragraphs, front-loaded points, and no nested clauses.

Email-safe formatting. Name the platform and Claude works around its limits.

⛔ “Don’t use tables.”

Present this without tables because I paste it into Substack, and tables break when the post goes out as an email.

Claude reaches for short labeled lines instead, and avoids other elements that render badly in email.

⛔ “Don’t promise specific results.”

Make no promises about specific results, because this goes to clients in [financial services/health], and anything that reads like a guarantee gets flagged in a compliance review.

Words like “guaranteed,” “proven,” and “risk-free” vanish without you listing a single one.

⛔ “Don’t make things up.”

Tell me plainly when you are not sure of something, because I repeat these facts to clients, and a wrong answer costs me more than a missing one.

Shaky statistics arrive with warning labels instead of confident phrasing.

A because typed into a chat helps exactly one conversation. Open a new chat tomorrow and Claude starts blank, with every reason you taught it gone.

Some rules should die that way. “Keep this under 200 words” can live and die with the LinkedIn post it was written for.

The rules you retype every week deserve a permanent home, and Claude gives you two.

Custom instructions carry your becauses into every chat. Click your initials in the lower left corner, choose Settings, and find the “Instructions for Claude” box. Anything written there gets read at the start of every conversation you open.

This is the home for reasons that describe you and the people you serve. “Avoid jargon because my clients will not stop to look terms up” belongs here, since it stays true no matter what you are writing.

Project instructions carry the becauses for one kind of work. Open or create a Project from the left sidebar and click “Set project instructions.” Rules pasted there run in every chat inside that Project and nowhere else.

This is the home for reasons that describe a destination. “Write flowing paragraphs because this goes out as an email newsletter” belongs in your newsletter Project, where it cannot leak into your proposals.

Get this right and the payoff compounds. Every new chat starts already knowing why your rules exist, and first drafts come back pre-checked against readers, destinations, and failures you explained one time, months ago.

Audit “Instructions for Claude” & Project Instructions. You should go through each line of your instructions for the “Instructions for Claude” box and each of your project instructions. Look for any rule without a “because” and fix it. This will give you an instant upgrade on all future outputs.