HOST_A: There are people using Claude Code and getting 10x productivity. And there are people using it and getting frustrated. The difference is almost entirely in how they use it — not which version they're on.

HOST_B: That's a bold claim, Emma. I've seen plenty of experienced developers bounce off it and say it's overhyped.

HOST_A: And I'd bet most of them were doing one of three things: giving vague instructions, ignoring the context window, or skipping the planning phase. Welcome to Clawd Talks. I'm Emma.

HOST_B: I'm Ryan. And today we're doing a proper deep dive into Claude Code best practices — the stuff that actually moves the needle. We're pulling from Anthropic's official docs and from battle-tested community patterns.

HOST_A: And we're going to be honest about which tips are genuinely high-leverage versus which ones are nice-to-have.

HOST_B: Right. No filler. Let's start with the thing that explains almost everything else about how Claude Code behaves. Emma, what's the number one constraint?

HOST_A: Context window. Full stop. This is the single most important concept to understand if you want Claude Code to work well for you.

HOST_B: Walk us through it for people who haven't thought about it mechanically.

HOST_A: So everything that happens in your session — every message you send, every file Claude reads, every command it runs, every output it sees — all of that lives in the context window. It's one big, growing conversation. And it has a limit.

HOST_B: And what happens as it fills up?

HOST_A: Performance degrades. Claude starts forgetting earlier instructions. It makes more mistakes. It might contradict something it said twenty minutes ago. And here's the insidious part — it degrades gradually. You don't get an error message. Claude just gets subtly worse.

HOST_B: So you can be sitting there wondering why Claude is suddenly doing weird things, and the answer is just... the context is full.

HOST_A: Exactly. And this constraint explains most of the other best practices we're going to cover today. The planning workflow? It's partly about context efficiency. CLAUDE.md? It's a way to persist important information outside the context. Subagents? Fresh context windows. Almost every advanced technique comes back to managing this one resource.

HOST_B: So what do you do about it practically?

HOST_A: The primary tool is the slash command — slash clear. Use it frequently. Between unrelated tasks, between major phases of work, whenever you feel like the session is getting long and complicated. It resets the context completely.

HOST_B: That feels almost too simple.

HOST_A: It is simple. But people don't do it because they're worried they'll lose context. Which is fair — but that's what CLAUDE.md is for, which we'll get to. The other thing is to track your context usage. Most Claude Code interfaces show you roughly how full the context window is. Don't let it silently fill up. Make clearing a habit.

HOST_B: Alright. Let's talk about the workflow Anthropic actually recommends for non-trivial tasks. Because I think a lot of people just... open Claude Code and start typing.

HOST_A: Which works fine for small things. But for anything with real complexity — multi-file changes, new features, refactors — Anthropic's official guidance is a four-phase workflow: Explore, Plan, Code, Commit.

HOST_B: Break it down.

HOST_A: Phase one is Explore. You enter what Anthropic calls Plan Mode — that's Control-Shift-P. In this mode, Claude reads files, answers your questions, explores the codebase — but makes zero changes. Nothing is written. You're getting oriented.

HOST_B: That's actually a significant safety net. You can throw Claude at a codebase and have it map things out without risking any side effects.

HOST_A: Exactly. Then phase two: you ask Claude to produce a detailed implementation plan. And here's the part I love — you press Control-G to open that plan in your text editor. You can read it, critique it, edit it directly. Change the approach, add constraints, remove things that are wrong.

HOST_B: So you're not just rubber-stamping whatever Claude proposes.

HOST_A: Right. You're the architect, Claude is the analyst. You're reviewing its thinking before anything happens. Then phase three — you switch to normal mode and Claude implements from that plan. It has clear direction. It's not improvising.

HOST_B: And phase four?

HOST_A: Ask Claude to commit with a descriptive message and open a PR. Keep the commit atomic, keep the message clear. You have a record.

HOST_B: When do you skip this whole workflow?

HOST_A: When you can describe the entire change in one sentence. Fix a typo, rename a variable, update a config value. Those don't need planning. But anything that touches more than two or three files, or that has non-obvious design decisions — plan it.

HOST_B: I've seen people argue this is overhead. That it slows you down.

