Claude Code Best Practices: Community Secrets for 10x Productivity
Claude Code has quietly become the tool of choice for AI-native developers and knowledge workers alike. But between the official documentation and the YouTube tutorials, there's a gap: the real practices that separate productive users from those "donating money to Anthropic."
This guide synthesizes insights from Claude Code's creator Boris Cherny, product discovery expert Teresa Torres, and community educators like Greg Isenberg and Ross Mike—combining official capabilities with battle-tested workflows that actually work.
The Core Insight: Input Quality Determines Output Quality
Let's start with the most important lesson, articulated by Ross Mike on the Greg Isenberg show:
"However good your inputs are will dictate how good your output is. We're getting to a point where the models are so freakishly good that if you are producing quote unquote slop, it's because you've given it slop."
This isn't motivational fluff—it's the fundamental principle underlying every best practice in this guide. Claude's capabilities have crossed a threshold where quality problems trace back to human instructions, not model limitations.
Part 1: The ask_user_question Secret
Most Claude Code users don't know this tool exists. Those who do consider it the single most important feature for non-trivial projects.
What It Does
When planning a feature, Claude can interview you with multiple-choice questions about specifics you'd never think to specify. Instead of accepting Claude's generic planning questions, the ask_user_question tool forces granular thinking about:
- Database choices and data models
- UI/UX layouts and interactions
- Cost handling and edge cases
- Error states and recovery flows
- Testing strategies
How to Invoke It
Simply ask Claude to interview you about your project:
> Interview me about this feature: user authentication system
Or be more specific:
> Before implementing the payment flow, use ask_user_question to understand my requirements for:
> - Payment providers
> - Currency handling
> - Refund policies
> - Error recovery
Claude will present multiple-choice questions, letting you think through decisions before any code is written.
Why This Matters
Greg Isenberg's key insight: "A lot of times people will describe a product, not describe features, and will be frustrated with AI." The ask_user_question approach forces you to think in concrete features with clear acceptance criteria.
The investment in upfront questioning prevents expensive iteration loops later. As Ross Mike puts it: "If you have a terrible plan, if you have a terrible PRD, this doesn't matter. You're just donating money to Anthropic."
Part 2: Context Architecture (The Teresa Torres Method)
Teresa Torres—author of Continuous Discovery Habits—doesn't write code. Yet she's become one of the most sophisticated Claude Code users by pioneering what she calls "context architecture."
The Principle
"To do context well, it's not just that we have to document everything. We have to document everything in teeny-tiny files so that when we ask Claude to do a task, we can give Claude just the context it needs."
This is the opposite of the typical approach (one massive CLAUDE.md file). Instead, Torres creates granular context libraries:
.claude/
├── CLAUDE.md # High-level project overview
├── context/
│ ├── business-profile.md # Company background, goals
│ ├── writing-style.md # Tone, vocabulary preferences
│ ├── product-docs/
│ │ ├── auth-system.md # Authentication details
│ │ ├── payment-flow.md # Payment implementation
│ │ └── api-design.md # API conventions
│ └── personal/
│ ├── preferences.md # Your work preferences
│ └── schedule.md # Availability, deadlines
└── commands/
├── today.md # Daily task generation
├── blog-review.md # Writing feedback
└── research.md # Research automation
"Lazy Prompting" Through Context
With extensive context libraries, Torres can be "lazy with prompting":
> Claude, blog post review
Claude loads her writing style guide and provides feedback calibrated to her actual goals—no lengthy explanation needed.
Pair Programming for Everything
Torres's most powerful insight extends beyond code:
"I pair program now with everything I do, even if it's not programming. I pair task manage and I pair write and I pair everything."
Her custom /today command generates daily to-do lists by checking multiple sources:
- Markdown task files
- Trello boards
- Calendar integrations
- Previous day's incomplete items
Part 3: The 50% Context Rule
Ross Mike emphasizes a critical threshold most users ignore:
"Never exceed 50% context. Once you hit ~100K tokens in a session, model quality deteriorates."
How to Monitor Context
Use the /context command to visualize your token usage:
> /context
This displays a colored grid showing what's consuming your context window.
When to Start Fresh
Start new sessions when:
- Context exceeds 50%: Quality degrades with very large contexts
- Switching projects: Different codebases need different context
- Task dramatically changes: Frontend to DevOps, for example
- Conversation becomes stale: Old information can confuse Claude
Compacting Conversations
The /compact command summarizes your conversation history, freeing tokens while preserving key information:
> /compact focus on the authentication changes we made
This creates a summary and resets the conversation with that summary as context.
Part 4: RALPH Loops (Use With Caution)
RALPH (named after Ralph Wiggum from The Simpsons) is an autonomous development technique where Claude works through a task list iteratively without human intervention.
How It Works
- You provide a PRD (Product Requirements Document) with a task list
- A hook prevents Claude from exiting after completing each task
- Claude works on task 1, documents progress, moves to task 2
- The loop continues until all tasks are complete
The Warning
Ross Mike is emphatic about RALPH loops:
"If you haven't built anything, deployed anything, there isn't a URL that I myself or Greg can click on that you've built, you have no business using RALPH."
RALPH loops amplify your planning quality:
- Good PRD + RALPH = Multi-day loops that build complete applications
- Bad PRD + RALPH = Expensive chaos
Best Practices for RALPH
If you do use RALPH loops:
- Exhaustively detailed PRD: Use ask_user_question to fill every gap
- Clear acceptance criteria: Each feature needs testable criteria
- Test-first verification: Run tests after each feature before proceeding
- Stay under 50% context: Monitor token usage throughout
Part 5: The Boris Cherny Principles
As Claude Code's creator, Boris Cherny offers unique insights into how to think about AI-augmented development.
70% Productivity Boost
At Anthropic, where Claude Code was built:
"Anthropic has tripled in headcount, but productivity per engineer has grown 70% because of Claude Code. That's not automation replacing work—that's augmentation creating leverage."
This isn't automation—it's augmentation. Claude handles the tedious parts while humans provide judgment and direction.
Build for Future Models
"Don't build for the model of today. Build for the model 6 months from now."
Cherny's estimate: A project that took 20-30 engineers two years (Facebook Groups migration) could now be done by 5 engineers in 6 months. In another 6 months? Maybe just one.
This means:
- Invest in good architecture over clever prompts
- Build workflows that can scale with model improvements
- Don't over-optimize for current limitations
The Generalist Advantage
"At Anthropic, product managers code. Data scientists code. User researchers code. This isn't about job titles blurring—it's about reducing the coordination costs of building."
Claude Code enables this generalist approach. When everyone can contribute to the full stack, velocity increases exponentially.
Part 6: Automation vs. Augmentation
Teresa Torres's framework for every task:
"I forced myself every time I did a task to ask: How can AI help with this? Can it automate it? Can it augment it? Do I like doing it? Do I want AI to do it for me?"
What to Automate
- Research summaries (arXiv, Google Scholar papers)
- Data processing and formatting
- Boilerplate code generation
- Test writing
- Documentation updates
What to Augment (Keep Human Involvement)
- Writing (if you enjoy it)
- Design decisions
- User research synthesis
- Strategic planning
- Code architecture
Torres's insight: "I love to write. I don't want to automate writing." As AI capabilities expand, be intentional about which parts of your work define you.
Part 7: Essential Workflows
Daily Task Management
Create a /today command that checks multiple sources:
<!-- .claude/commands/today.md -->
Check my task sources and generate today's priorities:
1. Review @tasks/current.md for active items
2. Check for any overdue deadlines
3. Consider my calendar for today
4. Prioritize by impact and urgency
Format as a numbered list with time estimates.
Research Automation
Set up overnight research processing:
<!-- .claude/commands/research.md -->
Process papers I've downloaded to @research/inbox/:
1. Summarize key findings (3-5 bullet points each)
2. Identify relevance to my current project @context/project-goals.md
3. Extract quotes worth saving
4. Move processed files to @research/processed/
Code Review
Create a comprehensive review command:
<!-- .claude/commands/review.md -->
Review the code changes in my current branch:
1. Check for security vulnerabilities
2. Evaluate against our standards @context/code-standards.md
3. Identify potential performance issues
4. Suggest improvements (be specific)
5. Note any missing tests
Intelligent Search
Torres's approach to finding things across notes:
> I have a thing called new blog post tomorrow
Claude searches context and finds "article Wednesday"—understanding intent even when you remember wrong.
Part 8: CLAUDE.md Best Practices
Your CLAUDE.md file is Claude's persistent memory. Here's how to structure it effectively:
Hierarchy
Enterprise policy (organization-wide)
└── Project memory (team-shared, in git)
└── Project rules (modular topics)
└── User memory (your preferences)
└── Local project (not in git)
Good CLAUDE.md Structure
# Project Name
## Architecture
- Framework: [your stack]
- Database: [your database]
- Key patterns: [important conventions]
## Code Standards
- [Specific, actionable rules]
- [Not generic advice]
## Commands
- `bun run dev`: Start development
- `bun test`: Run tests
## Important Context
- [Project-specific gotchas]
- [Things Claude should always remember]
## Don'ts
- [Specific anti-patterns to avoid]
Conditional Rules
Use frontmatter for path-specific rules:
---
paths:
- "src/api/**/*.ts"
---
# API Development Rules
- All endpoints must include input validation
- Use the standard error response format
- Include OpenAPI documentation
Part 9: For Non-Technical Users
Claude Code isn't just for developers. Teresa Torres uses it daily without coding experience.
Getting Started
- Install Claude Code: Follow the setup guide
- Start simple: Ask Claude to explain your project's structure
- Build context gradually: Create context files as you learn
Questions You Can Ask
> What does this code do?
> Explain this error in simple terms
> I need a feature where users can [describe what you want]
> Fix the bug when I click [describe the problem]
Tips
- Be specific: "Fix the bug when I click submit" beats "fix the bug"
- Share errors: Copy the full error text—it helps Claude diagnose
- Ask for explanations: "Explain what you just did in simple terms"
- Name sessions: Use
/rename my-taskso you can return later
Part 10: TeamDay Integration
TeamDay runs Claude Code on Linux servers, making it accessible via web browser. This means you can:
- Access Claude Code from any device without local installation
- Share sessions with team members
- Integrate with TeamDay's agent ecosystem
- Run long-running tasks without keeping your laptop open
Getting Started with TeamDay + Claude Code
- Create a TeamDay workspace
- Connect your repositories
- Start a Claude Code session from the web interface
- Your CLAUDE.md and context files are automatically loaded
Key Takeaways
- Input quality is everything: Use ask_user_question religiously
- Context architecture: Granular files beat monolithic documentation
- Monitor context usage: Stay under 50%, use /compact when needed
- RALPH loops require expertise: Build manual reps first
- Automate selectively: Keep what you love, automate what you don't
- Build for the future: Models improve faster than your workflows
What's Next
The experts agree: we're in the early days of AI-augmented work. Boris Cherny's prediction that a 20-30 engineer project could soon be done by one person isn't hyperbole—it's the trajectory we're on.
The winners won't be those with the best tools, but those who invest in crafting precise inputs. Start with ask_user_question, build your context library, and iterate.
Sources