8 Advanced Claude Code Tips Most Developers Never Find

Most people use Claude Code like a smarter autocomplete. They open it, type a request, get code, and close it. That works. But if you are using Claude Code for four to six hours a day, the way I do, you start uncovering an entire layer of the tool that the documentation barely mentions. These eight advanced Claude Code tips come from that kind of heavy daily use: some cut costs dramatically, some save long sessions from dying mid-task, and some turn Claude Code from a chatbot into a dev partner that already knows your codebase.

1. CLAUDE.md Is Your Most Underused Asset

Every Claude Code project has a .claude/ folder. Most developers ignore it entirely. The most impactful thing in that folder is CLAUDE.md, which Claude reads automatically at the start of every session as its system prompt for your project.

This is where you stop repeating yourself.

A well-crafted CLAUDE.md can include your stack and architecture (so Claude does not suggest the wrong framework), naming conventions and code style preferences, which files or directories are off-limits, common tasks it gets wrong and how to handle them correctly, and your testing setup.

Here is a minimal example that actually changes Claude’s behavior:

# Project: MyApp API

## Stack
- Node.js 20, TypeScript strict mode
- Prisma ORM with PostgreSQL
- Vitest for testing (NOT Jest)

## Conventions
- All services go in /src/services/
- Error handling: always use Result<T, E> pattern, never throw
- No default exports. Named exports only.

## Never modify
- /prisma/migrations/ (these are immutable)
- /src/generated/ (auto-generated, will be overwritten)

## Testing
Run tests: `npm test`
Tests live next to source files, not in /tests/

With this file in place, Claude stops suggesting Jest, stops writing export default, and knows to leave your migrations alone. You never had to say any of it in the chat.

The deeper anatomy of everything in the .claude/ folder is worth understanding fully. I wrote a separate piece on exactly what lives inside .claude/ and what each file does if you want to go further.

2. Use /compact Before Context Dies, Not After

This is the single most impactful habit change for power users.

Claude Code sessions have a context window limit. When you hit it, the session degrades badly or you are forced to start over with /clear. Most developers treat /clear as the only option when sessions get heavy. That is the wrong instinct.

The right move is /compact.

/compact asks Claude to summarize the conversation so far into a compressed form: preserving the key decisions, the current state of the code, and the outstanding tasks, while discarding the verbose back-and-forth that was eating your token budget. It is the difference between wiping a whiteboard entirely versus erasing the rough work and keeping the final formulas.

The key is timing. Do not wait until Claude starts forgetting things. Run /compact:

• After completing a major task within a session (natural checkpoint)
• When switching from one feature to another in the same session
• After a long debugging loop that finally resolved

After compacting, Claude has a clean, dense summary to work from. You can often double or triple the effective length of a single session this way.

3. Custom Slash Commands Are a Hidden Superpower

Claude Code lets you define your own slash commands by creating .md files inside .claude/commands/. This feature is barely documented and dramatically underused.

Each file becomes a slash command. The filename is the command name. The file contents are the prompt that gets sent to Claude when you invoke it.

For example, create .claude/commands/review-pr.md:

Review the current diff (git diff main) for:
1. Logic errors or edge cases that were not handled
2. Missing error handling
3. TypeScript type issues
4. Whether tests cover the new behavior
5. Performance concerns for database queries

Be specific. List file names and line numbers where relevant.
Format your response as a numbered list of issues, ordered by severity.

Now you type /review-pr and get a consistent, structured code review every single time. No prompt writing. No forgetting what to check.

Other custom commands worth building for your own workflow:

• /write-tests: Generate tests for the currently open file
• /fix-types: Find and fix TypeScript errors in the current file
• /explain-this: Get a plain-English explanation of selected code
• /document: Generate JSDoc or docstring comments for the current file
• /debug-plan: Generate a step-by-step debugging plan for the current error

Custom commands encode your workflow into one-liners. Paired with a well-written CLAUDE.md, you have essentially built a custom Claude Code persona for your project.

4. Target the Right Model for the Right Task

Here is a cost-saving tip that most Claude Code users miss entirely: not every task needs Claude Sonnet or Opus. Many common tasks, specifically boilerplate generation, renaming, formatting, adding comments, and writing simple CRUD operations, can be handled by Claude Haiku at a fraction of the cost.

The model picker in Claude Code lets you switch models mid-session. The pattern that works in practice:

If you are on the API and managing costs carefully, this matters a lot. The real cost math behind Claude Max versus direct API usage goes deep on where the numbers actually land if you want the specifics.

For Claude Max subscribers the model distinction matters less on a flat-rate plan, but even then, switching to Haiku for trivial tasks means faster responses, which compounds over a full working day.

5. Use @ References to Anchor Claude’s Attention

