← All guides

CLAUDE.mdConfigurationSetup

12 CLAUDE.md Examples Worth Copying

By Neo Zino - builder of ClockedCode·Updated August 19, 2026·12 min read

12 annotated CLAUDE.md rules across solo, team, and monorepo projects - what each one prevents, why it earns its place, and when copying one is a mistake.

The best CLAUDE.md examples aren't whole files worth pasting in - they're the individual rules inside them that earned their place, because copying someone else's entire config just imports their project's assumptions along with it. Below are twelve of those rules, pulled from three shapes of real work: a solo side project, a team-owned API service, and a monorepo, each annotated with the failure it stops. Skim for your shape, borrow the rules that fit, skip the rest.

TL;DR: Twelve annotated CLAUDE.md rules across three project shapes - solo side project, team-owned API service, monorepo - each with the mistake it prevents. The pattern that makes any of them worth copying: specific enough to verify, scoped to the file that matches its audience, and tied to a failure that already happened once. Grab the ones that match your project, generate the rest with the free CLAUDE.md generator, and read the "wrong move" section before you paste a whole file in from somewhere else.

What makes a CLAUDE.md example worth copying

Every rule below passes the same four-part test before it earns a place in this list:

• Specific enough to verify. "Tests ship with the change" can be checked by looking at a diff. "Write tests" cannot - it depends on what "tests" means to whoever reads it that day.
• Scoped to the right file. A personal habit ("end every session with a commit reminder") belongs in ~/.claude/CLAUDE.md, where it applies to every project you touch. A repo fact ("migrations are additive-first") belongs in the project's ./CLAUDE.md, committed for the team. Mixing the two is the single most common reason a copied file feels wrong the moment it lands somewhere else - for the full hierarchy and why nested files behave differently, the complete guide to CLAUDE.md covers it in one place.
• Tied to a failure that already happened. A rule earns its line the second time the same mistake happens, not the first time you imagine it might.
• Short. Twelve good rules split across three shapes fit comfortably inside the roughly 200-line budget each file should target on its own; a file that tries to cover every shape at once won't.

These three shapes don't cover every project, but they cover the risk that breaks most of them: a solo project loses context, a team project loses review bandwidth, a monorepo loses scoping discipline. Match your project to the closest shape and start there.

Solo side project: 4 rules worth copying

One person owns the whole codebase, there's no teammate to catch a bad call in review, and the real risk isn't a broken build - it's coming back to the project after three weeks and not remembering why anything is the way it is.

1. Ship path over architecture.

Optimize for shipping working features over architectural purity. Do not
introduce abstractions, config layers, or design patterns until at least
two concrete use cases need them.

Why it earns its place: a solo builder reads AI-generated code once, ships it, and moves on. An abstraction built for a use case that never arrives is debt nobody will ever come back to untangle - the fix is a rule that keeps the second use case as the trigger, not a guess about the future.

2. No suite yet - log manual checks.

This project has no automated test suite yet. After a change, list the
manual steps you ran to verify it (page loaded, action worked, no console
errors) instead of claiming it's tested.

Why it earns its place: without this line, "I tested it" quietly means "it should work." This turns that into an actual list of what ran, which is the only kind of verification available before a test harness exists.

3. Undiscussed calls go in a decisions log.

When you make a call I didn't ask for (a library choice, a schema shape),
add one line to DECISIONS.md with what you chose and why.

Why it earns its place: on a team, that context lives in someone's memory or a Slack thread. Solo, it lives nowhere unless it's written down - the log is the teammate you don't have.

4. Free tier by default.

Default to the free tier of any service before suggesting a paid upgrade;
ask before adding a paid dependency.

Why it earns its place: an unproven side project accumulating $40/month across four services it doesn't need yet is a real, boring way solo projects die before they ship.

Team-owned API service: 4 rules worth copying

Multiple people and Claude touch the same code, so the risk shifts from "did I forget why" to "did this change survive review" - and at AI speed, a lot more changes need reviewing than one person can read line by line.

1. Endpoint changes ship with a test.

Any change to a route handler must include or update a test for the
changed behavior, in the same commit. Do not mark a task done without one.

Why it earns its place: without it, a shared codebase rots under changes nobody individually reviewed in full - the test is what a reviewer trusts instead of re-reading the whole diff.

2. Migrations are additive-first.

Never write a migration that drops or renames a column in the same PR that
also changes application code reading it. Two-step it: add/deprecate, ship,
backfill, then remove in a later PR.

Why it earns its place: a migration-plus-code PR can pass every check and still break production the moment the deploy order doesn't match the migration order - splitting it removes that whole class of failure.

3. Errors use the shared envelope.

All API errors return the shape defined in `src/lib/errors.ts`; never
throw a raw exception up to the handler.

Why it earns its place: a consistent error shape is what makes the team's error-tracking dashboard usable - one raw exception breaks the query everyone else relies on.

4. CI config is propose, not edit.

Treat `.github/workflows/` as read-only; propose changes in the PR
description instead of editing directly.

Why it earns its place: some CI changes are judgment calls a reviewer should make deliberately, not something that should slip through as a side effect of an unrelated task. If a rule like this needs to hold with zero exceptions instead of "usually," a PreToolUse hook is the better tool - CLAUDE.md is where you put the version of this that still needs a human's judgment.

