Make Claude Code smarter with better prompts

Contents
Best practices for Claude Code documentation

Anthropic’s Best practices for Claude Code guide.

Set up your tools first

Claude Code doesn’t reimplement anything — it drives the binaries already on your machine. So install and authenticate them yourself, outside Claude Code, before you prompt anything. Have git configured, aws logged in, and whatever else the task needs (gh, docker, kubectl) installed and working when you run it by hand.

The agent inherits your shell, your config, and your credentials. If aws sts get-caller-identity works in your terminal, it works for the agent; if it doesn’t, no prompt will fix that. Get the plumbing right first, then the prompting below is what makes the results predictable.

Steps

  1. Default to opusplan. Opus thinks and plans, Sonnet writes the code. It’s the single easiest optimisation for larger coding tasks.

    /model opusplan
    

    Or in your settings file:

    {
      "model": "opusplan"
    }
    
  2. Make it investigate before it edits. Especially in unfamiliar code:

    Investigate this first. Do not make any changes yet.
    
    Find the relevant files, understand how the current implementation works,
    and tell me what you think is causing the problem.
    
  3. Have it review its own work with fresh eyes. Not Check your code. — the same context will just agree with itself:

    Now review the implementation critically.
    
    Use a fresh subagent so the review is independent.
    
    Look specifically for:
    - incorrect assumptions
    - edge cases
    - security issues
    - missing tests
    - unnecessary complexity
    
    Fix any valid findings.
    

Using subagents

Subagents run in separate contexts, so they’re ideal for large searches that would otherwise flood the main context. You rarely need custom agent definitions — just ask:

Use separate subagents to investigate:

1. the backend implementation
2. existing tests
3. the frontend integration

Have them report their findings back to you before making changes.

Keep the expensive coordinating model out of the file-grep business:

Delegate codebase exploration to a Sonnet subagent.

Have it find the relevant files and return a concise summary.
You should reason from its findings.

And for larger features:

Break this into independent tasks — backend, frontend, tests.
Fan out independent work to Sonnet subagents.
Coordinate their work and integrate everything afterwards.

Do not parallelise tasks that depend heavily on each other's unfinished changes.

Keep the context window small

A bloated context makes Claude Code slower and dumber. Keep it lean:

  • Fan out more subagents. Every large search or investigation you push to a subagent runs in its own context, so only the summary comes back — the grep noise never touches your main window.
  • Compact when it drifts. Run /compact to squeeze the history down to what still matters before it gets confused.
  • Or kill it and restart. What I usually do: once I have an AGENTS.md that captures the project context, I just kill Claude Code and start fresh. The new session reloads AGENTS.md and picks up clean — faster than nursing a stale context back to health.

Keeping the change small

Negative instructions work well. Be explicit:

Do not:
- refactor unrelated code
- rename unrelated files
- add dependencies
- change public interfaces
- modify the database schema
- disable tests
- weaken validation

Plus the catch-all: “Make the smallest change that correctly solves the problem.”

When it’s going the wrong way

The agent eventually goes the wrong way. When that happens, CRTL-C your agent and then ask it:

Stop implementing.

Re-evaluate your assumptions.

Inspect the relevant code again and explain why the current approach is wrong
before making any further changes.

If the context itself has gone stale or messy, run /clear and restate the task cleanly. That’s usually faster than arguing with a confused context.

Make it prove the work

Instead of asking Done?:

Before finishing, show me:

1. what you changed
2. why you changed it
3. what tests you ran
4. whether they passed
5. anything that remains uncertain

Or just: “Verify this works. Don’t just tell me it works.”

Give it more reach — tools, authenticated.

Claude Code is only as good as what it can touch. Authenticate its binaries (git, aws, gh), wire up MCP servers, and write skills for the workflows you repeat. Every authenticated tool is another slice of the job it can run end-to-end — as the rest of this series shows.

If you don’t, the AI agent is going to spend tokens to find out or invent a new way to do x or curl its way through.

The idiot proof formula

If you only remember one thing:

OPUSPLAN

Investigate → Plan → Implement → Review → Test

Use the words: investigate, fan out in subagents, make no mistakes.
Keep your context small!
Use many binaries! You do not need to re-ai-invent the wheel.

And phrase every instruction around:

What I want
+ What you must preserve
+ What you must not touch
+ How to approach it
+ What "done" means