When Claude Code works in a large codebase, it reads a lot of files to build context. Sometimes this is exactly right. Sometimes it reads the wrong files and anchors to incorrect patterns from an adjacent service or an older module.

The @ reference syntax lets you be explicit about what Claude should focus on.

Instead of saying “update the user authentication flow,” say:

@src/auth/middleware.ts @src/auth/types.ts
Update the JWT verification to use RS256 instead of HS256.
The public key is in config.publicKey.

This tells Claude exactly which files matter and prevents it from drifting toward similar-looking files with different or outdated patterns. On large monorepos or multi-service repositories, @ references are essential.

You can also use @ to anchor Claude to documentation files:

@docs/api-spec.md
Implement the /users/{id}/preferences endpoint exactly as described in the spec.

This is one of the most practical ways to close the gap between a spec and an implementation without letting Claude guess at ambiguities.

6. Commit Before Every Major Prompt

This is not a Claude Code feature. It is a habit, and it is the habit that saves the most pain.

Before you ask Claude to do anything non-trivial (refactor this module, migrate a schema, rewrite a component), run git commit -am "wip: before claude refactor".

Claude Code is powerful enough to make sweeping changes across dozens of files simultaneously. When the result is not what you wanted, or when it partially worked but created new issues, you want a clean rollback point. Without a commit, you are manually un-doing changes across multiple files while figuring out what went wrong.

A fast shortcut: set up a git alias once and use it forever.

git config --global alias.pre-claude 'commit -am "wip: pre-claude checkpoint"'

Now git pre-claude before anything big becomes muscle memory.

7. Break Agentic Tasks Into Stages, Not One Giant Prompt

Claude Code’s agentic mode can run autonomously across many files and many steps. The temptation is to write one enormous prompt describing the entire feature and let Claude run. Resist this.

Large monolithic prompts lead to Claude making assumptions early that cascade into wrong decisions later, hard-to-audit changes spread across dozens of files, context window exhaustion mid-task, and difficult rollbacks when only part of the work was correct.

The better pattern is staged autonomy:

Stage 1: Plan first. Ask Claude to generate an implementation plan, file by file, without writing any code yet. “Here is the feature. Give me a step-by-step plan. No code yet.”

Stage 2: Review the plan. Read it. Correct any misconceptions before a single line gets written. This is your cheapest intervention point.

Stage 3: Execute in chunks. Run each stage of the plan as a separate prompt. Commit after each one. Review before continuing.

This takes slightly longer per feature but produces dramatically cleaner results. When something goes wrong, you know exactly which step caused it because you reviewed each one.

8. MCP Servers Turn Claude Code Into a Full Context Engine

This tip is for developers who want Claude Code to go beyond editing files.

Claude Code supports the Model Context Protocol (MCP), which lets you connect Claude to external tools and data sources directly from your .claude/mcp.json config. Through MCP, Claude can query your database (read-only), read your Notion or Confluence docs, pull from GitHub issues and PRs, and search your internal documentation.

A practical example with the GitHub MCP server: you can say “read issue #347 and implement the feature described in it” and Claude will actually fetch the issue, read the description, check related PRs, and start implementing. No copy-pasting. No context switching.

This is one of the fastest-moving areas of Claude Code’s development. The breakdown of Claude Code Desktop vs Claude Cowork covers how these capabilities differ across deployment contexts if you are figuring out which setup fits your workflow.

Putting It All Together

These eight tips work best as a system, not individually. Here is how they layer on top of each other:

1. CLAUDE.md gives Claude your codebase’s permanent memory
2. Custom commands encode your workflow into repeatable, zero-effort prompts
3. @ references keep Claude focused on the right files
4. Model targeting keeps costs rational for simple tasks
5. /compact extends sessions without losing critical context
6. Staged agentic tasks give you control and auditability over complex implementations
7. Git commits before major prompts provide a safety net for everything
8. MCP servers connect Claude to your actual data sources and tools

If you are evaluating Claude Code against alternatives, the Cursor vs GitHub Copilot vs Codeium breakdown for 2026 is worth reading alongside this. Claude Code wins on complex reasoning and agentic tasks, but the workflow configuration matters enormously. Without these habits, you are running at maybe 40 percent of what the tool can actually do.

The biggest unlock is treating Claude Code as infrastructure to configure rather than a tool to prompt reactively. CLAUDE.md, custom commands, and MCP integration are configuration. Staged tasks and /compact are workflow discipline. Model targeting is optimization. Together, they change what the tool fundamentally is.

Start with CLAUDE.md and one custom slash command this week. Add the rest as the habits solidify. After a month, you will not recognize how you coded before.

Ready to go deeper on the Claude ecosystem? Try Claude Code if you have not committed to a plan yet. The Max plan is where the heavy usage math starts to favor a flat rate over API billing.