Tips and tricks

The previous guides cover the architecture of working with Claude Code. This one covers the day-to-day tactics that make individual sessions more productive. These are patterns that emerged from real usage, not theoretical best practices.

Managing Context: Compaction

What compaction is

Claude Code has a finite context window. As the session progresses, files read, commands run, and responses generated all accumulate. When the window fills up, Claude Code compacts the conversation: it summarizes earlier content to free space for new work. This happens automatically when you hit the limit.

The problem with automatic compaction is that Claude decides what to keep and what to summarize, and it does not know which parts of the conversation matter most to you. Important decisions, specific values, and the current task state can all get reduced to a one-line summary that loses the detail you need to continue working.

Compact proactively, on your terms

You are almost always better off compacting manually with /compact before the automatic compaction triggers. When you compact yourself, you control what gets preserved and what gets discarded.

The /compact command accepts an optional prompt that tells Claude what to prioritize in the summary. This is where the real value is.

/compact retain the implementation plan for the migration function and the
current test results. The earlier debugging session can be heavily summarized.

This produces a compaction that keeps the information you need for the next phase of work and discards the noise from the prior phase.

Ask Claude to write your compaction prompt

If you are deep in a session and need to compact but are not sure what to preserve, ask Claude to write the prompt for you. Claude has full visibility into the conversation and can identify what matters.

“We need to compact. Write me a compaction prompt that preserves everything I need to continue writing the integration tests. The research phase and the earlier debugging can be heavily summarized.”

Claude will produce a compaction prompt tailored to the current session state. Review it, adjust if needed, then paste it into /compact. This is faster and more thorough than writing the prompt yourself, because Claude can enumerate the specific values, file paths, and decisions that would otherwise be lost.

Compaction instructions in CLAUDE.md

For recurring session types, you can put compaction instructions directly in your project CLAUDE.md. These are read by Claude when compaction occurs (both manual and automatic) and serve as a standing set of priorities.

Our planning repo includes a # Compact instructions section that specifies:

• Always preserve: work item numbers, implementation plan paths, feature branch names, commit hashes, all decisions with reasoning, test pass/fail counts
• Preserve what was happening: the exact task in progress when compaction triggered, current debugging hypothesis if mid-debug, the most recent user request verbatim
• Do not preserve: raw file contents (re-read with Read tool), full build output (keep only the summary), exploratory reads that did not lead to findings

This acts as a safety net. Even when automatic compaction fires unexpectedly, the instructions guide what survives. Combined with proactive /compact usage, you maintain control over what the session retains.

Model Strategy

Planning vs execution: separation of concerns

The most effective pattern for model usage is not “pick one and stick with it.” It is using the right model for the right phase of work, and understanding why the separation matters.

Opus is the stronger model for reasoning and analytical work. It excels at planning, architecture, complex debugging, discovery, writing specifications, and anything that requires synthesizing information from multiple sources into a coherent design. When you need Claude to think deeply about a problem, explore tradeoffs, or produce a plan that accounts for edge cases, Opus is the right choice.

Sonnet is a highly capable model that shines at instruction following. Given a clear plan, Sonnet will execute it faithfully and is almost always capable enough to handle minor deviations that arise during implementation. It is faster and less expensive than Opus, and for execution-phase work, those savings come without meaningful quality loss.

The general pattern: do complex analysis and planning with Opus. Have it write the plan. Pass the plan to Sonnet for execution.

This separation offers a practical benefit beyond cost. Opus can sometimes overthink during execution, re-analyzing decisions that were already made during the planning phase. A well-reasoned plan gets second-guessed, alternative approaches get explored, and the work takes longer than it should because the model is treating settled questions as open ones. Sonnet does not have this tendency. It takes the plan at face value and executes it, which is exactly what you want when the planning was thorough.

The workflow in practice: start a session in Opus. Do the research, make the design decisions, write the plan (or have Opus write it to a file). Switch to Sonnet with /model sonnet. Point Sonnet at the plan and tell it to execute. Switch back to Opus if something genuinely complex comes up that Sonnet cannot resolve.

Switching models mid-session

Claude Code supports switching between models without starting a new session. /model opus, /model sonnet, /model haiku. The conversation context carries over, so you do not lose anything by switching.

This also applies to agents. When spawning a background agent for research or implementation (guide 02), you can specify the model. Agents doing straightforward file searches, pattern matching, or executing against a clear plan do not need Opus. Specifying Sonnet for those agents saves cost and often runs faster, while reserving Opus for the work that benefits from deeper reasoning.

Effort levels

/effort controls how deeply Claude thinks before responding. The levels range from low (quick, surface-level) through medium, high, and xhigh (deep reasoning, Opus only).

The strategic use: set effort high when you need Claude to reason through something complex (a multi-step plan, a tricky debugging session, a cross-cutting design decision). Drop it to medium or auto for straightforward work where deep reasoning adds latency without value.

