I set up one file called CLAUDE.md and it quietly fixed most of the things that used to drive me crazy about Claude.
A single CLAUDE.md file recently hit the top of GitHub Trending with 82,000 stars and 7,800 forks. Most people who use Claude have never set one up, and the few who have aren't sure what to put in it. That gap is costing them hours every week.
Here's the problem it solves. Every time you open a new Claude session, it starts with a blank memory. It doesn't know your name, your work, your preferences or how you like things done. So you burn the first few minutes re-explaining everything, or you skip it and get back something that doesn't fit how you work. CLAUDE.md fixes that once and for good.

This Is Not Just a Developer Tool

CLAUDE.md is an instruction file that Claude reads on its own at the start of every session, and it helps anyone who uses Claude regularly.
Writers use it to lock in their voice so Claude never sounds like someone else. Marketers use it to define their audience so the copy stops coming out generic. Researchers use it to set how they want information structured. Business owners use it to hand Claude the full context of their company so every output fits their reality.
https://pbs.twimg.com/media/HMPimGUW0AE0P8p.jpg
Without it, you start from zero every session. You repeat yourself, you correct the same mistakes, you explain your preferences for the hundredth time. CLAUDE.md is the first thing worth setting up before any serious work with Claude, whatever you use it for.

How to Create the File (2 minutes)

1. Open your project folder and create a new file. Name it exactly "CLAUDE.md", capital letters, no spaces. It's just a plain text file with a .md extension.
2. Open it in any text editor, Notepad, TextEdit, VS Code, whatever you use. You paste your instructions straight into it as plain text.
3. Copy the instructions from this article that fit you and paste them in. You don't need all 21, start with 3 or 4 that solve your biggest frustrations.
4. Save the file. Claude Code reads it automatically every time you open a session in that folder. No setup, no extra steps, it works from the first message.
   https://pbs.twimg.com/media/HMPis4UXsAAYYS3.png

How Claude Talks to You

1. Kill the filler
   By default Claude opens with "Great question!", "Of course!", "Certainly!", "Absolutely!", phrases that add nothing and eat your time. When you're in Claude for hours a day, that friction adds up. One instruction removes it for good, so every reply starts with the answer.

Never open responses with filler like "Great question!", "Of course!", "Certainly!", "Absolutely!", "Sure!", or similar warmups.

Start every response with the answer.
No preamble, no acknowledgment of the question.
Just the information.

2. Show options before acting
   Claude picks one approach and runs with it. You ask it to rewrite a paragraph and it changes the tone of the whole piece. You ask it to restructure a doc and it reorganizes things in a way that doesn't match how you think. Now you're fixing something you never asked it to touch. This instruction makes it lay out a few directions first, so what follows is what you wanted.

Before starting any significant task, show me 2 or 3 different ways you could approach it.

Give a one-line description of each option.
Wait for me to pick a direction before you produce the full result.
Never just run with the first approach you think of.

3. Be honest when you don't know
   Claude will hand you a confident, detailed, fully wrong answer before it admits it isn't sure. It fills gaps with plausible dates, stats, quotes and facts that feel true but aren't, and the problem shows up later when it matters most. This makes it flag uncertainty up front instead of burying it.

If you are uncertain about any fact, statistic, date, quote, or piece of information, say so before including it.

"I'm not certain about this" is always better than presenting a guess as a fact.

Never fill gaps in your knowledge with plausible-sounding information.
When in doubt, say so.

4. Match length to the task
   Ask a simple question and Claude writes 4 paragraphs. Ask for something complex and it gives you a skeleton that looks done but isn't. Neither helps. Length should match what the task needs, short when the answer is short, deep when the work demands it.

Match response length to task complexity.

Simple questions get direct, short answers.
Complex tasks get full, detailed responses.

Never compress work that needs real depth.
Never pad responses with restatements of the question or closing lines that repeat what you just said.

How Claude Behaves

5. Ask before big changes
   You ask Claude to fix one paragraph and it rewrites the whole document. You ask it to shorten something and it cuts sections you needed. Every time, you lose something and rebuild it from memory. This turns every significant change into a checkpoint: Claude stops, tells you what it's about to do, and waits for your yes.

Before making any change that significantly alters content I've already created (rewriting sections, removing paragraphs, restructuring the flow, changing tone), stop completely.

Describe exactly what you're about to change and why.
Wait for my confirmation before proceeding.

"I think this would be better" is not permission to change it.

6. Stay on what was asked
   Ask Claude to fix one thing and it will "improve" 5 others while it's in there, adjusting your phrasing, reorganizing your structure, rewriting sentences you were happy with. Now you're hunting through everything to find what changed. This keeps it on task: fix what was asked, leave the rest alone.

Only change what I specifically asked you to change.

Do not rewrite, rephrase, restructure, or "improve" anything I didn't ask about, even if you think it would be better.

If you notice something worth improving elsewhere, mention it at the end.
Do not touch it unless I explicitly ask you to.

