You're using Claude Code wrong.
Not your fault — nobody told you the right way.
Boris Cherny did. He's the guy who BUILT Claude Code at Anthropic. And last month, he shared exactly how his team actually uses it internally.
Someone turned it into a workflow template. I'm breaking it down.
The 6 Rules That Change Everything
1. Plan Mode Default
Stop diving straight into code.
The rule: For ANY task with 3+ steps or architectural decisions, enter plan mode FIRST.
Why it matters: When something goes sideways (and it will), you have a plan to revert to. You're not winging it and hoping Claude figures it out.
How to use it:
• Start with "Let's plan this out first"
• If Claude starts coding before planning, stop it
• When things break, re-plan immediately — don't keep pushing
Most people skip this. Then wonder why Claude goes off the rails halfway through.
2. Subagent Strategy
Your main context window is expensive real estate.
The rule: Offload research, exploration, and parallel analysis to subagents.
Why it matters: Main context stays clean. Subagents handle the grunt work. You orchestrate instead of drowning in details.
How to use it:
• Researching a library? Subagent.
• Testing 3 different approaches? 3 subagents in parallel.
• One task per subagent. Focused execution.
Think of it like delegating to junior developers. You're the architect, they're the implementation team.
3. Self-Improvement Loop
This is the one everyone misses.
The rule: After ANY correction from you, Claude updates tasks/lessons.md with the pattern.
Why it matters: Claude learns from YOUR corrections. Same mistake won't happen twice.
How to use it:
markdown
tasks/lessons.md
Never Do This Again
Issue: Forgot to run tests before marking complete
Rule: Always run npm test before saying "done"
Why: Caught by user 3 times in Week 1
Create this file. Make Claude update it every time you correct something. Watch your mistake rate drop.
4. Verification Before Done
"It's done" means nothing without proof.
The rule: Never mark a task complete without proving it works.
Why it matters: Staff engineers don't say "done" and hope. They show you the passing tests, the diff, the logs.
How to use it:
• Run tests
• Check logs
• Demonstrate correctness
• Ask yourself: "Would a staff engineer approve this?"
If you can't prove it works, it's not done.
5. Demand Elegance (Balanced)
Hacky fixes compound into technical debt.
The rule: For non-trivial changes, pause and ask "is there a more elegant way?"
Why it matters: The best engineers don't ship the first thing that works. They ship the thing that SHOULD work.
How to use it:
• If a fix feels hacky: "Knowing everything I know now, implement the elegant solution"
• Skip this for simple, obvious fixes — don't over-engineer
• Challenge your own work before presenting it
Elegance ≠ perfection. It means "does this solution make sense architecturally?"
6. Autonomous Bug Fixing
Stop hand-holding.
The rule: When given a bug report, just fix it. Don't ask for help.
Why it matters: If you're still debugging FOR Claude, you're not using it right.
How to use it:
• Point at logs, errors, failing tests
• Let Claude resolve them
• Zero context switching from you
• Failing CI? Claude fixes it without being told how
This is the difference between a junior dev and a senior dev. Seniors solve problems autonomously.
Why This Works
Boris Cherny's team writes Claude Code itself. They use it 10+ hours a day.
These aren't theory. They're battle-tested patterns from the people who know the tool best.
And they're embarrassingly simple. No complex prompts. No 50-page CLAUDE.md files. Just 6 rules.
COPY THIS BELOW AS YOUR CLAUDE.MD FILE:
This file provides guidance to Claude Code when working in this repository. Claude reads it automatically at the start of every session.
Workflow Orchestration
1. Plan Mode Default
When to use: ANY non-trivial task (3+ steps or architectural decisions)
The rule:
Enter plan mode FIRST before touching code
If something goes sideways, STOP and re-plan immediately — don't keep pushing
Use plan mode for verification steps, not just building
Write detailed specs upfront to reduce ambiguity
In practice:
Before starting any task:
1. Ask Claude to enter plan mode: "Let's plan this out first"
2. Review the plan together
3. Approve or revise before execution
4. If errors occur mid-task: pause, re-plan, then continue
Why this matters: When you skip planning, Claude commits to an approach that may be wrong. Re-planning mid-task is cheaper than debugging bad architecture.
2. Subagent Strategy
When to use: Research, exploration, parallel analysis, complex problems
The rule:
Use subagents liberally to keep main context window clean
Offload research, exploration, and parallel analysis to subagents
For complex problems, throw more compute at it via subagents
One task per subagent for focused execution
In practice:
Main session: Architecture, coordination, final review
Subagent 1: Research library options
Subagent 2: Prototype approach A
Subagent 3: Prototype approach B
Then: Compare results in main session
Why this matters: Your main context window is expensive. Subagents handle grunt work while you orchestrate from the top.
3. Self-Improvement Loop
When to use: After EVERY correction from the user
The rule:
After ANY correction: update
tasks/lessons.mdwith the patternWrite rules for yourself that prevent the same mistake
Ruthlessly iterate on these lessons until mistake rate drops
Review lessons at session start for relevant project
File structure:
markdown
tasks/lessons.md
Never Do This Again
Issue: Forgot to run tests before marking complete
Rule: Always run npm test or equivalent before saying "done"
Why: Caught by user 3 times in Week 1
Date: 2026-03-01
Issue: Ignored CLAUDE.md instruction about TypeScript strict mode
Rule: Check CLAUDE.md for project-specific rules BEFORE starting
Why: Had to refactor 200 lines after user correction
Date: 2026-03-05
Patterns That Work
Pattern: Always ask for clarification on vague requirements
Example: "Should this be client-side or server-side validation?"
Result: Saved 2 hours of rework
Date: 2026-03-03
Pattern: Use descriptive commit messages with context
Example: "Fix: Prevent duplicate API calls in useEffect hook (closes #123)"
Result: User approved without asking for changes
Date: 2026-03-06
Setup:
Create
tasks/directory in project rootCreate
tasks/lessons.mdusing the template aboveTell Claude to update it after every correction
Review weekly and consolidate patterns
Why this matters: Claude doesn't remember across sessions. This file IS its memory. The more you update it, the fewer mistakes you'll see.
4. Verification Before Done
When to use: Before saying "task complete"
The rule:
Never mark a task complete without proving it works
Diff behavior between main and your changes when relevant
Ask yourself: "Would a staff engineer approve this?"
Run tests, check logs, demonstrate correctness
Checklist before saying "done":
✅ All tests pass (unit, integration, E2E if applicable)
✅ Code runs without errors in dev environment
✅ Changes are visible/functional in UI (if applicable)
✅ Logs show expected behavior
✅ No new warnings or errors in console
✅ Diff reviewed (no accidental changes)
✅ Would a staff engineer approve this?
*In practice:*
❌ Bad: "I've updated the component. It should work now."
✅ Good: "Updated the component. Tests pass (npm test output below),
checked in browser (screenshot attached), no console errors."
*Why this matters:* "It should work" is not proof. Staff engineers show their work. So should Claude.
---
### 5. Demand Elegance (Balanced)
*When to use:* Non-trivial changes that feel hacky
*The rule:*
• For non-trivial changes: pause and ask "is there a more elegant way?"
• If a fix feels hacky: "Knowing everything I know now, implement the elegant solution"
• Skip this for simple, obvious fixes — don't over-engineer
• Challenge your own work before presenting it
*In practice:*
Scenario: Need to add a feature that requires changes in 5 files
Before implementing:
"I could add this feature by modifying these 5 files, but that feels
scattered. Let me think... Is there a cleaner architecture?"
Then:
"Actually, if I create a shared util function, this becomes a 2-file change
and the code is more maintainable."
*When to skip:*
• Simple bug fixes (typo, missing import)
• Obvious one-liner changes
• Time-sensitive hotfixes
*Why this matters:* Elegant solutions age better. Hacky fixes compound into technical debt.
---
### 6. Autonomous Bug Fixing
*When to use:* Bug reports, failing tests, production issues
*The rule:*
• When given a bug report: just fix it. Don't ask for hand-holding
• Point at logs, errors, failing tests — then resolve them
• Zero context switching required from the user
• Go fix failing CI tests without being told how
*In practice:*
❌ Bad:
User: "Tests are failing in CI"
Claude: "Can you show me the error logs?"
✅ Good:
User: "Tests are failing in CI"
Claude: [Checks CI logs] "Found it. The issue is X. Fixing now..."
[3 minutes later] "Fixed. Tests passing. Here's what was wrong..."
*Autonomous debugging process:*
1. Read the error message completely
2. Check relevant logs (CI, console, server)
3. Identify root cause
4. Implement fix
5. Verify fix works
6. Report back with explanation
*Why this matters:* Senior engineers debug autonomously. If you're still debugging FOR Claude, you're not using it right.
---
## Memory & Context Management
### CLAUDE.md File Structure
*Keep this file under 200 lines* for reliable adherence. If it grows beyond that:
*Option 1: Split into multiple CLAUDE.md files (monorepos)*
/project-root/
├── CLAUDE.md # Root-level, shared conventions
├── frontend/
│ └── CLAUDE.md # Frontend-specific rules
├── backend/
│ └── CLAUDE.md # Backend-specific rules
└── api/
└── CLAUDE.md # API-specific rules
*How loading works:*
• *Ancestors load at startup* — Claude walks UP from current directory
• *Descendants load lazily* — Only when you edit files in those subdirectories
• *Siblings never load* — Working in frontend/ won't load backend/CLAUDE.md
*Option 2: Use .claude/rules/ for organization*
/project-root/
├── CLAUDE.md # Main entry point (imports rules)
└── .claude/
└── rules/
├── testing.md
├── code-style.md
└── git-workflow.md
Then in CLAUDE.md:
markdown
# CLAUDE.md
@.claude/rules/testing.md
@.claude/rules/code-style.md
@.claude/rules/git-workflow.md
---
### Context Management Commands
*Before context fills up:*
• Use /compact manually at ~50% usage (check with /context )
• Avoid "agent dumb zone" — compact before hitting 80%
• Use /clear to reset context completely when switching to unrelated task
*When Claude goes off-track:*
• Use /rewind or Esc Esc to undo recent changes
• Don't try to fix it in the same context — rewind and re-approach
*Session management:*
• Use /rename for important sessions (e.g., "TODO - refactor auth system")
• Use /resume to continue named sessions later
---
## Personal Preferences
*Add this section for your own workflow preferences:*
[06/03/2026, 22:53:03] Optimax/ Coach Hub: markdown
## My Preferences
### Code Style
- Use TypeScript strict mode
- Prefer functional components over class components
- Use named exports, not default exports
- Max line length: 100 characters
### Git Workflow
- Commit messages: "<type>: <description> (<issue>)"
- Types: feat, fix, docs, style, refactor, test, chore
- Branch naming: feature/<description>, bugfix/<description>
### Testing
- Write tests BEFORE implementation (TDD)
- Minimum 80% coverage for new code
- Integration tests for critical paths
### Communication
- Be direct — no "Great question!" fluff
- Show your reasoning, not just the answer
- If uncertain, say so explicitly
---
## Project-Specific Context
*Add these sections as needed for your project:*
### Tech Stack
markdown
## Tech Stack
*Frontend:*
- React 18 + TypeScript
- Vite for build
- TailwindCSS for styling
- React Query for data fetching
*Backend:*
- Node.js + Express
- PostgreSQL database
- Prisma ORM
- Redis for caching
*Testing:*
- Vitest for unit tests
- Playwright for E2E tests
### Key Patterns
markdown
## Key Patterns in This Codebase
### API Client Pattern
All API calls go through `src/lib/api-client.ts`. Never use `fetch` directly.
### Error Handling
Use custom error classes from `src/lib/errors.ts`. Always include context.
### State Management
Use React Query for server state. Use Zustand for client state.
### Common Pitfalls
markdown
## Common Pitfalls
### DON'T: Import from barrel files in the same module
❌ `import { Component } from '@/components'`
✅ `import { Component } from '@/components/Component'`
*Why:* Causes circular dependency issues
### DON'T: Mutate Prisma results directly
❌ `user.name = "new name"`
✅ `const updated = { ...user, name: "new name" }`
*Why:* Prisma objects are immutable proxies
---
## Review Checklist
*Before starting a session:*
• [ ] Read this CLAUDE.md file
• [ ] Check tasks/lessons.md for relevant patterns
• [ ] Understand current task requirements
• [ ] Enter plan mode if task is non-trivial
*Before ending a session:*
• [ ] All changes verified and tested
• [ ] Updated tasks/lessons.md if corrections were made
• [ ] Committed changes with descriptive message
• [ ] No broken tests or errors left behind
Try This Today
1. Create tasks/lessons.md in your project
2. Next time Claude makes a mistake, have it write a lesson
3. Next session, have Claude read that file before starting
That's it. One file. Watch your productivity jump.
Mike