The Claude Code Planning Workflow That Actually Works
Problem
My code reviews were taking forever. Every time I finished a feature with Claude Code, I’d spend hours fixing issues that should have been caught earlier. Scope creep, missed edge cases, architecture decisions that didn’t make sense in hindsight.
Here’s a typical session:
Me: "Build a user authentication system"
Claude: [generates 500 lines of code]
Me: [reviews code]Me: "Wait, this doesn't handle token refresh"Me: "And where's the rate limiting?"Me: "Why did you use sessions instead of JWT?"Me: "This doesn't match our existing auth pattern"
[2 hours of fixes later...]
Me: "Finally done"I was being lazy with planning. AI generates code so fast that planning feels unnecessary. Why spend 30 minutes planning when Claude can generate code in seconds?
The trap: Fast generation doesn’t mean fast completion.
What I Tried First
I added a planning phase to my workflow. But I was doing it wrong.
Me: "Plan the authentication system"
Claude: "Here's a plan:1. Create user model2. Add auth routes3. Implement login4. Add logout5. Test everything"
Me: "Looks good, implement it"
[Same problems. Same long reviews. Same rework.]This wasn’t planning. It was a to-do list.
The plan was too vague. It didn’t explore alternatives. It didn’t catch edge cases. It was just a checklist that happened before coding instead of after.
What Actually Worked
I found a Reddit thread where experienced Claude Code users shared their planning workflows. One comment stuck with me:
“It’s really frickin’ easy to get lazy with the planning phase of projects with AI… tools that feel like they slow my progress actually speed me up because my reviews are much faster and the code’s of better quality.”
The comment described a three-phase workflow:
- Pre-work: Problem statement + Socratic planning
- Implementation: Brainstorming -> Plans -> Subagents
- Review: Grill-me technique after each phase
I tried it on my next feature. Here’s what happened.
Phase 1: Pre-work
Instead of jumping to code, I spent 15 minutes on context.
## Problem StatementNeed user authentication that works for both mobile app and web dashboard.
## Research Already Done- Checked current session implementation (uses cookies)- Reviewed competitor auth patterns- Mobile team needs JWT support
## Socratic Questions (ran /socratic skill)1. What are the core assumptions? - Assumed cookies work for web only - Assumed mobile needs stateless auth
2. What alternatives exist? - JWT with refresh tokens (scales better) - Session-based (simpler, but mobile issues) - OAuth integration (deferred - no third-party need)
3. What could go wrong? - Token refresh race conditions - Multiple device sessions - Logout across all devices
4. How will we verify success? - Mobile can authenticate - Web maintains current UX - Token refresh works without user noticingThis took 15 minutes. In my old workflow, I would have spent 15 minutes debugging auth issues later.
Phase 2: Implementation Pipeline
Instead of asking Claude to “build auth,” I broke it into stages.
brainstorming (specs) -> writing-plans -> subagent executionBrainstorming first:
## ApproachesA. JWT with refresh tokens (best for mobile + web)B. Session-based auth (simpler, but mobile issues)C. OAuth integration (overkill for our needs)
Selected: A - JWT with refresh tokens
Why: Mobile team already expects JWT. Web can use same flow.Trade-off: More complex token management, but better scalability.Then detailed planning:
## Subagent 1: Auth middleware- Input: Auth requirements spec- Output: Middleware module with token validation
## Subagent 2: User model- Input: Database schema- Output: User model + migrations
## Subagent 3: Auth routes- Input: API contract- Output: Route handlers for login/refresh/logout
## Subagent 4: Tests- Input: Test requirements- Output: Test suite with 80%+ coverage
## Verification Checkpoints- After each subagent: Grill-me session- After integration: Full security reviewThen subagent execution:
I had Claude work on each subagent independently. Each subagent got clear inputs and expected outputs. No scope creep because boundaries were defined.
Phase 3: Grill-me Review
This was the game-changer. After each phase, I asked Claude to grill me.
## Phase Completed: Auth middleware
## What I Did- Chose JWT over sessions- Implemented refresh token rotation- Added rate limiting to login endpoint
## What I Need You to Challenge1. Are my assumptions valid?2. Did I miss any edge cases?3. Is the architecture sound?4. What will break first?
## Questions for Claude- What would a senior engineer criticize here?- What technical debt am I creating?- Where am I being optimistic?Claude’s response:
Critiques from the grill:
1. Token refresh race condition: If two requests happen simultaneously during refresh, you could get inconsistent tokens. Need mutex/lock.
2. Missing rate limiting on refresh endpoint - only login is protected.
3. No revocation mechanism for compromised tokens.
4. Refresh token storage in localStorage is vulnerable to XSS.
Technical debt: Token revocation will require a denylist or short expiry.
You're optimistic about: Mobile offline handling. No plan for that.I fixed these issues BEFORE moving to the next phase. In my old workflow, these would be bugs found during code review. Now they were design decisions made during planning.
The Hidden ROI
I measured the time investment:
Activity | Without Planning | With Planning | Net Effect----------------------|------------------|---------------|------------Initial coding | Fast (AI-gen) | Slower | -20% speedCode review | Slow (many bugs) | Fast (few) | +50% speedDebugging | High (unclear) | Low (clear) | -70% timeRefactoring | Frequent | Rare | -60% effort----------------------|------------------|---------------|------------TOTAL | Baseline | +30% faster | Better qualityThe planning feels slower. But the total workflow is faster because:
- Fewer bugs in code review
- Clearer scope means fewer refactor cycles
- Design decisions are intentional, not accidental
- Edge cases documented, not discovered
Common Mistakes That Kill Planning
I made these mistakes. Maybe you will too.
Mistake 1: Skipping pre-work
# WRONGMe: "Build feature X"Claude: [generates code immediately]
# RIGHTMe: "Here's the problem statement and my research..."Claude: [runs Socratic planning]Mistake 2: One-shot implementation
# WRONGMe: "Implement authentication"Claude: [generates monolithic 500-line response]
# RIGHTMe: "Break this into subagents with clear interfaces"Claude: [creates 4 subagents with defined boundaries]Mistake 3: Skipping the grill
# WRONGPhase complete -> Move to next phase immediately
# RIGHTPhase complete -> Grill-me session -> Fix issues -> Next phaseMistake 4: Using Claude as generator only
# WRONGAccept first output as final
# RIGHTUse Claude as "second brain that critiques"Iterate on work, don't just accept itThe Workflow Diagram
Here’s the complete workflow I now use:
Problem Statement | vResearch Context | v/socratic Planning <-- Pre-work Phase | vSpec Document | v/superpowers:brainstorming | vSolution Options | v/superpowers:writing-plans <-- Implementation Phase | vImplementation Plan | vSubagent Execution | vGrill-me Review | vIssues Found? / \ Yes No | | v vFix & PhaseIterate CompleteSummary
The best Claude Code planning workflow combines pre-work (problem statement + Socratic planning), systematic implementation (brainstorming to plans to subagents), and rigorous review (grill-me technique after each phase).
This structured approach feels slower but delivers faster overall results with higher code quality.
Before my next Claude Code session, I now spend 10 minutes on pre-work:
- Define the problem statement clearly
- Document research I’ve already done
- Run a Socratic planning session
- Identify constraints and success criteria
My code reviews became faster. My code quality improved. And I stopped wasting hours fixing issues that should have been caught during planning.
Final Words + More Resources
My intention with this article was to help others share my knowledge and experience. If you want to contact me, you can contact by email: Email me
Here are also the most important links from this article along with some further resources that will help you in this scope:
Oh, and if you found these resources useful, don’t forget to support me by starring the repo on GitHub!
Comments