7 Copy-Paste CLAUDE.md Templates (and How to Write the Do Not Section)

“My CLAUDE.md? I just listed the tech stack. That’s the point of it, right?”

That’s exactly what I thought at first. Astro, TypeScript, Tailwind - done. I felt organized, handed Claude Code a task, and then watched it make the same mistake three times in a row. It skipped the tests. It reached for a config file I’d specifically told myself never to touch. It announced “Fixed!” while the build was quietly broken.

A CLAUDE.md that only lists the stack is like telling a new hire “we’re a Java shop” and walking away. They now know what you use. They have no idea how you expect them to work.

So this article isn’t another “describe your stack” post. Below are seven CLAUDE.md templates I keep on hand for real client work, in copy-paste form. They lean almost entirely on two things: the order you want work done in, and the things you never want done.

Key takeaways

• The part of CLAUDE.md that actually moves the needle isn’t the tech stack. It’s the Working Rules (how to proceed) and the Do Not section (what to never do).
• There are seven templates here, one per situation: solo app, content site, API, team, legacy, automation, monorepo. Find the one closest to your repo and paste it.
• After pasting any template, adding three of your own Do Not lines is non-negotiable. That’s what stops the accidents.
• “Longer is better” is a myth. CLAUDE.md is not a manual, it’s an operations file. Short behavioral rules win.
• If Claude Code repeats the same failure three times, don’t blame the model - suspect the granularity of your CLAUDE.md.

Think of this page as the “physical catalog” that sits between the complete getting started guide and CLAUDE.md best practices. Read the theory there; come here to grab something you can actually paste.

What a good CLAUDE.md is quietly doing

A strong CLAUDE.md isn’t clever. It just quietly kills the same three recurring accidents:

• Editing the right place, but skipping a convention specific to that project.
• Making the fix, but skipping the test or check that should have run.
• Being fuzzy about what’s in scope, so the exploration sprawls and burns time.

To prevent those three, here’s the minimum set of sections I want in the file:

Section	Role	Impact
Tech stack and key commands	Set the baseline	Medium
Directory roles	Narrow the search area	Medium
Project-specific rules	Enforce local conventions	High
Working rules (the order)	Prevent skipped checks	High
Do Not	Stop the accidents	Very high

The top two are nice-to-haves. The bottom three are what actually work. In particular, the moment you write the working rules and the Do Not section, Claude Code calms down like a different person. “How to proceed” and “what not to do” - it turns out that’s the same thing you’d hand a new human teammate.

From here on it’s the real thing. Take the contents of each code block and paste it straight into your own CLAUDE.md.

1. For a solo-developer web app

If you’re running a small service by yourself, start here.

# Project Overview

Customer-facing Astro site with a small Node API.

## Tech Stack

- Frontend: Astro 5 + TypeScript
- Styling: Tailwind CSS
- Backend: Node.js 22
- Tests: Vitest

## Key Directories

- `site/src/pages/` route entrypoints
- `site/src/components/` reusable UI
- `site/src/content/` blog and docs content
- `scripts/` operational scripts

## Common Commands

- Build: `cd site && npm run build`
- Test: `npm run test`
- Search content: `rg "keyword" site/src/content`

## Working Rules

- Prefer minimal diffs over wide refactors
- Keep copy changes aligned with existing brand tone
- When editing UI, verify mobile width before calling the task done

## Do Not

- Do not rename routes unless required
- Do not delete analytics or SEO fields
- Do not claim deploy success without checking the public URL

The thing earning its keep here isn’t the stack section - it’s the last lines of Working Rules and Do Not. “Don’t say it’s done until you’ve checked mobile width.” “Don’t say the deploy succeeded until you’ve looked at the public URL.” Before I added those two lines, I shipped UI that looked fine on my laptop and overflowed the screen on every phone, more than once. Pin the success condition down in plain words and that whole class of accident disappears.

2. For a content site with articles, PDFs, and product funnels

This blog is exactly that, and a generic dev template is far too weak for any site with a revenue path.

# Project Overview

Multilingual Claude Code content site with free PDF lead magnet, Gumroad products, and consultation funnel.

## Business Goal

- Priority 1: free PDF registration
- Priority 2: Gumroad product clicks and purchases
- Priority 3: consultation inquiries

## Content Rules

- Every new article must include internal links
- Every article must include free PDF, product, and consultation CTA paths
- Use the same slug across all locales when publishing multilingual posts

## Verification Workflow

1. Build the site
2. Deploy the site
3. Open the public URL
4. Check mobile layout
5. Confirm CTA destination links

## Do Not

