You spell it out in your Claude Project’s Custom Instructions: “no emoji in responses,” “TypeScript only, never JavaScript,” “answer in English, never Chinese.” Two turns in, emoji are everywhere, code samples are JS, and one response is in Chinese. This isn’t Claude actively ignoring you — Project Instructions are soft constraints to the model, not hard rules.
Key mental model: Project Instructions get prepended to the system prompt on every chat. The model “considers” them, but when the current prompt implicitly or explicitly conflicts, or the rule is too vague, it follows the most recent, most specific signal. That’s instruction drift.
Common causes
Ordered by hit rate, highest first.
1. Rules are too abstract — model can’t judge violations
“Be professional.” What counts as professional? “Don’t be too verbose.” How long is too long? Subjective words leave interpretation space, and drift is inevitable.
How to spot it: Read your rules. Ask “could a new contractor objectively decide which answers violated this?” If no, this is your problem.
2. Current prompt implicitly conflicts
The rule says “output TypeScript.” But you ask “how would I change this JS snippet?” — the model follows the prompt because it inferred you wanted JS for this turn.
How to spot it: Review recent prompts. Any hints you implicitly wanted the banned format / language / style?
3. Long context dilutes the rules
Project Instructions stay in the system prompt, but after 30 turns most attention is on recent dialogue. Early rules lose force.
How to spot it: Violation in turn 1 → rule itself is broken. Violation only after turn 20 → context dilution.
4. Rules contradict each other
“Explain every step in detail” + “Keep answers concise.” Model must pick one, and it isn’t always the one you wanted.
How to spot it: Read the full instructions and look for direct opposites like “must be detailed” vs. “must be brief.”
5. Ambiguous negations
“Don’t not write tests” (double negative), “avoid too many technical terms” (vague hedge). Models parse these badly.
How to spot it: Search for “don’t not,” “avoid too,” “less of,” “try not to.”
6. Instructions are too long (>1000 words)
Long instructions drown key rules in decoration. If the first 200 words are “our company is focused on…” the real rules are pushed down.
How to spot it: Paste instructions into a word counter. >500 words → cut.
Shortest path to fix
Step 1: Turn abstract rules into hard ones
❌ "Be professional"
✅ "Never emit emoji characters; never end sentences with !"
❌ "Don't be too verbose"
✅ "No response over 300 words; if longer is required, use bullets"
❌ "Use TypeScript"
✅ "All code blocks must be tagged ts or tsx; never .js / .jsx;
if user pastes JS, first say 'I'll convert to TS', then answer"Observable, mechanically verifiable rules are followed dramatically more often.
Step 2: Structured template
# Hard rules (must follow)
- Never use emoji
- Always respond in English
- Code is always TypeScript, never JavaScript
# Soft preferences
- Prefer functional patterns over OOP
- Use named arguments
# Tone
- Direct, no hedging
- No filler intro ("Great question!")Explicit hard/soft split — model satisfies hard first, soft second.
Step 3: Trim to 300-500 words
Cut:
- Company / project background (unless it affects answers)
- Politeness (“please,” “thank you”)
- Restated rules (“must,” “never forget to”)
- Decorative paragraphs
Keep only behavior rules.
Step 4: Restate the 1-2 most critical rules at chat start
First message:
Reminder: all code must be TypeScript, no emoji.
My question now is ...Most recent + most specific = highest priority for the model.
Step 5: Call out violations and demand acknowledgment
Your last response contained emoji. Confirm you saw the rule
"Never use emoji" and explain why you violated it. Then redo
the answer.Forcing the model to recite the rule sharply increases compliance on the next turn.
Step 6: For API use, put critical rules in system, not Projects
If you’re calling the API (not the web Claude), put hard rules in the system field — it has more weight than Project instructions. Wrap them in <critical_rules>...</critical_rules> tags for even stronger adherence.
Prevention
- Split instructions into three blocks: MUST / MUST NOT / Style. Max 5 lines each
- Every rule must be observable and mechanically verifiable — abstract rules won’t be followed
- Total length under 500 words; cut redundant verbiage
- Re-state critical rules at the start of each chat (one short sentence)
- When the model violates, don’t gloss over — explicitly name “which rule was violated”
- Review instructions monthly based on which ones actually get followed
Related
Tags: #Claude #Troubleshooting