Claude Code best practices: 12 habits that actually help

The one constraint behind every tip

Claude Code best practices come down to a few habits: give Claude a way to verify its work, explore and plan before you code, write specific prompts, keep CLAUDE.md short, and manage context on purpose. Most of them come from one fact: the context window fills up fast, and Claude's performance drops as it fills. Every message, every file Claude reads and every command output takes space. When the window gets crowded, Claude starts losing track of earlier instructions and makes more mistakes.

So the habits below do two things. They give Claude a clear target and a way to check it, and they keep the context window clean. These are drawn from Anthropic's official best practices, the docs for each feature, and what holds up in daily use.

1. Give Claude a way to verify its work

This is the highest-leverage habit. Claude stops when the work looks done. Without a check it can run, you become the test suite. With one, Claude does the work, runs the check, reads the result and keeps going until it passes.

Ask for evidence, not claims: the test output, the command it ran, a screenshot. Checking evidence is faster than re-running everything yourself.

2. Explore, plan, then code

Letting Claude jump straight into code often solves the wrong problem. For anything non-trivial, split the work:

1. Explore. Press Shift+Tab until the status bar shows plan mode, or start with claude --permission-mode plan. Claude reads files and answers questions without editing.
2. Plan. Ask for an implementation plan: which files change, what the flow is. Press Ctrl+G to open the plan in your editor and fix it before Claude starts.
3. Implement. Approve the plan and let Claude code against it, writing and running tests as it goes.
4. Commit. Ask Claude to commit with a clear message and open a PR.

Skip the plan when the change is small and obvious. If you could describe the diff in one sentence, just ask for it.

3. Be specific in your prompts

Claude can infer a lot, but not your constraints. Name the file, the scenario and what "done" looks like.

• "add tests for foo.py" becomes "write a test for foo.py covering a logged-out user. No mocks."
• "fix the login bug" becomes "login fails after session timeout. Check token refresh in src/auth/. Write a failing test first, then fix it."
• "add a calendar widget" becomes "look at how widgets on the home page are built, HotDogWidget.php is a good example, and follow that pattern."

Reference files with @ instead of describing where code lives, paste screenshots directly, and pipe data in with cat error.log | claude -p "explain this error". For a large feature, ask Claude to interview you with questions first and write a spec to a file, then start a fresh session to build from the spec.

4. Keep CLAUDE.md short and specific

CLAUDE.md loads into every session, so every line costs context in every request. Run /init to generate a starter, then cut hard. For each line ask: would removing this cause a mistake? If not, delete it.

Put in: commands Claude cannot guess, style rules that differ from defaults, test instructions, branch and PR conventions, setup quirks. Leave out: anything Claude can read from the code, standard conventions, long explanations. If Claude keeps breaking a rule that is in the file, the file is probably too long and the rule is getting lost.

5. Manage context on purpose

• /clear between unrelated tasks. A long session full of old work makes Claude worse at the new task.
• Clear after two failed corrections. If you have corrected the same thing twice, the context is full of failed attempts. Run /clear and write a better first prompt that includes what you learned.
• /compact <focus> when you want to keep going but free space, for example /compact Focus on the API changes.
• /btw for a quick side question. The answer never enters the conversation history.
• /context shows what is filling the window, including CLAUDE.md, MCP tools and skills.

You can also add a line to CLAUDE.md telling Claude what to keep when it compacts, such as the list of modified files and the test commands.

6. Use subagents for research

When Claude investigates a codebase it reads many files, and all of them land in your context. A subagent does that reading in its own window and returns a summary:

Use subagents to investigate how our auth system handles token refresh,
and whether we already have OAuth helpers I should reuse.

Subagents also work well as a second opinion after Claude finishes: a fresh context reviews the diff without the reasoning that produced it. Tell the reviewer to flag only issues that affect correctness or the stated requirements, or it will invent work.

7. Set permissions so you are not clicking through prompts

After the tenth approval, you stop reading and start clicking. That is worse than no prompt. Use /permissions to pre-approve commands you trust and deny what you never want:

{
  "permissions": {
    "allow": [
      "Bash(npm run lint)",
      "Bash(npm run test *)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)"
    ]
  }
}

That goes in .claude/settings.json for the team or ~/.claude/settings.json for you. Claude Code also has permission modes you switch with Shift+Tab, including Manual (asks before edits and commands), accept edits, plan, and auto mode, where a separate classifier model reviews actions and blocks risky ones. Recent versions start interactive sessions in auto mode. For OS-level isolation, /sandbox restricts what commands can touch on disk and on the network.

8. Turn repeat instructions into skills

If you have pasted the same instructions three times, make it a skill. A skill is a SKILL.md file in .claude/skills/<name>/. Only its short description loads until it is used, so a long checklist costs almost nothing until you need it. Add disable-model-invocation: true for workflows with side effects so only you can trigger them with /name:

---
name: fix-issue
description: Fix a GitHub issue
disable-model-invocation: true
---
Analyze and fix GitHub issue $ARGUMENTS.

1. Use `gh issue view` to read it.
2. Find the relevant code and implement the fix.
3. Write and run tests, then lint and typecheck.
4. Commit with a descriptive message and open a PR.

Then run /fix-issue 1234. The same goes for code review, release notes and your house writing style.

9. Use hooks for rules that must never break

CLAUDE.md is advice. Hooks are enforced. They run your scripts at fixed points, every time. Two hooks almost every project benefits from: a PostToolUse hook that runs your formatter after each edit, and a PreToolUse hook that blocks writes to files like .env or a migrations folder. You can ask Claude to write them: "Write a hook that runs eslint after every file edit."

10. Prefer CLI tools, add MCP where it pays

CLI tools are the most context-efficient way for Claude to reach outside services. Install gh and Claude can open PRs, read issues and check CI without an extra integration. For tools without a good CLI, such as an issue tracker or a design tool, connect an MCP server with claude mcp add.

11. Treat git as the safety net

• Checkpoints are not git. Claude Code snapshots files before each edit, and Esc Esc or /rewind restores code, conversation or both. But checkpoints only cover changes made through Claude's file tools, not Bash commands. Commit before risky work.
• One task per branch. Small branches make diffs reviewable and easy to throw away.
• Run sessions in parallel with worktrees. Separate git worktrees let two Claude sessions edit the same repo without colliding.
• Name sessions. Use /rename and claude --resume to come back to a workstream with its context intact.

12. Review the output like a teammate's PR

Plausible code that misses edge cases is the most common failure. Before you accept a change:

1. Read the diff with /diff, not just Claude's summary.
2. Run /code-review for a correctness pass in a fresh context, and /security-review for anything touching auth, input or data.
3. Check that tests actually exercise the new behavior, not just that they pass.
4. If you cannot verify it, do not ship it.

Common failure patterns

Keep what works

The prompts that produce great results are worth saving: the interview prompt, your review prompt, the one that writes good commit messages. Kipt keeps them in a private GitHub repo you own. Paste to save, press ⌘K to find one, and Enter to copy, with blanks like {{file}} filled in a small form. When a prompt earns a permanent place, Promote to skill turns it into a SKILL.md that installs with one npx skills add command. For ready-made starting points, see the coding prompts collection.

Source: Best practices for Claude Code and Extend Claude Code.