- Do not publish only one locale when the article requires all locales
- Do not treat build success as release success
- Do not prioritize pageviews over conversion path quality

The key is the last Do Not line: “prioritize conversion path quality over pageviews.” Without it, Claude Code drifts toward writing “articles that look like they’ll get read” and quietly mass-produces pages with a thin, neglected CTA. Just ranking the business goals and putting them at the top changed the direction of the output completely.

3. For a backend API

For an API where consistency is everything, I force two habits: “read before you change” and “put the change into words after.”

# Project Overview

Internal TypeScript API for billing and account management.

## Tech Stack

- Node.js 22
- Fastify
- PostgreSQL + Prisma
- Zod
- Vitest

## Directory Map

- `src/routes/` HTTP handlers
- `src/services/` business logic
- `src/repositories/` DB access
- `src/lib/` shared utilities

## Required Workflow

1. Read the route or service first
2. Check for existing schema and tests
3. Make the smallest safe change
4. Run unit tests or type checks
5. Summarize risk in plain English

## Do Not

- Do not bypass Zod validation
- Do not edit migrations casually
- Do not touch billing logic without tests

My favorite line in this one is Summarize risk in plain English. With that in place, Claude Code doesn’t stop at “fixed it.” It volunteers things like “this change sits close to the billing boundary, so it may affect the monthly batch job,” describing the blast radius on its own. The first move of any review gets dramatically easier.

4. For team development

The thing that actually hurts on a team isn’t a shortage of output - it’s diffs that are hard to review. This template gets ahead of that.

# Team Workflow

- Work on the current branch only
- Do not revert changes you did not make
- Call out uncertainty before making broad edits
- Prefer review-friendly patches over large rewrites

## Pull Request Expectations

- Mention user-facing behavior changes
- Mention test coverage gaps
- Flag security, permissions, and deploy risks first

## Approval Boundaries

- Ask before deploy commands
- Ask before editing CI, infra, or secrets-related files
- Ask before changing lockfiles unless required

Do not revert changes you did not make looks minor but pulls real weight. While “tidying up” nearby code, an agent will sometimes roll back something a teammate wrote on purpose. For how to slice up those approval boundaries, I went deep in the Approval and Sandbox guide - worth a read if you run a team.

5. For legacy code

When you’re modifying old code, “don’t break it” beats “make it pretty” every time.

# Legacy Repo Notes

- This codebase has inconsistent patterns
- Prefer compatibility over elegance
- Preserve behavior unless the task explicitly allows change

## Investigation First

1. Explain current behavior
2. Locate the smallest responsible file set
3. Identify risks before editing

## Do Not

- Do not rename public methods casually
- Do not introduce new frameworks
- Do not rewrite files only to match modern style

Prefer compatibility over elegance. On legacy projects this is frequently the single most important sentence in the file. Left alone, Claude Code will helpfully offer to “rewrite this in the modern style” - and on legacy code, that’s the doorway to an accident. Putting “do not rewrite files only to match modern style” in the Do Not section caps that good intention before it bites.

6. For automation and operational scripts

Sending email, deploying, writing to a third-party API - if you’re going to let it touch scripts with side effects, this is your first candidate.

# Automation Rules

- Dry-run whenever the script supports it
- Log intended side effects before executing
- Prefer idempotent operations
- Keep secrets out of logs and generated files

## Required Checks

- Confirm environment variables used
- Confirm target environment
- Confirm output path or destination service

## Do Not

- Do not send emails, deploy, or publish without explicit approval
- Do not delete generated assets unless cleanup is requested

Log intended side effects before executing - basically “spell out what you’re about to do to the world” - is the safety valve. Make it announce “I’m about to send 120 emails to production” up front, and a human gets a chance to hit the brakes. Paired with Dry-run whenever the script supports it, every irreversible operation gets one mandatory beat of hesitation.

7. For a monorepo

When multiple apps and shared packages live together, write down “which package owns this” before anything else.

# Monorepo Map

- `apps/web/` customer app
- `apps/admin/` internal admin tool
- `packages/ui/` shared UI
- `packages/config/` lint and tsconfig presets

## Ownership Rules

- Web UI work should stay inside `apps/web/` unless the task clearly needs a shared component change
- Shared package edits require checking downstream usage
- Avoid version or config churn unless necessary

## Verification

- Run the narrowest relevant build or test command first
- Describe cross-package impact before editing shared code

Just writing the Ownership Rules cuts down cross-cutting accidents a lot. What was supposed to be a small fix in apps/web/ quietly grows a hand into the shared component in packages/ui/, drags in apps/admin/, and breaks it - that’s the classic monorepo accident. Make it declare its scope up front, and add one line forcing it to “describe downstream impact” before it touches shared code.