Effort level persists until you change it. Check the current level with /effort (no argument).

Session Management

Naming sessions with /rename

By default, sessions are labeled with the last prompt you gave, which makes the session list hard to scan when you have a dozen recent sessions. /rename lets you give a session a descriptive name that persists.

/rename net10 migration batch 5
/rename april rpiv summary
/rename 181646 auto-complete service

Name your session as soon as you know what it is about. The value shows up when you need to come back to it.

Resuming sessions with /resume

/resume brings up a list of recent sessions and lets you pick one to continue. Claude Code restores the conversation state from where you left off.

This pairs directly with /rename. A session named “181646 auto-complete service” is immediately identifiable in the resume list. A session named “Can you look at the handler in…” is not.

If you know you are stepping away from a session and plan to come back, the best sequence is: compact (with a targeted prompt), rename, then close. When you resume, the context is focused and the session is easy to find.

Clearing vs compacting

/clear wipes the conversation and starts fresh in the same session. Unlike /compact, nothing is preserved. Use this when you are genuinely switching to unrelated work and the prior context is noise, not signal. If there is anything worth keeping from the current conversation, compact first.

Session continuation

When a session runs out of context entirely (even after compaction), Claude Code can continue the conversation in a new session with a summary of the prior one. The summary is automatically generated and injected at the start of the new session.

The quality of the continuation depends heavily on whether you compacted well before hitting the limit. A session that was compacted proactively with a good prompt produces a clear, focused summary. A session that ran to the wall and auto-compacted multiple times produces a degraded summary that may have lost important details.

The takeaway: if you know a session is going to be long, compact early and often rather than waiting for the automatic trigger. Each proactive compaction preserves the information you chose. Each automatic compaction preserves whatever Claude thought was important, which may not match.

Useful Commands

/cost

Shows the running cost, duration, model usage, and code changes for the current session. Useful for staying aware of how much context and budget a session has consumed, especially during long multi-phase work.

/insights

Analyzes your recent Claude Code usage and suggests ways to improve it. It looks at patterns in how you interact with Claude and identifies opportunities you may be missing. Worth running periodically, especially when you are building your workflow for the first time.

The ! prefix

Typing ! followed by a command runs it in your terminal directly, without Claude being involved. The output lands in the conversation context, which means Claude can see and reference it.

Useful for three things: interactive commands that Claude cannot run itself (like gcloud auth login), quick lookups where you want the answer without a round trip through Claude (! rg 'ToggleKey' src/), and commands that need to persist in the current shell session (environment variable exports, directory changes).

If the answer is one grep or one file read away, running it yourself with ! is faster than asking Claude and keeps the context lighter.

Strategic Patterns

Interrupt and redirect

You can interrupt Claude mid-response or mid-tool-execution by pressing Escape or sending a new message. The interruption is not rude; it is a core part of the interaction model. If you see Claude heading in the wrong direction, going down a rabbit hole, or about to do something you do not want, interrupt immediately.

The sooner you redirect, the less wasted context. Letting Claude finish a wrong approach and then correcting it costs more context than catching it early.

Non-deviation instructions for mechanical work

When Claude is executing a plan that was carefully developed in an earlier phase, you do not want improvisation. Make this explicit:

“Execute the plan. Stick to it. Do not deviate, get creative, or improvise. The plan was developed carefully and your job is to execute it as written.”

This is not insulting; it is a behavioral constraint that prevents a common failure mode. Claude’s default behavior is to improve things it touches. When the plan is the product of deliberate design, improvements are unwanted deviations. Stating this up front prevents the drift.

Background code review during implementation

When a teammate finishes implementation or you reach a natural checkpoint, kick off a code review agent in the background while you continue with other work:

“Have the code review agent review the workflow changes in the background. Pass it a reference to the story file and have it focus on functional accuracy.”

You keep working. The review report arrives when it is done. This is the background agent pattern from guide 02 applied to quality checks, and it means code review never blocks your flow.

Asking Claude to conform to existing patterns

When working in a new area of a codebase, or when integrating with a system you did not build, tell Claude to match what exists rather than inventing:

“Review the changes and make sure they conform with the existing plugin standards and style.”

This is more effective than specifying the standards yourself, because Claude can read the existing code and derive the patterns. What you are really saying is “do not be original here; be consistent.”

Saving plans and analysis to files

When Claude produces a plan, analysis, or design that you want to persist beyond the current session, ask it to write the output to a file rather than leaving it in the conversation.

“Write the plan to .context/plans/migration-plan.md.”

Content in the conversation gets compacted. Content in a file persists. If you are going to reference a plan in a future session or hand it to an agent, it needs to be in a file, not in chat history.

Keep responses short

If you only need a yes/no or a file path, say so. “Just the file path, nothing else.” Every token in Claude’s response is context that persists. Verbose answers on simple questions accumulate into context noise over the course of a session. The amount of context consumed by responses is under your control if you specify the response format.