Duration: 60 minutes | Level: All
A curated collection of practical tips from the Claude Code community, Anthropic engineers, and discussions across GitHub, Reddit, and Hacker News. Covers prompting frameworks, context and cache management, thinking budgets, the slot machine pattern, CLAUDE.md optimization, verification loops, cost control, and language suitability.
Every effective Claude Code prompt answers four questions:
- What specifically needs to change?
- Where in the codebase? (file paths, line numbers)
- Why -- the constraint or requirement driving the change?
- How should Claude verify the result? (tests, linting, expected output)
# BAD
Fix the bug
# GOOD (answers all four)
The /api/users endpoint (src/routes/users.ts:42) returns 500 when
email is empty. Add validation to return 400 with a clear error
message. Run `pnpm test:api` to verify -- the existing test for
empty email should pass.
This is the single highest-leverage practice according to community consensus. Include test commands, linter checks, or expected outputs so Claude can verify its own work:
Implement the login form. After each change, run `pnpm test:e2e`
to verify. Don't modify the test files.
Claude performs dramatically better when it can self-check.
# BAD
Add a cache to the getUser function
# GOOD
The getUser function hits the database on every call, including repeated
calls in the same request. Add an in-memory cache with a 5-minute TTL
to reduce database load.
Claude generalizes better from motivated instructions. Instead of "never use var," say "never use var because we enforce strict ES6+ for consistency."
Put constraints at the beginning, not the end. When context gets long, the end of the prompt gets less attention. Critical constraints should also live in CLAUDE.md for persistence.
If Claude goes in the wrong direction, don't continue -- the wrong response stays in context and pollutes subsequent attempts. Use /rewind or /clear immediately, then redirect:
Stop. Don't refactor the entire module. Only fix the null check on line 15.
Just add input validation to the createUser function. Nothing else.
"Just" constrains scope effectively.
The single most impactful practice. Don't reuse sessions across unrelated tasks.
- Never manually edit files mid-session -- this invalidates the prompt cache
- Cache expires after 5-15 minutes of inactivity
- Disable format-on-save in your editor to prevent token burn from failed diffs
- Avoid reopening old sessions if the cache has expired
Don't wait for degradation, but use /compact strategically by steering what gets retained:
/compact Focus on the auth module and current test failures
When /compact fails with exhausted context, close Claude and restart with claude --continue to recover.
Build context by putting relevant codebase into the window. At each logical stopping point, hit double-escape to rewind to the context-filled checkpoint without re-spending those tokens.
# First session: implement the feature
claude
# Later: fix an issue found during testing
claude --continueclaude --add-dir /path/to/shared-libraryThis adds another directory to Claude's context without changing your working directory.
Instead of asking Claude to "read all the auth files and explain the flow" (consuming your main context), say:
Use an Explore agent to trace the authentication flow from login
to session creation. Report the key files and functions.
The research happens in isolated context.
Magic keywords trigger progressively larger thinking token budgets:
| Keyword | Budget | Use When |
|---|---|---|
| (default) | Standard | Routine coding tasks |
| "think" | Extended | Multi-step problems |
| "think hard" | Large | Complex refactoring, debugging |
| "ultrathink" | Maximum | Architecture decisions, gnarly bugs |
Use "ultrathink" for genuinely complex problems. Default mode for routine work saves significant cost.
claude --model opusOr in environment:
export CLAUDE_MODEL=opusConsistent model = consistent behavior.
Toggle fast mode for simple questions or small edits:
/fast
What does the getUser function return?
Fast mode uses the same Opus model with faster output.
claude --bareSkips loading MCP servers and other extensions. Faster startup for quick tasks.
claude --print "What's the export from src/utils/index.ts?"No interactive session overhead.
/doctor
Diagnoses installation, auth, MCP servers, and config issues.
/mcp
Shows status of all configured MCP servers.
/clear
Full context reset. Sometimes a fresh start is faster than debugging a degraded session.
My last request didn't work as expected. What went wrong?
Can you trace through your approach and identify the issue?
claude --verboseShows detailed tool call information.
/review
Always review before committing. Claude catches bugs you'll miss.
Create a new branch called "experiment/new-auth" and try implementing
the auth flow with JWT. If it doesn't work, we'll just delete the branch.
Look at the staged changes and write a conventional commit message.
Write a PR description for the current branch. Include:
- What changed and why
- How to test
- Any breaking changes
From Anthropic's internal teams:
"Save state before letting Claude work, let it run for 30 minutes, then either accept the result or start fresh rather than trying to wrestle with corrections."
Key observations:
- Claude reaches 70-80% completion on most tasks
- The remaining work requires human intervention
- Attempting fixes often underperforms versus restarting fresh
- Multiple concurrent attempts increase success rates compared to sequential refinement
Practical workflow:
- Commit before starting
- Let Claude run autonomously
- Evaluate the result
- Accept, or
git resetand try again with a different prompt
git worktree add ../attempt-1 -b attempt/v1
git worktree add ../attempt-2 -b attempt/v2
# Run Claude in each with slightly different prompts
# Pick the best resultBeyond ~60-80 lines, Claude starts ignoring parts. Be ruthlessly selective. For every line, ask: "Would Claude make a mistake without this?"
| Rule Type | Compliance Rate |
|---|---|
| Specific, concrete ("use pnpm, not npm") | ~89% |
| Detailed, well-formatted files | ~95% |
| Vague instructions ("write clean code") | ~35% |
| >200 instructions | Significant degradation |
# GOOD
Never use `var`. Use `const` by default, `let` only when reassignment is needed.
# BAD
CRITICAL (PRIORITY 0)!!!! NEVER EVER USE VAR!!!!Calm, clear directives work. Excessive urgency markers are ignored.
IMPORTANT, YOU MUST, CRITICAL, and NEVER do influence Claude's behavior in CLAUDE.md -- but only when used sparingly. Overuse dilutes their effect.
Boris from the Anthropic team recommends visual verification tools (Puppeteer/Playwright MCP) as the second-highest-leverage practice after feedback loops. It provides a 2-3x reliability improvement.
Ask Claude to review its own output before you do:
Review the code you just wrote. Look for logic errors, missing edge
cases, performance issues, and security vulnerabilities.
Complement Claude with deterministic tools:
- husky + lint-staged for pre-commit formatting
- Hooks for auto-formatting and security scanning on every edit
- Linting on commit/write provides stronger compliance than CLAUDE.md instructions alone
A recurring theme from senior developers: convert stateless services to simple CLI wrappers rather than MCP servers.
# Instead of an MCP server for Jira:
jira-cli list --project MYPROJ --status "In Progress"
# Instead of an MCP server for AWS:
aws s3 ls s3://my-bucket/CLIs are more intuitive for Claude. Write guidance into CLI --help text so Claude discovers usage naturally.
Use MCP for: authentication-heavy services, real-time data, tools needing complex state.
Audit unused MCPs: use MCP-tidy to check what you actually use. Unused servers still consume context with tool descriptions.
11.10 Hidden & Under-Utilized Features
Transfer your session to another device:
/teleport
Generates a link that opens the same session on another device (phone, tablet, another computer).
/loop 5m Check if CI has passed and notify me
/schedule "Run tests and report" --cron "0 9 * * 1-5"
Runs on Anthropic's infrastructure, not your machine.
Work on branches without leaving Claude Code:
/branch feature/new-api
Tell Claude something for later without interrupting current work:
/btw When you write tests, use Vitest not Jest
/batch "Add JSDoc comments" src/**/*.ts
Dictate instead of typing:
/voice
Run Claude as a fully autonomous agent:
claude --agent "Implement the feature described in specs/new-feature.md"/ultrareview
Launches a multi-agent cloud review of the current branch. Multiple specialized agents review in parallel.
/ultraplan
Multi-agent planning for complex features.
monorepo/
├── CLAUDE.md ← Shared conventions
├── apps/
│ ├── web/CLAUDE.md ← Web-specific
│ └── api/CLAUDE.md ← API-specific
└── packages/
└── shared/CLAUDE.md ← Shared lib specifics
Use an Explore agent to find all files that handle payment processing
# BAD
Refactor the authentication system
# GOOD
Refactor src/auth/token-validator.ts to extract the JWT verification
into a separate function. Don't change any other files.
claude --add-dir ../shared-typesEach session should have a single goal:
Session 1: Implement the data model
Session 2: Add API endpoints
Session 3: Build the frontend components
Session 4: Write tests
When exploring or learning a codebase, a longer session is fine. Use /compact regularly.
# Morning: implement the feature
claude
# ... work ...
# Escape to exit
# Afternoon: fix issues found in review
claude --continueclaude --resume
# Shows a list of recent sessions to choose from| Anti-pattern | Why it fails | Better approach |
|---|---|---|
| "Read the entire codebase" | Fills context, slow | "Find files related to X" |
| Reusing sessions for unrelated tasks | Context degradation | One task per session |
| Not providing file paths | Claude guesses wrong | Give explicit paths |
| Asking Claude to "be careful" | No effect on behavior | Set specific constraints |
| Over-approving without reading | Dangerous changes slip through | Read the diff |
| Using Claude for simple grep | Slow, wastes tokens | Use grep directly |
| Long initial prompts | Most gets compressed | Front-load the critical info |
| Editing files manually mid-session | Busts prompt cache | Let Claude do all edits |
| Continuing after a wrong direction | Wrong output pollutes context | /rewind or /clear immediately |
| Over-stuffing CLAUDE.md (>200 rules) | Compliance drops significantly | Keep under 60 lines, be selective |
| Trusting AI-generated tests blindly | Misses edge cases, weak assertions | Treat as scaffolding, review carefully |
| Wrestling with corrections vs restarting | Diminishing returns | The slot machine pattern: accept or restart |
- Python, JavaScript/TypeScript, Go -- abundant training data
- Boilerplate/scaffolding and CRUD apps
- Refactoring to modern patterns
- SQL generation and web app prototyping
- Targeted refactoring of existing code
- Rust -- complex ownership semantics
- Elasticsearch queries -- subtle DSL issues
- Race conditions and concurrency bugs
- Complex multi-file changes across very large codebases
- Greenfield exploration without clear specs
- $0.50-0.75 per focused task
- A few dollars for prototype exploration
- Developer time typically exceeds API costs substantially
Opus costs ~5x more per token. Only switch to Opus for deep analysis or complex refactoring. Tactical model switching reduces costs 60-80%.
| Task | Model | Why |
|---|---|---|
| Complex architecture | Opus | Best reasoning, better first-attempt adherence |
| Standard coding | Sonnet | Good quality, lower cost |
| Simple questions | Haiku | Fast and cheap |
Non-interactive mode is cheaper -- no session management overhead.
Less context = fewer input tokens per turn = lower cost. But steer compaction:
/compact Focus on the database migration and current errors
Subagent context is discarded after returning results. The main session only pays for the summary.
Use /cost to track spending within a session. Set budget limits. Developers who actively monitor report 40-70% cost reductions from the combination of model switching, clearing, and specific prompting.
| Agent Type | Tools to Grant |
|---|---|
| Read-only (reviewers, auditors) | Read, Grep, Glob |
| Research agents | + WebFetch, WebSearch |
| Code writers | Read, Write, Edit, Bash, Glob, Grep |
This is both a security and a cost optimization practice.
- Create a global
~/.claude/CLAUDE.md-- keep it under 60 lines - Set up your most-used permissions in
~/.claude/settings.json - Add a PostToolUse hook to auto-format files Claude writes
- Try
--barefor a quick question
Take a real task and write it using the four-question framework:
- What specifically needs to change?
- Where in the codebase?
- Why?
- How should Claude verify?
Compare the result quality against a vague version of the same prompt.
- Commit your current state
- Give Claude a medium-complexity task
- Let it run autonomously for 10-15 minutes
- Evaluate: accept or
git resetand try with a different prompt - Compare this against your usual back-and-forth approach
- Create two worktrees for independent tasks:
git worktree add ../task-a -b feature/task-a git worktree add ../task-b -b feature/task-b
- Run Claude in each with clear, focused plans
- Review each branch's output independently
- Merge the best results
Exercise 11.5: Try Hidden Features
- Try
/teleportto transfer a session - Try
/loopto monitor something - Try
/voicefor voice input - Try different thinking keywords: "think", "think hard", "ultrathink"
- Community Tips & Insights -- deep dives on every topic in this module
- Plugins, Tools & Ecosystem Directory -- curated directory of 800+ plugins and tools
- Configuration Best Practices -- production-grade config guide
- Give Claude a feedback loop -- the single highest-leverage practice
- One task per session -- the #1 productivity tip
- Use the four-question prompt framework -- what, where, why, how to verify
- Don't bust the cache -- avoid manual edits mid-session
- The slot machine pattern -- accept or restart, don't wrestle
- Git worktrees -- the power user unlock for parallelism
- Keep CLAUDE.md under 60 lines -- specific rules beat verbose docs
- Match thinking budget to task -- ultrathink for complex, default for routine
- Match model to task -- Opus for complexity, Sonnet for 80% of work
- Read the diff before approving -- trust but verify