In entry 02, I established that Claude doesn’t know you by default. Every conversation starts from zero. Entry 03 covered Projects as the fix for that within a specific context. But there’s a layer that sits underneath all of it, one that travels with you everywhere between chats, not just inside one Project.
That’s your user preferences. (sorry, I kinda lied to you last week)
what preferences actually are
Preferences live in your profile settings, not just in one Project. That means they’re always on. Every conversation you start, every Project you work on, every random question you ask at 2am about whether you can freeze sourdough starter or if we’re about to go to nuclear war. Claude reads them every time.
They’re not memory. They’re not a Project system prompt. They’re closer to a standing brief. The things that are true about you that don’t change based on what you’re working on.
there’s three layers
If you’ve been reading this series, you’ve now got three tools that work together:
| layer | what it is | where it lives | when it applies |
|---|---|---|---|
| 🧍 Preferences | Standing brief about who you are | Your profile | Every conversation, everywhere |
| 📁 Projects | Context for a specific body of work | Inside a Project | Conversations within that Project |
| 🧠 Memory | Things Claude has picked up over time | Managed by Claude | Surfaces when relevant |
The short version: preferences set the baseline. Projects add specificity. Memory fills in the gaps over time but none of them replace the other.
what to actually put in them
My honest answer is: whatever changes how Claude should talk to you and how it should work with you, regardless of what you’re doing.
My preferences are pretty full. I’ll show you the actual categories and some details on the content.
Professional context. I told Claude I’m an AI enablement leader with a military background, that I built a production multi-agent platform without a formal engineering team, and that I work with 30+ U.S. Government enterprise customers at Microsoft. That context changes how Claude calibrates explanations, what assumptions it makes about my environment, and what kinds of caveats are actually relevant to my work.
Personal context. I told Claude about the homestead aspirations, the kids, the chickens 🐓, and the fact that I’m a Swiftie. The reasonable kind. This sounds soft and very human.. I mean, why would Claude care? But it matters. Claude doesn’t over-explain things to me like I’m new to complexity. It also doesn’t assume I have unlimited time or a perfectly quiet workspace. It doesn’t treat me like I’m fragile (don’t get me started on Chad again..) It knows context switching is my specialty and how often that happens in my work. It knows who it’s actually talking to and that makes it work better for me.
How I work. This is probably the highest-value category. I told Claude I think out loud and prefer to collaborate toward answers. I told it to reflect back what it understands my ask to be before diving in. I told it not to wrap up or signal the conversation is over, I’ll end it when I’m ready. I told it to correct me if I say something wrong. These aren’t personality quirks; they’re working style instructions that make every conversation better.
Expertise calibration. I told Claude I’m technically literate but not an engineer. Broad, not deep. Check in before assuming on code or systems architecture, I want to learn as we go as well. This one saves a lot of time in both directions.
Tone and writing rules. No em dashes. No engagement bait. No therapy speak. Emojis should be used sparingly. US English. Don’t jump to deliverables before the outline is clear. These apply everywhere, so they live here once and don’t need to be repeated in any individual Project or conversation.
You don’t need all of that on day one. You only need to start with the parts that are causing you friction, the rest will build naturally.
how preferences actually develop
You’re not going to write perfect preferences the first time. I sure didn’t. If someone says they did.. weird flex, is all I’m saying. 👀
Mine continue to develop in two ways:
The first is through use. When Claude does something that annoys me, or explains something at the wrong level, or wraps up a conversation before I’m done, I add it. (let’s be honest.. it usually happens 2 or 3 times before I get annoyed enough to actually go update my preferences.. we’re people, not perfect) Preferences aren’t a one-time setup task. They’re a living document. They change as you learn and grow.
The second is through other people sharing what worked for them. I learned from reading what other people put in theirs. What categories they’ve used. What instructions actually changed the behavior the way they wanted. That’s the open source part of open source learning.
Nobody figured this out alone and nobody should have to. 🤝
If you’re reading this, you’re already doing the second one. Good job you!
If you want to share what’s in yours, the repo is open. Put it in discussions or open a PR. I’m genuinely curious what other people have landed on that works for them.
setting it up
Settings > Profile and put your instructions in the text field. Write in plain language, not code. Claude reads it as instructions, not as a form. There’s no required format. Mine is written in paragraphs with some bullet points. Whatever makes sense to you will work for Claude too.
Start somewhere. It doesn’t have to be perfect and it won’t be, and that’s totally fine. (Preferred actually.) The goal isn’t a polished preferences document, it’s a working one. Write down what’s causing friction today and build from there. You’ll be surprised how quickly it starts to feel like Claude actually knows you. ✨
Next up is tip 3: memory and how Claude builds on what it learns over time. We’re getting into the good stuff.