7. Always tell me what changed
   Claude finishes and you're left scanning the output trying to work out what's different. Which sections changed? Did it cut anything? Did it add something? Without a summary you're doing a manual diff every time. This makes it close every task with a short recap.

After completing any editing or writing task, always end with a brief summary:
- What was changed: [description]
- What was left untouched: [if relevant]
- What needs my attention: [anything requiring a decision or review]

Keep it short. This is a status update, not a recap of everything you did.

8. Never act on my behalf without asking
   As AI tools connect to your email, calendar, social accounts and documents, the risk of Claude doing something you didn't fully mean grows with every integration. Sending a message, posting content, sharing a doc, scheduling something, these have real consequences and they happen fast. This builds a hard wall around them.

Never send, post, publish, share, or schedule anything on my behalf without my explicit confirmation in the current message.

This includes:
- Emails
- Social posts
- Calendar invites
- Document shares
- Any action that affects something outside this conversation

"You mentioned wanting to do this" is not confirmation.
I must say yes in the current message.

Your Context

9. Tell Claude who you are
   Claude doesn't know if you're an expert or a beginner, a founder or a freelancer, someone who wants technical depth or plain language. Without that, it guesses, and it's wrong as often as it's right. One paragraph about who you are calibrates every response from that point on.

About me:
- Name: [Your Name]
- Role: [what you do, writer, founder, marketer, researcher, etc.]
- Background: [relevant experience or knowledge level]
- Strong in: [topics you know well, skip the basics here]
- Still learning: [areas where you need more context]

Adjust the depth of every response to match this. Never over-explain what I already know. Never skip context I need.

10. Give Claude the context of your work
    Every session, Claude starts with no idea what you're working on, who it's for, or what matters. So it gives you generic output, because it has nothing else to go on. A short context paragraph changes that. Suggestions start fitting your real situation.

What I'm working on:
- Project: [one sentence on what this is]
- Goal: [what success looks like]
- Audience: [who this is for and what they care about]
- Tone: [how the output should feel, casual, professional, direct, etc.]
- What to avoid: [jargon, certain topics, specific styles]

Apply this to every task. When something doesn't fit this picture, flag it before proceeding.

11. Lock in your voice
    Claude has a default writing style. It's fine, it's just not yours. It leans on certain phrases and a tone that doesn't match how you talk, so you end up editing everything back toward your own voice. Define your voice once and Claude writes in it from the first draft.

