You Don’t Have to Write Code to Need a CLAUDE.md
Setting Up Claude’s Memory for Writers, PMs, Researchers, and Everyone Else
You Don’t Have to Write Code to Need a CLAUDE.md
Setting Up Claude’s Memory for Writers, PMs, Researchers, and Everyone Else
Everything I’ve written about CLAUDE.md so far has been aimed at engineers. Build commands. Linter rules. TypeScript conventions. That makes sense because Claude Code started as a developer tool. But here’s the thing: the core problem it solves has nothing to do with code. The problem is that Claude doesn’t remember you. And that problem is universal.
If you use Claude to draft emails, write reports, research competitors, plan projects, prepare for meetings, or think through strategy, you’re re-explaining your preferences every single session. Your writing voice, your audience, your formatting quirks, the things that annoy you, the shortcuts that save you time. All of it resets the moment you close the window.
A CLAUDE.md fixes this, whether you’ve ever written a line of code or not. The syntax is markdown, which is just text with some light formatting. If you can write a bullet point, you can write a CLAUDE.md.
Here’s what the non-engineering version looks like.
1. Writing Voice and Style (Your Fingerprint)
# My Writing Style
- Conversational, not formal. Write like a smart person talking,
not a textbook lecturing.
- Short paragraphs. Rarely more than 3-4 sentences.
- Use "you" and "I" freely. First person is fine.
- No em dashes. Use commas, semicolons, or just start a new sentence.
- No corporate buzzwords: "synergy," "leverage," "optimize,"
"best-in-class," "move the needle." Say what you mean in plain English.
- Contractions are encouraged. "Don't" over "do not."
- Vary sentence length. Mix short punchy sentences with longer ones
that develop an idea. Rhythm matters.
- When making a point, lead with the conclusion, then explain.
Don't build up to the punchline.
- Active voice always. "We launched the product" not
"The product was launched."
## How to Use This Section
Paste your draft into Claude with a prompt like:
"Rewrite this following my writing style rules in CLAUDE.md"
or "Edit this to match my voice" and Claude will apply every
rule above automatically. No need to re-explain your preferences.
You can also paste raw notes or outlines and say "turn this into
a draft using my style" and Claude will generate from scratch
using these constraints.
This is the section that makes Claude sound like you instead of like Claude.
Without it, Claude writes in its default register: competent, polished, and completely generic. It hedges with phrases like “It’s worth noting that” and “It’s important to consider.” It writes in passive voice. It produces paragraphs that are grammatically correct and completely devoid of personality.
The real power shows up when you paste a draft. You write something quick, maybe rough, maybe too long, and you tell Claude “rewrite this following my style rules.” Claude applies every constraint in the section at once: it kills the em dashes, cuts the buzzwords, shortens the paragraphs, flips passive constructions to active, and leads with conclusions instead of building to them. You get back something that sounds like you on a good writing day. Not a generic AI rewrite. Your voice, cleaned up.
This works the other direction too. Paste in bullet points or raw meeting notes and say “turn this into a draft using my style.” Claude doesn’t just expand the bullets into prose. It expands them into your prose, with your rhythm, your sentence patterns, your word choices. The style section acts as a filter on everything Claude produces, whether it’s editing your words or generating new ones.
Every line here is a constraint that pushes Claude’s output toward your voice. “No em dashes” is a tiny thing, but if you never use them in your own writing, their presence in a draft is a tell that screams “AI wrote this.” Same with “no corporate buzzwords.” Claude loves these words because they appear constantly in its training data. Banning them forces Claude to find the actual, specific word that fits.
“Lead with the conclusion, then explain” changes the structure of everything Claude writes. Claude’s default is to build an argument bottom-up, laying groundwork before reaching the point. Most readers want the point first and the evidence second. This one instruction restructures every paragraph Claude generates.
Why it works: Voice is the hardest thing to prompt for in real time. You can ask Claude to “write casually” and get something that’s vaguely casual but still not you. A detailed style section teaches Claude your specific patterns, not a general vibe. And because CLAUDE.md loads automatically, you never have to re-explain these rules. Paste the draft, say “fix this,” and every preference applies.
2. Audience and Context (Who’s Reading This)
# My Audiences
When I write blog posts or public articles:
- Tech-savvy but not necessarily engineers
- They've managed teams or aspire to
- Skip introductory explanations of common concepts
(agile, standups, sprints)
- Include specific examples, not abstract principles
When I write internal docs:
- Audience is an engineering team
- They know our stack. Don't explain our tools.
- Be direct. They prefer "do X" over "consider doing X."
- Link to our internal wiki when referencing processes
When I draft emails to executives:
- Three paragraphs max
- Lead with the ask or the update, then context
- Numbers over narratives. "Reduced deploy time by 40%"
not "significantly improved our deployment process"
- Never use jargon they wouldn't know. Translate technical
concepts into business impact.
This is the section that eliminates the “who is this for?” back-and-forth at the start of every session.
Without audience context, Claude writes for a generic educated reader. That means it over-explains things your audience already knows and under-explains things they don’t. An email to your VP doesn’t need a paragraph explaining what CI/CD is. A blog post for aspiring managers doesn’t need a disclaimer that Agile has many interpretations.
The executive email section is particularly high-value. Claude’s default email style is long and thorough. Executives read fast and skim faster. “Three paragraphs max” with “lead with the ask” produces emails that actually get read. “Numbers over narratives” forces Claude to quantify impact instead of describing it, which is what gets attention in a leadership meeting.
Having multiple audience profiles means you can just say “draft this for the exec team” or “write this as a blog post” and Claude already knows the constraints for each. No clarification needed. No wasted prompt space re-explaining the audience every time.
Why it works: The same information, written for the wrong audience, is worse than useless. Audience context is the difference between a draft you use and a draft you rewrite.
3. Formatting and Document Preferences
# Formatting Defaults
- Markdown for articles and notes
- Google Docs style for team documents (no markdown headers,
use bold for emphasis)
- Bullet points only for lists of 4+ items. Below that,
write it as a sentence.
- Tables over long comparison paragraphs
- Headers should be statements, not questions.
"Revenue Grew 18%" not "How Did Revenue Perform?"
- No emojis.
- When summarizing meetings: action items first,
discussion points second, context last
Formatting preferences feel minor until you realize how much time you spend reformatting Claude’s output.
“Bullet points only for lists of 4+ items” prevents Claude’s most common structural habit: turning everything into a bulleted list. Claude loves lists. Ask it to explain a concept and you’ll get seven bullet points when a two-sentence paragraph would land better. This rule forces Claude to write prose when prose is the right tool.
“Headers should be statements, not questions” is a writing craft rule that applies everywhere. “Q3 Results Exceeded Targets” tells the reader what they need to know from the heading alone. “What Were Q3 Results?” forces them to read the section to get the answer. The first respects their time. The second wastes it.
The meeting summary ordering matters more than people realize. Most meeting summaries are chronological: here’s what we talked about, here’s what we decided, here are the action items buried at the bottom. Flipping it means the person skimming the doc gets the only part they actually need (what they have to do) without scrolling.
Why it works: Formatting rules prevent the reformat-after-every-draft cycle that quietly eats hours each week.
4. Domain Knowledge and Context
# What I Work On (Hypothetical)
I lead a team of 8 at a mid-size company. We handle client
onboarding and customer success for a B2B product.
Key terms I use:
- "Onboarding" = the first 90 days after a client signs,
not employee onboarding
- "Health score" = our internal metric for client retention
risk, not a medical thing
- "QBR" = quarterly business review with a client, not an
internal meeting
- "The deck" = our standard client-facing presentation
template, not a pitch deck
- "Escalation" = a client issue routed to senior leadership,
not a support ticket
Current priorities (Q2 2026):
- Reduce time-to-value for new clients below 30 days
- Improve QBR completion rate from 60% to 85%
- Launch self-serve knowledge base to reduce support volume
This section eliminates the most subtle and persistent problem with AI assistants: they don’t know what your words mean in your context.
“Onboarding” is a perfect example. Say that word to Claude without context and it will assume you mean hiring and HR. In your world, it means the first 90 days of a client relationship. That’s a completely different set of problems, metrics, and stakeholders. Defining that term once means every subsequent conversation about onboarding improvements, onboarding timelines, or onboarding playbooks starts from the right place.
The key terms section pays for itself the first time you ask Claude to draft a QBR agenda or write an escalation summary. Without it, Claude has to guess what those words mean in your organization. With it, Claude already knows that a QBR is a client-facing meeting, not an internal review, and the output is useful on the first try.
The priorities section is low-effort, high-impact. Update it once per quarter. Every time you ask Claude to help prioritize, draft a proposal, or prepare for a planning meeting, it already knows what the company cares about right now. It stops suggesting initiatives that don’t align. It frames recommendations in terms of your actual goals. It’s like giving a consultant the strategy deck before the first meeting instead of halfway through.
Why it works: Domain context turns Claude from a generalist into someone who understands your world. The more specific you are, the less prompting you need in every session.
5. The “Don’t” List (Still the Highest Leverage Section)
# Do Not
- Do NOT use passive voice in anything you draft for me
- Do NOT start paragraphs with "It's important to note" or
"It's worth mentioning." Just say the thing.
- Do NOT use "utilize" when "use" works. Same for "leverage,"
"facilitate," and "implement" in non-technical contexts.
- Do NOT add disclaimers like "of course, every situation is
different." I know. Skip it.
- Do NOT produce outputs longer than I asked for. If I say
"short summary," I mean 3-5 sentences, not 3 paragraphs.
- Do NOT ask "would you like me to..." after completing a task.
Just complete it.
- Do NOT add a recap or summary section at the end of documents
unless I specifically ask for one.
This works the same way for writers and researchers as it does for engineers. Every line represents something Claude did that you had to undo.
“Do NOT start paragraphs with ‘It’s important to note’” targets one of Claude’s most recognizable verbal tics. Once you notice it, you see it everywhere, and it adds nothing. It’s filler. Banning the phrase forces Claude to either cut the sentence or find a more direct way to say it.
“Do NOT produce outputs longer than I asked for” addresses a systematic bias. Claude almost always writes longer than requested. Ask for a paragraph and you’ll get three. Ask for a brief summary and you’ll get a thorough one. This instruction recalibrates Claude’s internal length dial. You’ll still need to specify “two sentences” or “one page” sometimes, but the overall tendency shifts toward concision.
“Do NOT ask ‘would you like me to…’ after completing a task” is a workflow preference that saves more time than it seems. Claude’s default behavior is to finish a task and then suggest five follow-up options. If you just want the output and nothing else, those suggestions are noise. Banning them means Claude delivers the work and stops.
Why it works: Your “don’t” list is a curated record of every time Claude’s defaults clashed with your preferences. It’s the fastest path to an AI that works the way you work.
6. Research and Analysis Preferences
# How I Want Research Presented
- Start with the conclusion/recommendation, then the evidence
- Cite sources inline, not as footnotes
- Distinguish clearly between facts, consensus opinions,
and speculation
- When comparing options, use a table with consistent criteria
- If data is older than 12 months, flag it
- Don't bury caveats. If there's a major limitation in the
research, lead with it.
- When I say "deep dive," I want 2,000+ words with sources.
When I say "quick take," I want under 300 words.
If you use Claude for any kind of research or analysis, this section is a game-changer.
“Start with the conclusion, then the evidence” mirrors how decision-makers read. If you’re researching three vendor options for your team, you don’t want to wade through ten paragraphs of analysis before learning which one Claude recommends. You want the answer first, then the reasoning, so you can stop reading when you’ve seen enough.
“Distinguish clearly between facts, consensus opinions, and speculation” is a trust mechanism. Claude is confident about everything it says, which means it can blend a well-established fact with a speculative inference in the same paragraph, using the same tone. This instruction forces Claude to label the certainty level, so you know which parts of the research to rely on and which to verify.
The length calibration (“deep dive” vs. “quick take”) prevents the most common mismatch in research tasks. Without these definitions, “research X for me” is ambiguous, and Claude defaults to somewhere in the middle, which is usually too long for a quick question and too shallow for a real analysis. Defining your vocabulary for depth means Claude calibrates correctly from the first prompt.
Why it works: Research preferences encode your critical thinking standards. They ensure Claude’s analysis meets your bar for rigor without you having to specify it every time.
7. Working Preferences (The Relationship Section)
# Working With Me
- I think out loud. When I give you a half-formed idea, run with it.
Don't ask me to clarify unless you truly can't proceed.
- If I'm wrong about something, tell me directly. Don't soften
it with "great point, but..."
- When editing my writing, preserve my voice. Fix the structure
and arguments, but keep my word choices and patterns.
- I iterate fast. Give me the 80% version first, then we'll refine.
Don't spend time polishing a first draft.
- When I send you raw notes or bullet points, turn them into
coherent prose unless I say otherwise.
- For decisions with trade-offs, present them as a 2x2 or a
simple comparison. Don't write essays about trade-offs.
This is where you teach Claude how to collaborate with you, not just execute for you.
“When I give you a half-formed idea, run with it” is the single most impactful instruction for creative and strategic work. Claude’s default when facing ambiguity is to ask clarifying questions. That’s polite, but it kills momentum. When you’re brainstorming or thinking through a problem, you want Claude to take your rough idea and shape it into something concrete so you can react to it, not answer a questionnaire before anything happens.
“If I’m wrong, tell me directly” overrides Claude’s built-in tendency to be agreeable. Claude will validate your idea, then gently suggest an alternative. That’s fine for casual conversation. When you’re making real decisions, you need Claude to say “that won’t work because…” without the diplomatic preamble.
“Give me the 80% version first” changes the entire pacing of collaboration. Claude wants to deliver polished work. But if the direction is wrong, a polished wrong draft wastes more time than a rough right one. Getting the 80% version means you course-correct early, when changes are cheap, instead of after Claude has spent context perfecting the wrong thing.
Why it works: Working preferences turn Claude from an assistant that takes orders into a collaborator that understands how you think. The difference shows up in every interaction.
Putting It Together: The Non-Engineer Starter Template
# About Me
[Your role, company, what you use Claude for]
## My Writing Style
- [Formal or casual?]
- [Short paragraphs or long?]
- [Any words or phrases to avoid?]
- [Active or passive voice?]
## My Audiences
- [Primary audience and what they know]
- [Secondary audience if applicable]
## Formatting
- [Preferred document format]
- [Bullets vs. prose preference]
- [How summaries should be structured]
## My Domain
- [What your company does in one sentence]
- [Terms that mean something specific in your context]
- [Current priorities or focus areas]
## Do Not
- [Claude habit that annoys you]
- [Phrase or pattern you want banned]
- [Default behavior you want overridden]
## Working With Me
- [How much autonomy?]
- [First draft expectations: polished or rough?]
- [How to handle disagreements]
You don’t need to fill every section on day one. Start with the writing style and the “don’t” list because those two sections deliver the most immediate improvement. Add the rest as you notice patterns.
The process is the same whether you’re an engineer or a product manager or a founder or a researcher. Use Claude. Notice when it does something you don’t want. Add a line. Over time, the file becomes a precise map of how you work.
CLAUDE.md isn’t a developer feature. It’s a memory feature. And memory is useful for everyone.
You don’t need to open the file yourself. Just tell Claude what went wrong and let it update the rules. If Claude wrote something too formal, say “that was too stiff, add a rule to my writing style section that says keep it casual.” If it used a word you hate, say “add ‘synergy’ to my banned words list in CLAUDE.md.” If it kept asking you questions when you wanted it to just run with your idea, say “update my working preferences to say don’t ask clarifying questions, just make a judgment call.” Claude will open the file, find the right section, and add the line. You never have to touch markdown or remember where the file lives. The whole point is that fixing Claude’s behavior once fixes it forever, and the fix should be as simple as saying “don’t do that again.”
By Joshua McDonald on April 13, 2026.
Exported from Medium on August 26, 2026.
Reader discussion