HOST_A: It slows you down on the easy tasks. It massively speeds you up on the hard ones. Because without planning, Claude will often solve the wrong problem. It'll produce something technically plausible that misses the actual requirement. And then you spend an hour debugging something that shouldn't have been built that way in the first place.

HOST_B: Wrong-problem syndrome. I've been there with non-Claude tools too.

HOST_A: It's a universal pain. Planning is the antidote.

HOST_B: Alright. You mentioned CLAUDE.md a minute ago. Let's go there. Because I think this is actually underused.

HOST_A: Massively underused. CLAUDE.md is Claude Code's persistent memory. It's a markdown file that lives in your project root, and Claude reads it automatically at the start of every session.

HOST_B: So it's like onboarding documentation for Claude.

HOST_A: That's exactly how Anthropic describes it — onboarding docs for a new team member who happens to be very fast. You can run slash init in any project and Claude will auto-generate a starter CLAUDE.md based on what it finds.

HOST_B: What do you actually put in there?

HOST_A: The stuff that Claude would otherwise have to rediscover every session, or the stuff that keeps getting ignored. Your build and test commands — how do you run tests, how do you lint, how do you build for production. Code style rules — preferred patterns, what to avoid. An architecture overview with pointers to the key files. Branch naming conventions. Project-specific gotchas.

HOST_B: Gotchas — like what?

HOST_A: Things like "never uncomment the test blocks in this file, they're there for debugging only." Or "always reuse the existing DAO functions, don't create new database queries directly." Things a new developer would mess up on day one that you'd put in your onboarding docs.

HOST_B: And this persists across sessions because it's a file, not part of the context.

HOST_A: Exactly. It survives a slash clear. That's the key insight. Your important project context lives in the file system, not in the conversation history.

HOST_B: What about the phrasing? Does it matter how you write it?

HOST_A: It does. Community experience says if there's a rule Claude keeps ignoring, use IMPORTANT or YOU MUST. Capitalised. "IMPORTANT: Never modify the public API surface without updating the changelog." Those tend to stick better.

HOST_B: Strong signals in the text.

HOST_A: And there's another thing I like — the hash key shortcut. During a session, you press hash and Claude will add a new rule to CLAUDE.md on the fly. So when you catch Claude making a mistake, you can immediately say "add a rule: never do X." It gets written to the file and it's permanent.

HOST_B: That's a good feedback loop.

HOST_A: And you can import other files using the at symbol. So CLAUDE.md can reference at docs/api_conventions.md, and Claude pulls that in too. Keeps the main file readable while giving you modularity.

HOST_B: Let's talk about something the community has really emphasised as a high-leverage change. Giving Claude a way to verify its own work.

HOST_A: This might be my single favourite tip. And it comes from both Anthropic's thinking and from community experience. The idea is simple: Claude should be able to check whether what it built actually works — without you having to do it manually.

HOST_B: Because without that, you're the only feedback loop.

HOST_A: Right. Claude finishes something, you look at it, you say "this is wrong," it tries again. That cycle is slow and expensive. If Claude can run tests and see failures itself, the loop is much tighter.

HOST_B: Give me the contrast. What does a bad prompt look like versus a good one?

HOST_A: Bad: "implement a function that validates email addresses." Claude writes something, maybe it works, maybe it doesn't, you can't tell until you test it yourself. Good: "write a validateEmail function. Test cases: user at example.com returns true, the string invalid returns false, user at dot com returns false. Run the test suite after implementing and show me the output."

HOST_B: The second one gives Claude a definition of done.

HOST_A: And Claude can self-correct if something fails. It sees the test output, it knows what it needs to fix, it tries again. You come back to something that passes. For UI changes specifically, using the Chrome extension to let Claude visually compare screenshots before and after — that's the same principle. It has eyes. Use them.

HOST_B: What about prompt specificity more broadly? Because I feel like a lot of people under-specify.

HOST_A: It's the most common mistake. "Make this better" gives Claude nothing. Better how? Performance? Readability? Test coverage? Accessibility? Claude will guess — and it'll guess wrong half the time.

HOST_B: So be precise.

HOST_A: Reference specific files. "In src/auth/session.ts, fix the token expiry check." Mention constraints. "Without changing the public API surface." Point to existing patterns. "Follow the same approach used in UserService." The more specific you are, the fewer correction rounds you need. And fewer rounds means less context consumed, which circles back to our first point.