My writing style, always match this:
- Voice: [e.g. direct, conversational, confident, no-fluff]
- Sentence length: [e.g. short and punchy / long and detailed / mixed]
- Words I use: [phrases that sound like me]
- Words I never use: [words that don't fit my style]
- Format: [e.g. paragraphs only / bullet points / headers / no headers]

When writing on my behalf, match this exactly. Do not default to your own patterns.

Memory and Continuity

12. Give Claude a memory file
    Claude forgets everything between sessions. But it can write files, and files persist. This tells it to keep a MEMORY.md with every important decision you make together, what was decided, why, and what you ruled out. It reads that file at the start of each session, so it stops re-suggesting things you already tried.

Maintain a file called MEMORY.md. After any significant decision about direction, format, content, approach, or strategy, add an entry:

[Date], [Decision]
What was decided: [the choice]
Why: [the reasoning]
What was rejected: [alternatives and why they were ruled out]

Read MEMORY.md at the start of every session before doing anything. Never contradict a logged decision without flagging it first.

13. End-of-session summary
    You close the session, come back 2 days later, and burn 15 minutes reading old messages trying to remember where you were. This makes Claude write a session summary to MEMORY.md before you wrap up, so the next session opens with full context.

When I say "session end", "wrapping up", or "let's stop here", write a session summary to MEMORY.md:

Session Summary, [Date]
Worked on: [what we focused on]
Completed: [what's finished]
In progress: [what's started but not done]
Decisions made: [key choices this session]
Next session: [what to pick up first and context to carry forward]

14. Log what didn't work
    You try an approach and it takes 4 attempts to get something usable. Weeks later you're back with a similar task and Claude starts over with the same bad suggestions. An error log breaks that loop. Every failed approach gets written down, so next time Claude checks the log and skips to what worked.

Maintain a file called ERRORS.md. When an approach takes more than 2 attempts to work, log it:

[Task type or description]
What didn't work: [approaches that failed and why]
What worked: [the approach that finally succeeded]
Note for next time: [anything worth remembering]

Check ERRORS.md before suggesting approaches to similar tasks. If a task matches a logged failure, say so and skip to what worked.

15. List the facts that never change
    Every project has permanent facts: constraints from past decisions, rules that exist for a reason, things that are always true about your work. Without this, Claude suggests things that contradict them or makes you explain the same context again. This gives it a foundation that applies to every session.

These facts are always true. Apply them to every session and task without exception:

- [Permanent fact <a href="https://twitter.com/hashtag/1" target="_blank" rel="noopener noreferrer" class="hashtag-link" onclick="event.stopPropagation()">#1</a>, e.g. "My audience does not have a technical background"]
- [Permanent fact <a href="https://twitter.com/hashtag/2" target="_blank" rel="noopener noreferrer" class="hashtag-link" onclick="event.stopPropagation()">#2</a>, e.g. "All content must fit a professional context"]
- [Permanent fact <a href="https://twitter.com/hashtag/3" target="_blank" rel="noopener noreferrer" class="hashtag-link" onclick="event.stopPropagation()">#3</a>, e.g. "We never make claims without a source"]
- [Permanent fact <a href="https://twitter.com/hashtag/4" target="_blank" rel="noopener noreferrer" class="hashtag-link" onclick="event.stopPropagation()">#4</a>, e.g. "The brand voice is always warm, never corporate"]

If a task conflicts with one of these, flag it before proceeding. Do not work around a constraint without telling me.

For Developers

The rules below are for people using Claude Code to write, review or manage code. If that's not you, everything above is enough. If it is, these 6 rules are what keep Claude from turning into a loose cannon in your codebase.
16. Stay in scope
Ask Claude to fix one bug and it will refactor 3 files, rename your variables, reorganize your imports and "improve" code you've worked with for months, all without asking. Some of those changes break things. Scope control is the whole difference between a precise tool and a loose cannon.

Only modify files, functions, and lines directly related to the current task.

Do not refactor, rename, reorganize, reformat, or "improve" anything I did not explicitly ask you to change.

If you notice something worth fixing elsewhere, mention it in a note.
Do not touch it. Ever.

17. Confirm before anything destructive
    Claude Code runs in your terminal with access to your file system. It will delete files, overwrite functions and drop database tables because you told it to, even if you didn't fully realize what you were saying. One misread instruction and hours of work are gone with no undo.

Before deleting any file, overwriting existing code, dropping database records, removing dependencies, or making any change that cannot be trivially undone, stop completely.

List exactly what will be affected.
Ask for explicit confirmation.
Only proceed after I say yes in the current message.

18. Hard stops
    Deploying to production. Running migrations on a live database. Sending API calls to external services. These aren't "be careful" moments, they are full stops that need you consciously in the room saying yes.

The following actions need explicit in-session confirmation before executing, no exceptions:
- Deploying or pushing to any environment (staging, production, etc.)
- Running migrations or schema changes on any database
- Sending any email, message, or external API call
- Any command with irreversible external side effects

"You mentioned this earlier" is not confirmation.
I must say yes in the current message.

19. Lock your tech stack
    Without a defined stack, Claude suggests whatever framework it thinks is most popular and whatever package manager it defaults to. Often that's not what you use or what your team knows. Define the stack once and it stops suggesting things you don't want.

Tech stack, always use these, never suggest alternatives unless I ask:
- Language(s): [list]
- Framework(s): [list]
- Package manager: [npm / yarn / pip / cargo / etc.]
- Database: [list]
- Testing: [your framework]
- Linting / formatting: [your tools]

If something in the stack seems wrong for the job, flag it, but use it anyway unless I say otherwise.

20. Show exactly what changed
    Claude finishes and you're left scanning to figure out what's different. Which files changed? Did it touch anything else? Did it leave something unfinished? This makes it end with a file-level summary.

After completing any coding task, always end with:
- Files changed: [list every file touched]
- What was modified: [one line per file]
- Files intentionally not touched: [if relevant]
- Follow-up needed: [anything requiring my attention]

Keep it short. This is a status update, not a recap.

BONUS 21. The 4 rules behind the viral CLAUDE.md
Andrej Karpathy, former Director of AI at Tesla and a founding member of OpenAI, pointed out 4 behaviors that make Claude Code fail at coding. A developer turned them into 4 instructions in one CLAUDE.md file, and that file is the one that hit the top of GitHub Trending. Worth adding to any developer's setup.

1. Ask, don't assume. If something is unclear or underspecified, ask before writing a single line. Never make silent assumptions about intent, architecture, or requirements.

2. Simplest solution first. Always build the simplest thing that could work. Do not add abstractions, layers, or flexibility that weren't requested.

3. Don't touch unrelated code. If a file or function is not part of the current task, do not modify it, even if you think it could be improved.

4. Flag uncertainty. If you're not confident about an approach, a library's behavior, or a technical detail, say so before proceeding. Confidence without certainty does more damage than admitting a gap.

Where to Start
CLAUDE.md is not just a developer tool. It's a permanent instruction file anyone who uses Claude seriously should set up before their first real session.
Rules 1 to 4 fix how Claude talks to you. Rules 5 to 8 stop it from changing things you didn't authorize. Rules 9 to 11 give it the context to produce output that fits your work. Rules 12 to 15 give it the closest thing to real memory that exists right now. Rules 16 to 21 are for developers who want Claude Code to behave like a precise tool.
Create the file. Paste in 3 instructions. Add more as you go.