Claude Code is not a search engine. You do not need to craft the perfect keyword query. But how you talk to it does shape the quality of what comes back. This chapter covers the conversation strategies that actually move the needle, drawn from real use.
How to Talk So Claude Understands
Many first-time users type something like “build me a user management system.” Claude will do it. The result will probably not be what you had in mind. Too little information forces Claude to guess.
The official Best Practices boil it down to three principles:
Be specific. Instead of “add a login feature,” say “add Google OAuth login in src/auth/, use the Better Auth library, and follow the pattern of the existing GitHub login implementation.” File paths, tech choices, reference patterns — the more specific you are, the more precise Claude’s output.
Point to existing patterns. You have a UserWidget in your project that is written exactly how you like things done? Tell Claude: “Look at src/components/UserWidget.tsx and build a CalendarWidget the same way.” Claude reads code extremely well. Giving it a model to follow is ten times more effective than a long description.
Describe symptoms, not causes. Do not say “the token refresh logic is broken” unless you have confirmed it. Say “users get a login failure after session timeout — check the token refresh flow in src/auth/.” Claude can see all the code. Let it find the root cause instead of guessing.
Some Before/After examples:
| Instead of… | Try this… |
|---|---|
| “Add search” | “Add a search box to the navbar in src/components/Header.tsx, use Fuse.js for fuzzy search against the posts array, match the styling of the existing FilterDropdown component” |
| “The API is broken, help” | “POST /api/orders returns 500 when quantity > 100. Check the input validation and database write logic in src/api/orders.ts“ |
| “Optimize performance” | “The homepage takes 4 seconds to load. The bottleneck is the Dashboard component fetching all user data at once. Switch to paginated loading, 20 items per page” |
Context Engineering: More Is Not Better
Context is not just the sentence you type. It is everything Claude sees before it responds: your CLAUDE.md, the files it has read, screenshots you have pasted, the entire conversation history.
Intuition says: give Claude as much information as possible. The opposite is true.
Anthropic’s engineering team found that too much context degrades model performance. Claude gets lost in the noise and makes confused decisions. Shrivu recommends regularly checking your context window usage with the /context command. In his monorepo, a fresh session eats roughly 20K tokens just loading basic configuration, leaving about 180K for actual work.
The core principle: do not give all information. Give the right information. Show Claude the context needed to solve the current problem, not an encyclopedia of the entire project.
You can manage context actively:
- @ file references: Use
@src/utils/auth.tsto tell Claude to read a specific file - Paste screenshots: For UI issues, a screenshot is worth ten paragraphs of description
- Pipe data:
cat error.log | claudefeeds logs directly to Claude - Give URLs: Claude can read web pages — give it an API docs link instead of copy-pasting
Let Claude Interview You
When you are tackling a large feature — say, building a payment system from scratch — do not write a requirements document first. Instead, tell Claude:
I want to build a payment feature. Before you write any code, interview me. Ask everything you need to know.
Claude will start asking: Which payment methods? Do you need refund handling? What is the expected concurrency? Webhook callbacks? Which currencies?
At least half of these questions will be things you had not considered. Claude is doing the work of a requirements analyst for you.
When the interview is done, have Claude compile the answers into a SPEC document. Then — and this is critical — open a brand new session and feed that SPEC to a fresh Claude instance for execution.
Why a new session? The interview process generates a long conversation history that eats context. A new session starts clean from the SPEC, letting Claude focus entirely on execution without the noise of the discussion that produced it.
Claude as Your Senior Engineer
Most people treat Claude Code as a code-writing tool. It is also an excellent codebase navigator.
Ask it directly:
“How does logging work in this project?”
“How do I create a new API endpoint?”
“What is the call chain for theuseAuthhook?”
“What is the difference betweensrc/lib/db.tsandsrc/utils/database.ts? Why do we have both?”
Claude reads the relevant files and gives you a structured explanation. Faster than documentation, more convenient than asking a colleague — especially when you are onboarding to a new project.
Boris’s team does exactly this. New team members do not start by reading a pile of wiki pages. They ask Claude Code directly. Its understanding of the codebase is often more accurate than outdated documentation.
Onboarding accelerator: when you join a new project, spend 10 minutes asking Claude Code: “What is the architecture? What are the core modules? How does data flow through the system?” You will save at least half a day of documentation spelunking.
Multi-Turn Conversation Strategy
Working with Claude Code is rarely a single exchange. Here are battle-tested strategies for multi-turn conversations.
Tight feedback loops. Do not wait for Claude to write 500 lines before checking the output. If the direction is wrong, correct it immediately. Correcting after 10 lines costs almost nothing. Correcting after a full feature wastes tokens and time.
Two corrections, then reset. If you have corrected Claude twice and it still is not following your intent, do not correct a third time. /clear the context and start fresh with a better initial prompt. A derailed conversation only drifts further.
Switch task, clear context. Finished a component and now need to change the database schema? /clear. Different tasks need different contexts. Carrying the previous task’s conversation history into a new task only adds noise. Shrivu’s approach: /clear then run a custom /catchup command that has Claude read the current git branch’s changes to rebuild context.
Use subagents for research. Sometimes you need Claude to investigate before building: “look into how this library works,” “analyze how competitors implement this.” Use subagents for these research tasks. The findings return to your main session; the intermediate thought process stays out of your main context.
One warning from Shrivu: do not rely on /compact. It is opaque and error-prone. When you need a restart, use /clear, not /compact.
Effort Level: Do Not Cheap Out
Claude Code has four effort levels: Low, Medium, High, and Max. They control how much reasoning power Claude invests in your task.
| Level | Best For | Characteristics |
|---|---|---|
| Low | Simple formatting, renaming | Fast but error-prone |
| Medium | Daily dev tasks | Lighter than default |
| High | Complex features, debugging | The default — Boris uses this |
| Max | Extremely complex architecture decisions | Unlimited reasoning tokens, slowest but deepest |
High is the default. Boris never turns it down. His reasoning matches his model choice: Claude thinks deeper, needs fewer corrections, and the overall efficiency is higher.
Many people think “this task is simple, I will save time on Low.” Then Low produces a mistake, and the time spent correcting it exceeds what High would have taken to get it right the first time.
If you are on a Max plan, High is already the default. Do not turn it down to save a few seconds. Fixing low-effort mistakes costs far more than a few seconds.
Three Principles for Asking
The art of talking to Claude Code comes down to three words.
Specific. File names, line numbers, function names, expected behavior — give them whenever you can. More specific instructions produce more precise output.
Point. Your codebase already has examples of good work. Point Claude at them. “Do it like that one” is 100 times more effective than “make it look nice.”
Restrained. One thing at a time. If the task is big, break it into steps and confirm each step before moving on. Stuff three unrelated requests into one message, and Claude will probably only do one of them well.
A useful mental model: treat Claude like a very smart colleague who just joined last week. They are highly capable but do not know your project’s history and conventions. The more precise the context you give them, the closer their output matches what you expect.
The core insight of this chapter: good conversations with Claude Code are not about clever prompts. They are about precise context. Be specific about what you want, let Claude interview you to fill blind spots, keep things clean with /clear, and never turn down the effort level. The real skill is not learning more prompt techniques — it is developing an intuition for how to collaborate with Claude, built through practice.