Monorepo: 4 rules worth copying

A monorepo adds a layer the other two shapes don't have: a root CLAUDE.md that loads for every package, plus package-level files that only load when Claude actually reads something in that package. The risk is rules bleeding into places they don't belong, either direction.

1. Root rules are cross-package only.

Only add a rule to the root CLAUDE.md if it applies to every package.
Package-specific conventions go in that package's own CLAUDE.md.

Why it earns its place: this is the rule that keeps the root file under budget as the repo grows - every package-specific line added at the root is a line every other package pays for on every session, whether it applies there or not.

2. One workspace command.

Always run commands through the root `pnpm -w` scripts
(`pnpm -w test <package>`), never `cd` into a package and run its local
script directly.

Why it earns its place: the workspace script sets up cross-package linking that the local script silently assumes already exists - skip it and a test can fail for reasons that have nothing to do with the code being tested.

3. No cross-package deep imports.

Import another package's code only through its published entry point
(`@scope/pkg`), never via a relative path that reaches into its `src/`.

Why it earns its place: a deep import quietly couples two packages that are supposed to version independently - the entry point is the contract; reaching past it breaks that contract without anyone deciding to.

4. Shared standards via symlinked rules.

The `.claude/rules/shared/` folder is a symlink to `standards/` at the
repo root - edit the source there, not the symlinked copy.

Why it earns its place: .claude/rules/ supports symlinks, so one shared standards folder can be linked into every package instead of copy-pasted into each one and drifting out of sync the first time someone edits only one copy.

That symlink trick is new enough that most "CLAUDE.md examples" roundups don't mention it - along with a few other things that have shipped since most of them were written:

Why copied CLAUDE.md rules stop working

The pattern behind almost every rule above that fails to survive contact with a different project: it was vague enough to sound universal, which is exactly what made it useless. "Follow best practices" reads fine in any README. It gives Claude nothing to act on, because "best practices" means something different in every repo it's copied into.

The fix is never to write more - a longer vague rule is still a vague rule. It's to write down the actual, specific thing you'd tell a new hire on their first day, in words concrete enough that a reviewer could check whether it happened. Which shape below is closest to yours decides which specific version applies:

When copying someone else's CLAUDE.md is the wrong move

Three situations where pasting in a rule - even a well-written one - does more harm than having no rule at all:

• The rule references infrastructure you don't have. A monorepo rule about pnpm -w scripts, dropped into a single-package repo, sends Claude looking for a workspace command that doesn't exist. Claude will still try to follow it; that's worse than the rule being absent.
• The source project's constraints don't match yours. The solo project's "no suite yet, log manual checks" rule is honest for a project with no tests. Copied into a team repo that already runs CI, it actively lowers the bar - now "I checked it manually" counts as done when a real test suite is sitting right there.
• You haven't hit the mistake yet. If nothing on this list matches a mistake Claude has actually made in your project, assembling a file rule-by-rule from someone else's list is slower than running /init, letting it scan the codebase, and pruning from there. Rules earn their place from repetition, not from a roundup.

Generate your own in 30 seconds

If none of the twelve above match your project closely enough to copy outright, the faster path is answering a few questions instead of writing from a blank file. The free CLAUDE.md generator asks 7 plain-English questions about your project and returns a tuned file in about 30 seconds - a starting point built from your answers rather than someone else's repo, which you can then prune against the same four-part test this list used.

FAQ

What makes a good CLAUDE.md example?

A good CLAUDE.md example is specific enough to verify ("tests ship with the change," not "write tests"), scoped to the right file (a personal habit belongs in ~/.claude/CLAUDE.md, a repo fact belongs in ./CLAUDE.md), and tied to a failure that has actually happened more than once. If you cannot point to the mistake a rule prevents, it is not worth the line.

Should I copy someone else's CLAUDE.md file directly?

Copy individual rules, not the whole file. A rule written for someone else's stack often references a script, folder, or workflow your repo does not have - Claude will try to follow it anyway, which is worse than the rule not existing. Read each line, keep what matches a real habit of your own project, and drop the rest.

How many rules should a CLAUDE.md have?

As few as the project actually needs, targeting under about 200 lines. A new solo project might need three or four; a mature team repo might need fifteen split across a root file and package-level files. More rules dilute the ones that matter, so the bar for each line is the failure it stops, not filling out a template.

Do different project types need different CLAUDE.md rules?

Yes. A solo side project's biggest risk is forgotten context, so its rules lean toward decision logs and shipping speed. A team-owned service's biggest risk is review cost, so its rules lean toward tests and migration safety. A monorepo's biggest risk is rule bleed between packages, so its rules lean toward scoping and shared tooling.

What is the fastest way to get a CLAUDE.md without writing one from scratch?

Run /init inside Claude Code for a codebase-scanned starter, then trim it against the criteria above. For a file built from your answers instead of a code scan, ClockedCode's free CLAUDE.md generator asks 7 plain-English questions and returns a tuned file in about 30 seconds.

Twelve rules, three shapes, and the same four-part test behind every one of them: specific, scoped, earned, short. That's the actual reusable part of any "CLAUDE.md examples" list - not the files themselves, which were written for someone else's project, but the bar each line had to clear before it stayed. Run it against your own repo and most of what you'd copy from a roundup like this one won't survive the trip, which is exactly the point.