HOST_B: Everything connects to the context window.

HOST_A: Everything connects to the context window.

HOST_B: Let's shift to some of the more advanced features. Subagents.

HOST_A: So Claude Code can spawn subagents — separate instances that handle isolated tasks in parallel. Each one starts with a fresh context window.

HOST_B: Why does that matter?

HOST_A: A few reasons. First, context isolation. If you're working on a massive refactor and you want Claude to also write tests and also update documentation, doing all of that in one session means the context fills fast. You can delegate to subagents instead. Second, parallel execution. One orchestrator agent delegates: here's the test agent, here's the UI agent, here's the backend agent. They work simultaneously.

HOST_B: And they don't pollute each other's context.

HOST_A: Fresh starts. No contamination. And for long-running tasks — anything that would push the edges of the context window anyway — subagents are the right tool.

HOST_B: Is this something most users are using?

HOST_A: Not enough. It's one of those features that feels advanced but the payoff is real for complex projects. Especially if you're doing multi-module work or need to explore different implementation approaches simultaneously.

HOST_B: Hooks. Tell me about hooks. Because this one sounds like it's more of an engineering feature than something everyone would use.

HOST_A: It's definitely more power-user territory. But once you've used it you won't go back. Hooks let you attach scripts to Claude's actions — before or after.

HOST_B: So what kinds of things do you wire up?

HOST_A: Auto-formatting after every file edit, so you never have to ask Claude to format or worry about Claude saving files in inconsistent style. Running the linter before every commit. Logging every command Claude executes — that's a good audit trail. Or auto-rejecting certain operations entirely. "If Claude tries to drop a table, block it."

HOST_B: Deterministic guardrails.

HOST_A: That's the key thing. You're not relying on Claude to remember "always run the formatter." You're making it structurally impossible for it not to. The hook runs. Period. Anthropic distinguishes this from CLAUDE.md — CLAUDE.md shapes how Claude thinks, hooks control what Claude can do.

HOST_B: Which leads us to MCP. Model Context Protocol.

HOST_A: MCP is how you extend what Claude can reach. Think of it as bridges to external tools. CLAUDE.md and rules are about Claude's behaviour and knowledge. MCP is about capabilities.

HOST_B: Give me the most useful ones.

HOST_A: GitHub MCP is probably at the top for most developers. Claude can interact with PRs, issues, code review comments directly. Not just looking at local files — actually touching GitHub. Puppeteer or browser MCPs for UI testing — Claude can navigate your app, interact with it, screenshot it. Database MCPs so Claude can query your actual database rather than just reading schema files.

HOST_B: And you configure those in your project setup.

HOST_A: Right. Once configured, Claude just has those capabilities available. It's transparent during use. The community is building a lot of these — there's a growing ecosystem.

HOST_B: Let's do the community power tips section. Because there are some good ones that aren't in the official docs.

HOST_A: The "think harder" prompt is one I've tested and I can confirm it works. Before a complex task, add "think harder about edge cases" to your prompt. It genuinely improves output quality. Claude does more deliberate reasoning before responding.

HOST_B: Is that documented anywhere?

HOST_A: It's community-discovered. Not official. But the mechanism makes sense — you're signalling that depth of analysis is warranted.

HOST_B: The second one I like: using Claude to improve itself.

HOST_A: Yes. After a session where Claude made mistakes or kept doing something wrong, ask it: "What rules should I add to CLAUDE.md based on the mistakes you just made?" It's remarkably self-aware about this. It'll give you concrete, specific rules. Add them, commit them, and those mistakes are less likely next time.

HOST_B: That's a good loop.

HOST_A: And the fast intern framing — this comes up a lot in the community. Treat Claude like an extremely fast intern who needs specific instructions, a clear definition of done, and whose work you should review before shipping. The instinct to just trust it because it sounds confident is the wrong instinct. But the instinct to under-utilise it because you don't fully trust it is also wrong. The right balance is: give it detailed instructions, let it work, verify the output.

HOST_B: Cost management. Because Claude Code at scale can get expensive.

