Most people use Claude the same way they use a search engine: type a question, read the answer, move on. That works for simple tasks. For complex, recurring work, it leaves most of Claude’s capability untouched.
The difference between a generic Claude response and a genuinely useful one often has nothing to do with the model. It has everything to do with what Claude knows about you, your project, and your standards before you type a single word.
That is what Claude preferences are for.
What preferences actually are
Claude preferences are instructions you write once that Claude reads at the start of every conversation. They sit in the Profile section of Claude.ai under the headings “What would you like Claude to know about you?” and “How would you like Claude to respond?”
They are not prompts in the conventional sense. They are not a message you type. They are persistent context: a standing brief that shapes how Claude approaches your work across every session without you having to re-explain yourself each time.
At their most basic, preferences might be a sentence or two: “I am a software developer. Prefer Python. Skip the preamble.” That is a meaningful improvement over nothing.
At their most developed, preferences become a complete operational document: workflow rules, terminology, formatting standards, accuracy protocols, banned phrases, style guides, tool configurations, and anything else Claude needs to understand your project in depth. The ceiling is high.
Why depth matters
Claude does not have memory between conversations by default. Every new session starts from zero. Without preferences, Claude treats you as an unknown user with unknown needs and produces accordingly generic output.
With preferences, the situation reverses. Claude arrives at the conversation already knowing your domain, your standards, and your rules. It does not need to be briefed. It does not produce output that has to be corrected for tone, terminology, or format. The first draft is already calibrated.
The practical effect compounds across a workflow. Consider a publishing operation with specific style rules: a particular variety of English, no certain punctuation marks, banned phrases from overused AI writing, specific HTML component names, SEO field requirements, schema markup standards, and an editorial code that values accuracy above all else. Without preferences, every session requires re-establishing all of that. With preferences, none of it needs to be stated. Claude already knows.
This is not a marginal improvement. For complex, high-output work it is the difference between a capable assistant and one that understands the job.
What to include
The most effective preference documents share a common structure. They answer, in some form, six questions.
Who are you and what do you do? Role, domain, and the nature of the work. Claude cannot calibrate tone, depth, or vocabulary without this. A surgeon and a startup founder asking the same question about risk should receive different answers.
What are the non-negotiable rules? Accuracy requirements, things Claude must never do, things Claude must always do. These should be stated explicitly, not implied. If a factual claim must be verifiable before it is included, say so. If a particular phrasing is banned, list it. Claude follows explicit rules more reliably than inferred ones.
What does the output look like? Format, structure, length, and delivery method. If the output is WordPress HTML, say what components are available. If the output is a legal brief, describe the required sections. If the output goes into a spreadsheet, define the column structure. Claude will produce output shaped to whatever container you describe.
What is the workflow? The sequence of steps from input to final product. If Claude is one stage in a multi-stage process, it needs to know what comes before and after its contribution. That context changes what good output looks like at each stage.
What is the editorial or professional voice? Tone guidelines, writing rules, vocabulary preferences, and examples of good and bad output. The more concrete this section is, the more reliably Claude hits the mark. Banning specific phrases is more effective than describing a general tone.
What reference information does Claude need? IDs, URLs, category names, product names, technical specifications, key contacts, recurring terminology. Anything Claude will need repeatedly should be in preferences rather than re-supplied in conversation.
Structure and organisation
A preference document that runs to several hundred words or more benefits from clear organisation. Numbered sections with descriptive headings make it easier for Claude to locate and apply the relevant rules for a given task.
Priority order matters. Rules that can never be violated should appear first, stated plainly. Rules that apply conditionally or in specific contexts can appear later, with that context defined. Claude reads the whole document, but explicit priority signals help when rules might appear to conflict.
Concrete beats abstract throughout. “Write in British English” is useful. “Write in British English: use -ise not -ize, use -our not -or, use single quotation marks” is more useful. “Never use em dashes” is unambiguous. “Avoid overly formal punctuation” requires interpretation.
Versioning your preferences is worth the small overhead. As your workflow evolves, your preferences should evolve with it. Keeping a dated copy of each version lets you roll back if a change produces unexpected results.
The compounding effect
The return on a well-written preference document is not linear. It compounds in two ways.
First, across volume. Every piece of output Claude produces is calibrated from the start. Multiplied across dozens or hundreds of sessions, the time saved on briefing, correction, and reformatting is substantial.
Second, across complexity. The more context Claude has, the more it can do with ambiguous instructions. A user with minimal preferences who asks Claude to “write a short update” gets a generic response. A user with detailed preferences gets a response that already conforms to their format, hits their word count conventions, avoids their banned phrases, uses their standard terminology, and fits into their workflow at the correct stage.
The relationship between context and output quality is not additive. More context does not just produce slightly better output. It unlocks qualitatively different capability, because Claude can make correct assumptions rather than conservative ones.
Common mistakes
The most common failure is vagueness. Preferences written as broad intentions rather than specific rules produce inconsistent results. “Be professional” tells Claude very little. A list of specific dos and don’ts tells Claude a great deal.
The second most common failure is incompleteness at the workflow level. Users often describe what they want the output to look like without describing how it will be used or what constraints govern its production. Claude cannot fully optimise output for a context it does not know exists.
The third is treating preferences as static. A document written on day one of a project may not reflect the reality of that project six months later. Preferences that have not been updated tend to produce output that feels slightly off in ways that are hard to diagnose. The answer is usually an outdated rule or a missing one.
Getting started
The practical starting point is a working session with Claude itself. Describe your work, your workflow, and your output requirements in a conversation. Ask Claude to draft a preferences document based on what you have described. Review it, correct it, and add what is missing. The result will be more complete than most people produce by writing from scratch.
Then use it. Paste it into the preferences field in Claude.ai Profile settings. Run a few sessions. Note where Claude’s output still misses the mark and refine accordingly. Most well-constructed preference documents stabilise within a few iterations.
The investment is an hour or two, once. The return is every subsequent session with Claude running at a materially higher baseline. For anyone using Claude for recurring, complex work, that is not an optional step. It is the step that makes everything else work.
John Moore is the editor of fastai.news, an independent publication covering developments in artificial intelligence.
He founded fastai.news in April 2026 to apply the same rigorous, neutral reporting standards he established at Powerboat News – his international publication – to the fast-moving world of AI.
With no filler and no opinion, fastai.news reports what is happening in AI models, research, business and tools, and leaves readers to draw their own conclusions.
John is based in Buckinghamshire, England.