Tom Hundley
Part 6 of 7
The difference between mediocre Claude Code results and exceptional ones often comes down to how you structure the thinking process. Rushing to implementation leads to mistakes. Deliberate planning leads to solutions that work the first time.
Anthropic's engineering team recommends the "explore-plan-code-commit" workflow—and for good reason. It mirrors how senior engineers approach unfamiliar problems: understand first, design second, implement third.
Before Claude writes a single line of code, have it understand the landscape:
"Read the authentication module and understand how sessions are managed. Don't write any code yet."
This primes Claude's context with relevant code patterns, existing implementations, and project conventions.
With understanding established, request a plan:
"Based on what you've learned, create a detailed plan for adding OAuth support. Think through edge cases before proposing solutions."
The plan should cover:
Only after confirming the plan, proceed to implementation:
"The plan looks good. Implement step 1: the OAuth provider configuration."
Work incrementally, verifying each step before moving to the next.
After implementation, commit with clear documentation:
"Create a commit with a message explaining what was added and why."
Claude Code supports explicit thinking levels that control how deeply Claude reasons about a problem.
| Mode | Trigger | Use Case |
|---|---|---|
| think | "think about this" | Basic extended reasoning |
| think hard | "think hard about this" | More deliberate analysis |
| think harder | "think harder" | Deep problem exploration |
| ultrathink | "ultrathink" | Maximum reasoning depth |
think — Default for most tasks:
"Think about how to refactor this function for better readability."
think hard — Complex decisions with tradeoffs:
"Think hard about the database schema design. Consider scalability and query patterns."
think harder — Architectural decisions:
"Think harder about how this microservice should communicate with the payment system."
ultrathink — Critical, high-stakes decisions:
"Ultrathink about the security implications of this authentication change."
Don't just add thinking keywords—structure your request to leverage them:
I need to add rate limiting to our API.
Before implementing:
1. Think hard about where in the middleware chain this should go
2. Consider both per-user and global limits
3. Think through the Redis vs in-memory tradeoffs
4. Plan the error response format
Only after you've thought through these, outline your approach.Plan mode is a special read-only state where Claude explores without executing changes.
Toggle with Shift+Tab or include "plan" in your prompt:
"Enter plan mode and explore how the authentication system works."
1. Enter plan mode (Shift+Tab)
2. Ask Claude to explore the relevant code
3. Request a detailed implementation plan
4. Review and refine the plan
5. Exit plan mode (Shift+Tab again)
6. Implement based on the approved planLong Claude Code sessions accumulate context that can degrade performance. Effective context management is essential.
Reset Claude's context when switching tasks:
/clearUse when:
Summarize context without losing it entirely:
/compactThe system creates a condensed summary of the conversation, freeing tokens while preserving key information.
Check current context usage:
/contextMonitor this to know when you're approaching limits.
Customize what happens before compaction:
{
"hooks": {
"PreCompact": [
{
"matcher": "manual",
"hooks": [
{
"type": "command",
"command": "echo 'Preserve: Current branch is main, working on feature X'"
}
]
}
]
}
}Inject critical context that should survive compaction.
"Read src/auth/ and understand the authentication flow. Don't write any code—just explain what you find."
Forces exploration before action.
"Before implementing, think about what could go wrong with this approach. Consider edge cases, error conditions, and backward compatibility."
Surfaces issues during planning, not debugging.
"Present three different approaches to solving this. For each, explain the pros, cons, and when you'd recommend it."
Gets multiple perspectives before committing to one.
"How will we verify this works correctly? What tests should exist? How do we know when we're done?"
Establishes success criteria upfront.
Advanced users run multiple Claude instances for different purposes:
Instance 1 (Writer):
"Implement the new caching layer for the API."
Instance 2 (Reviewer):
"Review the caching implementation in src/cache/. Check for race conditions, memory leaks, and cache invalidation issues."
Different context windows prevent the implementer's blind spots from affecting the reviewer.
Instance 1 (Researcher):
"Explore how similar projects handle rate limiting. Check our competitors' open-source code and industry best practices."
Instance 2 (Implementer):
"Based on this research summary [paste], implement rate limiting for our API."
Research context doesn't bloat implementation context.
For multi-step work, use markdown checklists as scratchpads:
"Create a checklist of all files that need updating for this migration. Check them off as we complete each one."
Claude maintains the checklist, providing:
Example output:
## Migration Checklist
- [x] Update User model schema
- [x] Create migration file
- [ ] Update UserService
- [ ] Update UserController
- [ ] Update tests
- [ ] Update API documentation@file.ts is shorter than pasting file contentsFor critical tasks, start fresh:
/clear
I'm starting a new task: implementing payment processing.
Here's what you need to know:
- We use Stripe
- See @src/payments/ for existing code
- Requirements are in @docs/payments.md
Begin by reading the existing code.Clean slate with only essential context.
We've covered how Claude thinks and plans. In Part 7, we'll explore how to deploy Claude Code across teams and integrate it into IDEs and CI/CD pipelines.
Up next: Part 7: IDE Integration & Enterprise Deployment — Scale Claude Code across your organization with VS Code, JetBrains, and enterprise configuration.
Discover more content: