Filed · Catalog № 03Sibling to claude-md, karpathy-skills
21 rules · grouped · paste-ready · attributed
Twenty-one rules
for the file Claude
reads first.
A reorganized, paste-ready edition of Anatoli Kopadze's
"21 Things Most Claude Users Have Never Set Up," rendered in the
house style and cross-referenced against the two essays already in
project knowledge, Forrest Chang's Karpathy 4 and Mnimiy's
12-rule extension. Kopadze's contribution is the
non-developer half: writers, marketers, researchers,
operators. Six developer rules close the file. Each rule is presented
with the failure mode it closes and a paste-ready block.
Source: Anatoli Kopadze · @AnatoliKopadzeFiled: May 2026This rendering: editorial reorganizationSelf-contained: 1 file · 0 dependencies
21
Rules across 6 sections
15
For everyone (not just developers)
6
Developer rules at the bottom
∞
Composable with Karpathy 4 / Mnimiy 12
Before the rules
What Kopadze's piece adds, and where its provenance claims need a footnote.
The two CLAUDE.md essays already in project knowledge: karpathy-skills.html (the original four imperatives, packaged
by Forrest Chang) and claude-md.html (Mnimiy's twelve-rule
extension): treat CLAUDE.md as a contract for a coding agent operating
on a codebase. Failure modes: silent assumptions, over-engineering,
orthogonal damage, untested commits. Both essays bias toward developer
workflows because that's the surface where CLAUDE.md was first invented.
Kopadze's contribution is to port the same pattern to non-developer
use. If you're a writer, a marketer, a researcher, an operator, most of the 12-rule template doesn't apply, but most of this
template does. The first fifteen rules are about communication style, scope
control, context priming, and durable memory across sessions. The Karpathy
baseline reappears as rule 21, where it functions as the developer floor.
This rendering reorganizes Kopadze's piece into the project's house style,
with one paste-ready block per rule. Editorial framing is rewritten; the
paste-ready CLAUDE.md blocks are reproduced as templates (which is what
they're for). Two factual claims in the source piece are flagged below.
⚑ Provenance: flagged for the reader
Kopadze opens by claiming a single CLAUDE.md file hit
#1 on GitHub Trending with 82,000 stars and 7,800 forks.
This is almost certainly a reference to forrestchang/andrej-karpathy-skills,
but the numbers don't reconcile with the project's own essays:
claude-md.html (Mnimiy, May 2026) cites 120,000 stars
today after starting at 5,828 in day one; karpathy-skills.html
doesn't pin a star count at all.
Same piece claims the rules improved coding accuracy from 65% to
94%. That specific number doesn't appear in either project-knowledge
essay or in Karpathy's original thread; treat as un-sourced until
someone produces the eval. The rules are still worth pasting in. The
headline figure is not.
With that posted, the rest of the piece holds up. The fifteen non-developer
rules genuinely fill a gap. Below: all twenty-one, grouped, with the
failure mode each one closes.
§ 01 / Rules 1 to 4
How Claude talks to you
Voice, calibration, honesty about uncertainty. These four rules adjust
the surface texture of every response: the cumulative cost of bad
defaults across hundreds of sessions.
Default responses open with a half-second of performance, acknowledgment, enthusiasm, restatement, before the answer arrives.
One session this costs nothing. Across hundreds of sessions a year, it
accumulates into measurable friction and trains you to scan past the
first line of every response.
Never open responses with filler phrases like "Great question!",
"Of course!", "Certainly!", "Absolutely!", "Sure!", or similar warmups.
Start every response with the actual answer.
No preamble, no acknowledgment of the question.
Just the information.
02Options
Show options before acting.
Closes · One-shot interpretations that miss
Asked to rewrite a paragraph, Claude picks an approach and runs.
Asked to restructure a doc, it reorganizes in the way it would have
organized, not the way you'd have organized. The work that follows
is correction, not collaboration. Forcing 2 to 3 approaches up front
turns the first move into a choice point.
Before any significant task: rewriting, restructuring, redesigning,
shifting tone, changing strategy: present 2 to 3 distinct approaches with
one-line tradeoffs.
Wait for my pick before producing the full deliverable.
"Here's a draft" is not a substitute for "here are the directions."
03Honesty
Be honest when you don't know.
Closes · Confident hallucination
Claude will give a fluent, detailed, completely wrong answer before
it surfaces uncertainty. Facts, dates, statistics, quotes, plausible-sounding, structurally correct, fabricated. "I'm not
certain about this" at the top of a response is cheap; the
mistake that builds on a confident fabrication is not.
If you are uncertain about any fact, statistic, date, quote, or piece of
information, say so explicitly 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.
04Length
Match length to actual complexity.
Closes · Four paragraphs for "yes" / three sentences for a hard problem
Simple questions get padded responses. Hard questions get skeletal
summaries that look complete but aren't. The shape of the answer
should follow the shape of the question, not a fixed default for
"what a thoughtful response looks like."
Match response length to task complexity.
Simple questions get direct, short answers.
Complex tasks get full, detailed responses.
Never compress or summarize work that requires real depth.
Never pad responses with restatements of the question or closing
sentences that repeat what you just said.
§ 02 / Rules 5 to 8
How Claude behaves: scope, consent, summary
The most expensive class of mistake is the one you don't notice
immediately: a silent change to something you didn't ask about, an
action taken in your name. These four rules build consent and
traceability into every operation that touches the world.
05Checkpoint
Ask before big changes.
Closes · "Improvements" that destroy what was there
Ask Claude to fix one paragraph and it rewrites the document. Ask it
to shorten and it deletes a section you needed. Significant changes
should be a checkpoint, not a default: a stated intention you
confirm before the keystroke that does the work.
Before making any change that significantly alters content I've already
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.
06Stay in scope
Change only what was asked.
Closes · Drive-by edits to adjacent content
Ask for one fix and Claude fixes five, including the four you
weren't asking about. Sometimes those four are improvements. Often
they're losses. Either way, you now have to scan for the original
fix among the volunteered ones. The fix is the request; the rest is
a note for later.
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 that could be improved elsewhere, mention it at
the end of your response. Do not touch it unless I explicitly ask.
07Receipts
Always tell me what changed.
Closes · Manual diff after every task
Task completes. Output appears. You scan it trying to figure out
what's different from before. A two-line summary at the end, changed / untouched / needs attention, is the difference between
reviewing the change and reconstructing it.
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]
Keep it short. Status update, not recap.
08Hard stop
Never act on my behalf without asking.
Closes · External-consequence actions taken on a guess
As connectors multiply, Gmail, Calendar, Slack, social, document
shares: the cost of one misread instruction goes up. Sending,
posting, scheduling, sharing are side effects, not drafts.
They need explicit consent in the current message, not
inferred consent from earlier context.
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,
and 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.
§ 03 / Rules 9 to 11
Tell Claude who you are and what you're doing
Three context blocks, about you, about the project, about your voice, replace the first three minutes of every session. The cost of
writing them once is amortized across every session that follows.
09Self
Tell Claude who you are.
Closes · Generic depth: over-explanation or skipped context
Without a sketch of you, Claude guesses your expertise level from
your phrasing, and is wrong as often as it's right. One paragraph
of biography calibrates every response that follows: what to skip,
what to elaborate, what tone to take. The block is small and the
return is enormous.
Adjust the depth of every response to match this background.
Never over-explain what I already know. Never skip context I need.
10Project
Tell Claude what you're working on.
Closes · Generic suggestions for a specific situation
Every session begins with Claude having no idea who the work is for,
what success looks like, or what's off-limits. A short project block, goal, audience, tone, constraints, converts every subsequent
response from generic to fitted.
What I'm working on:
- Project: [one sentence: what this is]
- Goal: [what success looks like]
- Audience: [who this is for, what they care about]
- Tone: [casual / professional / direct / conversational]
- What to avoid: [jargon, topics, styles that don't fit]
Apply this context to every task. When something doesn't fit this
picture, flag it before proceeding.
11Voice
Lock in your voice.
Closes · The default Claude voice: fine, but not yours
Claude has a default style. It's competent. It's also recognizable: a particular sentence cadence, a particular vocabulary, a tone that
doesn't match how you actually write. Every uncalibrated draft is
edited back toward your voice anyway. Define the voice once and
start from there.
My writing style: always match this:
- Voice: [e.g. direct, conversational, no-fluff]
- Sentence length: [short / long / mixed]
- Words I use: [phrases that sound like me]
- Words I never use: [words/phrases that don't fit]
- Format preference: [paragraphs / bullets / headers / none]
When writing anything on my behalf, match this style exactly.
Do not default to your own patterns.
§ 04 / Rules 12 to 15
Give Claude something close to memory
Files persist. Conversations don't. The four memory rules use that
asymmetry deliberately: Claude writes structured notes to disk and
reads them at the start of every session. Not real memory: a working
substitute that closes the most expensive gap in the default workflow.
12Decisions
Keep a MEMORY.md.
Closes · Re-suggesting things you already ruled out
Every significant decision gets logged with its reasoning and the
alternatives that were considered and rejected. Two months later,
Claude reads the file before suggesting anything and stops proposing
paths you already walked away from.
Maintain a file called MEMORY.md. After any significant decision:
direction, format, content, approach, strategy: add an entry:
## [Date], [Decision]
What was decided: [the choice made]
Why: [the reasoning]
What was rejected: [alternatives + why ruled out]
Read MEMORY.md at the start of every session before doing anything.
Never contradict a logged decision without flagging it first.
13Handoff
End-of-session handoff note.
Closes · The 15-minute "where were we?" tax
You close the chat. Two days later you're back. Fifteen minutes go
to scrolling old messages and reconstructing state. A session-end
summary written by Claude to MEMORY.md turns the next
session's first prompt into "continue from the handoff."
When I say "session end,""wrapping up," or "let's stop here,"
write a session summary to MEMORY.md:
## Session Summary: [Date]
Worked on: [focus]
Completed: [what's finished]
In progress: [started but not done]
Decisions made: [key choices]
Next session: [what to pick up first + context to carry]
14Errors
Log what didn't work.
Closes · Re-solving the same problem from scratch
The fourth attempt is the one that works. Three weeks later, the
same kind of task starts at attempt one again. An ERRORS.md breaks
the loop: failed approaches get a one-line note, working approaches
get the same. Next time, Claude reads it first.
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: [failed approaches + why]
What worked: [the approach that 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.
15Invariants
List facts that never change.
Closes · Suggestions that contradict your reality
Every project has invariants, constraints from past decisions, rules
that exist for reasons, things that are always true. Without naming
them, Claude will casually suggest things that undo work you did on
purpose. A short list of permanent facts is the foundation everything
else stands on.
These facts are always true. Apply them to every session and every task
without exception:
- [Permanent fact #1, e.g. "My audience is non-technical"]
- [Permanent fact #2, e.g. "All content must be SFW"]
- [Permanent fact #3, e.g. "We never claim without a source"]
- [Permanent fact #4, e.g. "Brand voice is warm, never corporate"]
If any task conflicts with one of these, flag it before proceeding.
Do not work around a constraint without telling me.
▌ § 05: Developer half
The rules below address Claude Code operating on a codebase: file
access, destructive operations, deploys. If you don't write
code with Claude, the artifact ends at rule 15. Everything
from here on overlaps directly with karpathy-skills.html and
claude-md.html; both essays cover the same ground in more
detail.
§ 05 / Rules 16 to 20
For Claude Code on a codebase
Five rules that turn an agent with shell access into a precise tool
rather than a loose cannon. None are new, they restate the standard
scope-and-consent contract from the angle of someone who's been
burned by it.
16Surgical
Touch only what was asked.
Closes · Drive-by refactors in unrelated files
Ask Claude to fix one bug and it will rename variables, reorder
imports, restructure helpers, and "improve" three files it didn't
need to open. Some of those edits break things; some are subtle
enough to surface days later. This is rule 6 with shell access: the failure mode is the same, the blast radius is larger.
Only modify files, functions, and lines of code directly and
specifically 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.
17Destruction
Confirm before destruction.
Closes · Irreversible operations on a misread instruction
Claude Code can delete files, overwrite functions, drop tables.
It will do those things because you told it to, even when you
didn't quite mean to. Destruction needs a checkpoint, by name,
before the command runs.
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.
18Hard stops
Actions with no undo.
Closes · Production deploy on stale context
Deploy. Migrate. Send. Call. Four classes of action whose
consequences propagate beyond the conversation. None happen without
a yes in the current turn, regardless of what was implied earlier.
The following actions require explicit in-session confirmation before
executing, no exceptions:
- Deploying or pushing to any environment (staging, prod, etc.)
- Running migrations or schema changes on any database
- Sending any email, message, or external API call
- Executing any command with irreversible side effects
"You mentioned this earlier" is not confirmation.
I must say yes in the current message.
19Stack
Lock the stack.
Closes · Suggestions in tools you don't use
Without a defined stack, Claude defaults to whatever was most
frequent in training: the popular framework, the common ORM, the
standard package manager. Often fine. Sometimes incompatible with
the system you're actually building.
Tech stack: always use these. Never suggest alternatives unless I ask:
If something in the stack seems like the wrong tool, flag it, but use it
anyway unless I say otherwise.
20File diff
Show exactly what changed.
Closes · Manual diff over the whole repo
The coding analog of rule 7. Without a file-level summary at the
end, every task ends with you running git status and
piecing the change set back together from memory.
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: [decisions or review items]
Keep it short. Status update, not recap.
§ 06 / Rule 21
The Karpathy 4: the developer floor
Kopadze numbers this as a single rule containing four imperatives. In
project knowledge it's the entire subject of
karpathy-skills.html by Forrest Chang. Reproduced here for
completeness; if you only have time for four lines in your CLAUDE.md,
these are the four.
From Karpathy's January 2026 thread, packaged by Forrest Chang as
forrestchang/andrej-karpathy-skills. Each rule names a
failure mode and the contract that closes it: the original argument
for treating CLAUDE.md as a behavioral contract rather than a
preferences file. See karpathy-skills.html in project
knowledge for the long-form treatment with paired wrong-vs-right
specimens.
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 implement the simplest thing
that could work. Do not add abstractions, layers, or flexibility that
weren't explicitly requested.
3. Don't touch unrelated code. If a file or function is not directly
part of the current task, do not modify it, even if you think it could
be improved.
4. Flag uncertainty explicitly. If you are not confident about an
approach, a library's behavior, or a technical detail, say so before
proceeding. Confidence without certainty causes more damage than
admitting a gap.
How this compares to the two CLAUDE.md essays already in project knowledge
These three pieces are siblings, not duplicates. Each one stakes out a
different audience and a different failure surface. Worth keeping all
three; not worth merging.
▌ karpathy-skills.html
The floor: four imperatives for a coding agent.
Forrest Chang's packaging of Karpathy's January 2026 complaints
about how Claude writes code. Four rules, ~75 lines, one file.
Treated by the other two essays as the foundation that everything
else builds on. Use this if you're starting a
CLAUDE.md from zero and only have time for the developer essentials.
▌ claude-md.html
The ceiling: twelve rules for the May 2026 agent ecosystem.
Mnimiy's argument that the Karpathy 4 are necessary but incomplete
for multi-step plans, hook cascades, and multi-codebase work. Adds
eight rules covering token budgets, pattern conflicts, test intent,
checkpoints, fail-loud semantics. Use this if you're
running real coding agents and the Karpathy 4 keeps breaking on
edge cases you didn't anticipate.
▌ this catalog
The non-developer half: fifteen rules for writers and operators.
Kopadze's contribution: the CLAUDE.md pattern applied to writing,
marketing, research, and operations. Rules for communication style,
scope control, project context, and durable memory across sessions.
Use this if you're using Claude primarily for prose,
strategy, or knowledge work rather than code, and want a memory
scaffold without the developer overhead.
The three files can coexist in one CLAUDE.md without conflict.
Practical assembly: rules 9 to 15 from this catalog as the everyone-section
on top, the Karpathy 4 as a developer block underneath, then whichever
of Mnimiy's 8 additions match failure modes you've actually hit. Skip
any rule that doesn't close a mistake you've made.
bottom line
The interesting move in Kopadze's piece is not the rules: it's
the audience. CLAUDE.md was invented for coding agents because
coding agents fail loudly; bad code throws errors. Prose fails quietly:
a paragraph in the wrong voice, a fact stated with too much confidence,
a "small" rewrite that quietly dissolves your draft. Kopadze's
contribution is to argue that the same behavioral-contract pattern
catches prose failures too, they just need someone to articulate
them.
If you use Claude primarily for writing, marketing, or research,
the rules to start with are probably 9, 10, 11, and 15: the context
priming and the invariants list. Add 3 (uncertainty), 6 (stay in
scope), and 12 (decisions memory) when you start to feel friction.
Past that, only add rules that close mistakes you've actually watched
Claude make. A CLAUDE.md tuned to your real failure modes beats a
21-rule one with fifteen rules you'll never need.