Claude Code Best Practices

Five habits separate engineers who ship with Claude Code: PRDs, modular CLAUDE.md rules, custom slash commands, /clear resets, and a system-evolution mindset.

Without a PRD, context drifts. Claude starts making architectural calls you never discussed. It adds OAuth because "that's what most auth systems include." It builds a password reset flow because it seemed relevant. You spend more time course-correcting than building.

With a PRD, every session has guardrails. You tell Claude "read the PRD, then implement the signup flow." It knows exactly what is in scope, what is not, and what patterns to match. When one section lands, you ask "based on the PRD, what should we build next?" and it stays on track.

This works on existing projects too. On greenfield work, the PRD is your MVP brief. On brownfield work, the PRD documents what you already have and then spells out what you want next. Different starting points, same structure.

The PRD also solves the multi-session problem. Claude Code has no memory between conversations, but your PRD does. Each new session opens with the same document, so you pick up exactly where you left off.

2. Modular Rules Architecture

Most developers make the same mistake with their CLAUDE.md: they dump everything into one file. Tech stack, coding conventions, testing rules, deployment procedures, API patterns. One giant wall of instructions.

The issue is context waste. Claude loads your whole CLAUDE.md at session start, and every token in it competes for attention. Your React patterns load while you debug a database migration. Your deployment rules load while you write unit tests.

A better approach: keep CLAUDE.md lean and point to task-specific docs.

About 15 lines. It covers the universal rules that apply to every task. Detailed knowledge lives in separate files Claude only loads when the task calls for it.

The folder layout:

Compare this to the "everything in one file" habit where 200+ lines of instructions sit in CLAUDE.md. That file burns context on every session, relevant or not. The modular approach loads domain knowledge on demand.

3. Command-ify Everything

If you prompt something twice, it should be a command.

A command in Claude Code is a markdown file in .claude/commands/ that defines a reusable workflow. When you type /commit, Claude reads the command file and follows the instructions. No retyping. No forgotten steps.

Here is what a simple command looks like:

Save that as .claude/commands/commit.md and you never write commit instructions again.

Five starter commands worth building:

• /commit for consistent, well-formatted git commits
• /review for code review against your project's standards
• /plan for generating a structured implementation plan before writing code
• /prime for loading session context at the start of each conversation
• /execute for running a plan document created in a previous session

Each command takes five minutes to write and saves hundreds of prompts over a project's lifetime. They also enforce consistency. Your commits always follow the same format. Your code reviews always check the same things. The compound effect is real.

4. The Context Reset

This is the one habit that feels counterintuitive: planning and execution should happen in separate conversations.

The flow:

1. Plan session: research the problem, discuss tradeoffs, explore approaches. Claude outputs a structured plan document (a markdown file saved to your project).
2. Clear context: exit the conversation entirely. Kill the session.
3. Execute session: start fresh. Feed Claude only the plan document from step one. Nothing else.

Why go through this? Because context window degradation is real.

After a long planning conversation, Claude's context is full of exploratory tangents, rejected approaches, and intermediate reasoning that no longer applies. When you then say "okay, now build it," Claude carries all that noise into execution. It might avoid an approach you discussed and discarded, even if your final plan recommends it. It might carry forward assumptions from early in the conversation that you corrected later.

A fresh context with just the plan means Claude starts execution with a clean head. No baggage from the planning phase. No stale assumptions. Just the spec. And because you are not burning tokens on planning history, Claude has more room to reason about implementation details and self-check its work.

The plan document has to stand alone. A good plan includes the feature description, user story, architecture context, references to the relevant components, and a task-by-task breakdown. If Claude needs to ask clarifying questions during execution, your plan has gaps.

In practice:

The plan document acts as a handoff between your planning brain and your execution brain. Both sessions are sharper because neither one is trying to do both jobs.

5. System Evolution Mindset

Every bug is a system failure, not a one-time mistake. The gap between good and great agentic engineering is whether you fix the instance or fix the system.

Three real examples:

Wrong import style. Claude keeps using relative imports (../../components/Button) instead of your path aliases. You could fix each one by hand. Or you add one line to CLAUDE.md: "Always use @ path aliases for imports, never relative paths." The bug never comes back.

Forgot to run tests. You finish a feature, push to CI, tests fail because Claude never ran them locally. Instead of remembering to prompt "run tests" every time, you update your /execute command template to include a mandatory testing step at the end of every implementation. Now every execution session finishes with a test run by default.

Wrong auth flow. Claude builds JWT auth with cookies when your project uses bearer tokens in headers. It happened because there is no reference document for your auth patterns. You create .claude/skills/auth/SKILL.md with your token format, header conventions, and middleware patterns. Next time anyone (including future you) works on auth, Claude loads the right patterns automatically.

The pattern is always the same: something goes wrong, you trace it back to a missing instruction or a missing reference, and you add it to your system. Over weeks, your configuration gets tighter. Claude makes fewer mistakes because your system has fewer gaps.

A practical way to build the habit: after every feature, ask Claude to review your rules and commands, compare the execution against the plan, and suggest what to improve. "Read CLAUDE.md and the commands we used. What rules or process changes would have prevented the issues we hit?" That turns system evolution from an afterthought into a routine step.

This is what separates a Claude Code user from a Claude Code practitioner. The user fixes bugs. The practitioner fixes the system that produced the bug.

Putting It All Together

These five habits are not independent tips. They form a system.

The PRD scopes your work. Modular rules keep context clean. Commands kill repetition. Context resets keep sessions sharp. System evolution makes the whole thing better over time.

None of this needs new tools or expensive setups. It is a set of habits that compound with every project you build. Start with whichever one addresses your biggest pain today, and add the rest as you go.