Styles and Custom Instructions: Making Claude Sound Like You
Four layers decide how Claude sounds, and each overrides the one below it — set tone once at the right layer instead of repeating it in every prompt.
If you've ever typed some version of "keep it short, no corporate-speak, get to the point" at the start of a message — and you've typed some version of it more than a few times — you've found the exact problem this lesson solves. That instruction is correct. It's also in the wrong place. Repeating it every message means you're manually re-applying a rule that should be automatic.
Four Layers, One Override Order
"How Claude sounds" isn't one setting — it's four layers stacked on top of each other, and the layer that matters most in any given reply is the most specific one that's actually set.
Account-level preferences are the quiet floor — whatever applies when nothing more specific has been configured. A Style sits above that, applying to every chat and Project you use it in until you deliberately switch. A Project's custom instructions sit above the Style, but only inside that one Project — appropriate, since a Project's instructions are often about the work, not your voice in general. And your actual message, this turn, sits on top of all of it: if you say "actually, make this one more casual," that wins, for this reply, no matter what the layers below it say.
The practical value of understanding this stack isn't trivia — it's knowing where to put a rule so you only have to state it once. If a tone preference should apply everywhere, it belongs in a Style. If it's specific to one Project's work, it belongs in that Project's instructions. Getting this placement right is most of what separates someone who's constantly re-typing the same three sentences from someone who set them once and never thinks about it again.
Building a Style That Actually Sounds Like You
Claude Styles come with useful presets, but the real value for a power user is a custom Style built around your own voice — and there are two ways to build one, with a real quality difference between them.
The stronger path, when you have the material for it, is building from a real writing sample: three or four pieces of your own writing that already sound the way you want output to sound. Claude analyzes sentence length, structural habits, vocabulary level, and formatting patterns from the actual text — it's a specification, not a guess. "Professional but warm" is an adjective pair that still has to be interpreted every single time it's applied. Three real paragraphs of your writing removes the interpretation step entirely.
The plain-text description path isn't wrong — it's just weaker, and it's the right call when you genuinely don't have a sample yet, or when what you're specifying is more about structural rules than voice ("always lead with the conclusion, never bury it in paragraph three" is a rule, not a tone, and reads fine as a direct description).
The two other decisions on the diagram matter almost as much as the build method. If your work genuinely spans different audiences — an executive summary reads nothing like a message to your own team — build multiple named Styles and switch between them deliberately, rather than writing one Style that tries to average both and satisfies neither. And if a tone rule is scoped to one Project's work specifically, it belongs in that Project's custom instructions, not in a Style you'd apply everywhere else too.
Where the Line Actually Falls
The layer confusion that trips people up most is Style versus Project instructions, because both feel like "instructions Claude follows automatically." The distinguishing question is simple, once you know to ask it: would this rule make sense in a completely unrelated Project? If yes — no exclamation points, short paragraphs, lead with the conclusion — that's voice, and it belongs in a Style. If the rule would be actively wrong somewhere else — "always refer to clients by account code, never company name" makes sense in a client-facing Project and no sense at all in your personal notes Project — that's specific to the work, and it belongs in that Project's custom instructions.
Getting this split right the first time saves you from the alternative: discovering months later that a Project-specific confidentiality rule somehow leaked into your general Style, or that your general voice preferences are duplicated, slightly differently worded, across six different Projects because you never gave them one home.
The next lesson takes this same "set it once, apply it automatically" logic and turns it toward a different decision entirely — not how Claude sounds, but which model tier actually does the thinking.