Project Instructions: writing rules Claude actually follows
A command outperforms a preference, every time
After this, you'll be able to rewrite vague preferences as direct commands, so your Project Instructions actually change how Claude responds instead of being politely ignored.
Before you start
Complete Projects in 10 minutes: setup, instructions, and first conversation first; this lesson builds on the Instructions you wrote there by making each rule one Claude actually follows.
The idea
Project Instructions are commands Claude follows, not preferences it weighs. "Always respond in bullet points" outperforms "I prefer bullet points" because one is testable and one is a wish.
This is the most common reason Instructions disappoint people. A command has a clear pass-or-fail shape Claude can check itself against; a fuzzy preference gets outweighed by the rest of the conversation. To convert one, ask "what would Claude do differently if it followed this?" then write that action down.
Here is the before and after: Before, a product manager writes "I prefer concise, professional answers and I like edge cases considered," and gets replies that are sometimes long, sometimes casual. After, she rewrites it as three commands ("keep answers under 150 words, use no slang, end with two edge cases to consider"), and every reply has the same shape.
Now try it: take one soft preference from your Instructions, ask what Claude would do differently if it followed it, write that as a command, then check it against your next reply.
A command has a pass-or-fail shape Claude can apply; a preference does not.
Try it (10 min)
Watch out for
- Phrasing rules as feelings ('I love a warm tone'); Claude cannot test a feeling, so it slips
- Writing commands that are not checkable ('be helpful'); if there is no pass-or-fail, it behaves like a preference
- Piling in ten rules at once; start with three or four testable commands and add more as you see what sticks
- Contradicting yourself ('be thorough' and 'keep it under 100 words'); conflicting commands force Claude to guess
- Forgetting that these rules apply to every chat in the Project, so a sloppy command quietly affects dozens of future conversations
Paste this into Claude
Here are some Project Instructions I wrote as soft preferences. Rewrite each one as a direct command you can follow consistently. My current Instructions: [paste your current Instructions, or use these examples to practice: "I usually like shorter answers." "I prefer a professional tone." "I like when you explain your thinking." "It would be good if you double-checked facts."] For each line, please: 1. Show the original soft version 2. Rewrite it as a testable command (something with a clear pass or fail) 3. In a few words, say what you would now do differently when following the command version Then give me the final cleaned-up Instructions block, commands only, ready to paste.
What good looks like
- Every soft preference was rewritten as a command with a clear pass-or-fail shape
- Each rewrite names a specific action Claude would take (a word limit, a banned word, a required closing line)
- Claude explained, per rule, what changes between the preference and the command version
- The final block contains only commands, with no 'I prefer' or 'I like' phrasing
- You replaced your old Project Instructions with the rewritten command version
When this breaks
- Breaks when an Instruction is phrased as a preference, because a fuzzy 'I like' has no pass-or-fail shape and gets outweighed by the rest of the conversation.
- Breaks when two Instructions contradict each other, because Claude has no way to satisfy both and will silently pick one, producing inconsistent output.
AI can help with this
Paste this into a Project chat: 'Here are my current Instructions written as preferences: [paste]. Rewrite each one as a testable command with a clear pass or fail, then give me a clean commands-only block to paste back into my Project.'
You can now
You can complete the lesson outcome in a real Claude chat, Project, Artifact, Connector, Desktop, or Code surface.
- You can verify that every soft preference was rewritten as a command with a clear pass-or-fail shape.
- You can verify that each rewrite names a specific action Claude would take (a word limit, a banned word, a required closing line).
- You can verify that claude explained, per rule, what changes between the preference and the command version.
- You can verify that the final block contains only commands, with no 'I prefer' or 'I like' phrasing.
Key takeaways
Instructions phrased as commands beat instructions phrased as preferences because a command has a clear pass-or-fail shape Claude can apply consistently across every chat in the Project.
- Write every Instruction as a direct command, not a soft 'I prefer' statement.
- Make each rule testable; if there is no clear pass or fail, it behaves like a preference and slips.
- Convert a preference to a command by asking what Claude would actually do differently, then writing that action.
- Start with three or four commands and avoid contradictions before adding more.
- Remember commands govern every chat in the Project, so the rewrite pays off across dozens of future conversations.
Go deeper