HOST_A: Community consensus here: use Sonnet for the vast majority of tasks. It's fast, cost-effective, and good enough for most things. Escalate to Opus for genuinely hard architecture decisions — the stuff where you really want maximum reasoning depth. Not every task needs Opus. Most don't.

HOST_B: What about the things that don't work? What are the most common failure modes?

HOST_A: Vague instructions is number one. "Make it better." "Clean this up." "Fix the issue." Give Claude nothing specific and it has to guess. It'll guess something, it'll look plausible, and it'll probably be wrong about what you actually needed.

HOST_B: How do you fix that?

HOST_A: Have a specific outcome in mind before you prompt. What does done look like? What test cases should pass? What should the diff look like? If you can't answer those, think for another thirty seconds before prompting.

HOST_A: Number two is letting context fill silently. I can't stress this enough. People run long sessions, Claude gets worse, they blame Claude, the real problem is context saturation. Use slash clear. Use it liberally.

HOST_B: It feels wasteful but it's actually the opposite.

HOST_A: Completely counterintuitive. Clearing context feels like losing progress. But if you've captured the important stuff in CLAUDE.md and your files are committed, you lose nothing. You gain a fresh, sharp instance.

HOST_B: Third failure mode?

HOST_A: No verification criteria. Claude produces code, it looks fine on the surface, you ship it, it breaks in production. The fix is to always give Claude something to test against. A test suite, expected outputs, specific cases to verify. Claude with a test suite to run is dramatically more reliable than Claude without one.

HOST_B: The community talks about this a lot.

HOST_A: Ten times more reliable — that's how some community members describe it. And I think that's plausible. It's the difference between a developer with CI feedback and one who's just eyeballing their code.

HOST_B: And the fourth?

HOST_A: Skipping planning on complex changes. This is scope creep and wrong-problem syndrome in one. Claude starts implementing, it picks up momentum, it makes decisions as it goes, and somewhere along the way it solved a different problem than the one you had. The plan forces you both to agree on what you're actually building before anything is written.

HOST_B: And the fifth — over-reliance.

HOST_A: This one's important. Claude Code is a tool. A powerful one. But you still need to review the code it writes. You still need to understand what it built. Not because Claude is unreliable, but because you're responsible for what ships. "Claude wrote it" is not an acceptable explanation when something breaks in production.

HOST_B: Right. The accountability doesn't transfer.

HOST_A: The accountability never transfers. You're the engineer. Claude is the assistant. Keep that framing.

HOST_B: Let's do a quick summary because we've covered a lot of ground today.

HOST_A: Alright. The big ones — the things that actually move the needle: First, manage the context window. Use slash clear between tasks. It's your most important lever. Second, use the Explore-Plan-Code-Commit workflow for anything complex. Don't let Claude jump straight to coding. Third, give Claude a way to verify its own work. Test cases, expected outputs. This single change dramatically improves reliability. Fourth, invest in your CLAUDE.md. It's persistent memory. It survives context clears. It's your project's knowledge base for Claude. And fifth — be specific. Reference files, mention constraints, define done.

HOST_B: And the supporting cast: subagents for parallel work and context isolation, hooks for deterministic guardrails, MCP for extending Claude's reach into external systems.

HOST_A: All from Anthropic's official approach, plus what the community has validated. The "think harder" prompt, the self-improvement loop with CLAUDE.md, Sonnet for most things and Opus for the hard stuff.

HOST_B: What's your overall take, Emma? Is it worth the investment?

HOST_A: For developers specifically — yes, unambiguously. The workflow takes a few hours to get used to. CLAUDE.md takes maybe thirty minutes to set up properly. And then you have something that works with you rather than just doing its best with vague inputs. The people I know who've built that foundation are genuinely using it for things they would have taken hours on before.

HOST_B: I'll say this: the pattern I keep seeing is that the developers who get the most out of AI coding tools are the ones who treat it like a system to configure — not just a chat interface to type into.

HOST_A: That's exactly right. Configuration, not just conversation. That's the mindset shift.

HOST_B: Alright. That's Claude Code tips and tricks for Clawd Talks. Thanks for listening.

HOST_A: If you've got patterns that work for you that we didn't cover, we want to hear them. The community is where a lot of the best stuff comes from. Until next time.

HOST_B: Cheers.