Last week I spent 45 minutes asking Claude Code variations of essentially the same question. "Can you fix the build?" Different ways each time. Different examples. Different error output. Thirty requests over 45 minutes.

Then it hit me: I was asking Claude Code to solve the same problem you solve manually every single time you work on the project.

Claude Code is the web interface at claude.ai/code. When you open it, it automatically loads a CLAUDE.md file from your project root at the start of every session.

Here's what changes everything: most teams document their architecture, but almost nobody documents their quirks—the gotchas, the edge cases, the "oh right, you have to do it THIS way or it breaks."

That's where Claude Code becomes a force multiplier.

The Quirk-Driven Advantage

Here's the difference between fumbling and flying with Claude Code:

Without documenting quirks:

• Claude encounters pnpm typecheck failing from a package directory
• Claude has to ask: "Are you in a monorepo? Are you using pnpm? Where should I run this?"
• You explain the architecture
• Claude fixes it
• Next task: same questions, same exploration, same delay

With quirks documented in CLAUDE.md:

• Claude encounters the same error
• Claude reads CLAUDE.md: "pnpm workspace puts binaries at root in node_modules/.bin/. Always run from project root."
• Claude knows instantly what went wrong
• Claude fixes it immediately
• Next task: no questions, no exploration, same instant fix

The magic isn't that Claude is smarter. The magic is that you're not re-teaching Claude the same lesson every session.

What Goes in CLAUDE.md

Document your quirks, not your features. Features are obvious. Quirks are invisible until they break.

Here's what a real pnpm monorepo CLAUDE.md looks like:

## pnpm Monorepo: Critical Commands

✅ pnpm install (from root - sets up workspace)
❌ cd packages/web && pnpm install (breaks symlinks)

✅ pnpm typecheck (from root)
❌ cd packages/web && pnpm typecheck (binaries at root, not in package)

✅ pnpm -C packages/web build (run specific package)
❌ cd packages/web && pnpm build (different behavior, can fail)

✅ pnpm --filter @workspace/utils test (run package by name)
❌ pnpm --filter utils test (partial matches fail)

Why each matters:
- pnpm workspace symlinks binaries to root node_modules/.bin/
- Running from package directory breaks PATH lookup
- -C flag changes working directory safely
- --filter requires exact package name from package.json

When you open Claude Code at claude.ai/code and encounter a pnpm error, it reads this CLAUDE.md and knows exactly what went wrong. No hypothesis. No questions.

The Force Multiplier

You already know these quirks. You solve them manually every time you work on the project. The difference between wasting 45 minutes and shipping in 5 minutes isn't that Claude Code is smarter—it's that you taught it to remember what you know.

That's the shift: from a chatbot that asks the same questions every session, to a development partner with perfect project memory.