Which template should you pick?

Seven options is enough to cause decision paralysis, so here’s the one-liner for each:

• UI or product is the center of gravity -> solo app template
• You have articles, PDFs, Gumroad funnels -> content site template
• Consistency is everything -> API template
• Coordination cost is high -> team or monorepo template
• Accident cost is high -> legacy or automation template

You don’t need to blend all seven. Blending actually makes the file longer and less effective. Take one as the base, then add only the rules that change behavior in your specific setup. That’s the right move.

Four mistakes people make with CLAUDE.md

These are landmines I stepped on personally, shared as-is.

Mistake 1: Writing it like a company wiki. “Longer explanations are better” was completely wrong. CLAUDE.md is an operations file, not a manual. Short behavioral rules beat long background essays many times over. It’s easy to forget that the reader is an AI, not a human.

Mistake 2: Listing commands but not the workflow. Writing billing -> always run tests when you touch it is overwhelmingly stronger than writing npm run test alone. A command only conveys that something exists. A workflow conveys when to use it.

Mistake 3: No Do Not section. This is the biggest waste. Don't touch .env, Don't claim deploy success without checking the public URL, Don't force push. A single sentence prevents an all-nighter. The Do Not section isn’t decoration - it’s insurance.

Mistake 4: Never updating it. If Claude Code repeats the same mistake three times, it’s usually not the model’s fault - the granularity in your CLAUDE.md is too coarse. When that happens, don’t scold it; add one line of rule. CLAUDE.md isn’t write-once - it’s a file you grow.

FAQ

Q. Where in the project should CLAUDE.md live? A. Put a file named CLAUDE.md at the repo root and Claude Code loads it automatically. In a monorepo you can also drop one in each package directory, and the nearer file takes priority. Here’s the entire “place it and confirm it’s working” routine, in two commands:

# Just place it at the repo root. Claude Code loads it automatically on startup.
cat > CLAUDE.md <<'EOF'
# Project
(paste one of the templates above here)
EOF

# Confirm it's working: ask it to read its own rules back to you
claude -p "List three Do Not rules from this project's CLAUDE.md"

For the detailed placement rules, check the official Claude Code documentation.

Q. Does it still work if I write it in my own language instead of English? A. Yes. I sometimes write the Do Not lines and workflows in Japanese. That said, keeping the template itself in English makes it easier to line up with overseas teammates and public samples, so I default to an English base here. As long as the meaning lands, either is fine.

Q. Long CLAUDE.md or short CLAUDE.md - which is better? A. Short. A good target is “fits on one screen.” When it starts growing past that, take it as a signal to split content out into a separate doc. Keep only the “rules that change behavior” in CLAUDE.md.

Q. After pasting a template, what should I add first? A. Three Do Not lines for your specific project. One line each for “the file that hurts if it’s touched,” “the operation that hurts if it’s run,” and “the lie that hurts if it’s told” (for example, reporting success without verifying). This is the highest-return addition you can make.

Q. How is CLAUDE.md different from permissions? A. CLAUDE.md is “requests and policy.” Permissions are “an enforced allow-list.” If you genuinely want a prohibition respected, use both together. I touch on how to split up permissions in the complete getting started guide too.

What I found after actually using this

Back when my CLAUDE.md only had the tech stack, I was nervous about Claude Code’s output every single time. “Will it actually run the tests this round?”

Once I added Working Rules and Do Not, that anxiety basically vanished. The one line “don’t say the deploy succeeded until you’ve looked at the public URL” in particular shows up clearly in the numbers. Before it, I’d get a “deploy is done” that was actually a 404 a few times a month; after adding it, that dropped to zero.

The conclusion is simple. CLAUDE.md isn’t a file for making the AI smarter - it’s a file for keeping the AI from causing accidents. Adding three Do Not lines beats adding more stack, and it isn’t close - it feels roughly ten times more effective. Start by pasting the template closest to your repo, then write just three Do Not lines of your own.

If you want to go deeper into the design philosophy behind CLAUDE.md itself, read CLAUDE.md best practices; for the bigger picture of building a safe “harness” before handing work to an AI, see the harness engineering guide. If you’d rather keep a template collection and config examples on hand, the free Claude Code Quick Reference Cheatsheet and the deeper Complete Claude Code Setup and Configuration Guide (covering hooks and permissions) both help. Browse everything from the product catalog, or if you want to nail down team standardization together, head to the consultation page.