How You Work

Module 2: How You Work

Identity tells Claude who you are. The next section tells it how you operate — and where the guardrails are.

This is where most CLAUDE.md files stop, and it’s where the good ones start.

Every Annoyance Is a Rule Waiting to Be Written

“How you work” means your preferences, patterns, and non-negotiables. The stuff you’d tell a human assistant in their first week:

## How I Work

- Always check what exists before creating something new
- Prefer editing existing files over creating new ones
- Use conventional commits for all git messages
- Never commit without running tests first
- When I say "ship it," I mean deploy to production
- Don't add features I didn't ask for

Each line is a rule that prevents a specific failure mode. “Always check what exists before creating something new” stops Claude from writing a utility function when one already exists three files away. “Don’t add features I didn’t ask for” stops the over-engineering that wastes your time.

The best rules come from friction. Every time Claude does something that annoys you, that’s a rule waiting to be written. Over time, your CLAUDE.md becomes a record of every lesson learned — a document that gets more valuable the longer you use it.

Try this: Think about the last three times AI output annoyed you. What happened? Write a rule that would have prevented each one.

The Gate Between Claude and the Outside World

This is the section people forget, and it’s the one that prevents disasters.

Boundaries are things Claude should never do, always do, or only do with your explicit approval. They’re your guardrails.

## Boundaries

### Never
- Expose API keys, tokens, or credentials in any output
- Push to git without my explicit approval
- Delete files without asking
- Make up URLs or statistics

### Always
- Read a file before editing it
- Verify URLs from primary sources before using them
- Use British English spelling

### Ask First
- Before running destructive commands (rm, git reset, DROP TABLE)
- Before creating new files (prefer editing existing ones)
- Before making changes visible to others (push, publish, send)

The “Ask First” category is the most important. It creates a checkpoint between Claude’s action and the outside world. Inside your local environment, Claude can be bold. But anything that touches shared systems — git remotes, email, social media, production servers — needs a gate.

Write yours now: Start with the “Never” list — what’s the worst thing that could happen? Then “Always” — what should be true of every interaction? Then “Ask First” — where do you want a human in the loop?

What This Section Is Really Doing

Rules and boundaries serve different purposes.

Rules calibrate Claude’s judgment. They encode how you prefer to work so Claude doesn’t have to guess. The more specific, the better — “use conventional commits” is more useful than “write good commit messages.”

Boundaries define the edges of autonomous action. They answer the question: where does Claude need to stop and check before proceeding? The answer to that question is different for everyone, but everyone has an answer.

Together, they give Claude a working model of how you operate — which means fewer corrections, fewer second-guesses, and more output you can actually use.

---

This section evolves. Every time Claude does something that requires a correction, add the rule that would have prevented it.