Skip to content

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:

What my workflow looked like
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.

My first attempt at planning
Me: "Plan the authentication system"
Claude: "Here's a plan:
1. Create user model
2. Add auth routes
3. Implement login
4. Add logout
5. 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:

  1. Pre-work: Problem statement + Socratic planning
  2. Implementation: Brainstorming -> Plans -> Subagents
  3. 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.

Pre-work Session
## Problem Statement
Need 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 noticing

This 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.

Implementation Pipeline
brainstorming (specs) -> writing-plans -> subagent execution

Brainstorming first:

Brainstorming Output
## Approaches
A. 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:

Implementation Plan
## 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 review

Then 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.

Grill-me Session
## 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 Challenge
1. 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:

Claude's Critique
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:

Time Investment Comparison
Activity | Without Planning | With Planning | Net Effect
----------------------|------------------|---------------|------------
Initial coding | Fast (AI-gen) | Slower | -20% speed
Code review | Slow (many bugs) | Fast (few) | +50% speed
Debugging | High (unclear) | Low (clear) | -70% time
Refactoring | Frequent | Rare | -60% effort
----------------------|------------------|---------------|------------
TOTAL | Baseline | +30% faster | Better quality

The 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

Mistake 1 Example
# WRONG
Me: "Build feature X"
Claude: [generates code immediately]
# RIGHT
Me: "Here's the problem statement and my research..."
Claude: [runs Socratic planning]

Mistake 2: One-shot implementation

Mistake 2 Example
# WRONG
Me: "Implement authentication"
Claude: [generates monolithic 500-line response]
# RIGHT
Me: "Break this into subagents with clear interfaces"
Claude: [creates 4 subagents with defined boundaries]

Mistake 3: Skipping the grill

Mistake 3 Example
# WRONG
Phase complete -> Move to next phase immediately
# RIGHT
Phase complete -> Grill-me session -> Fix issues -> Next phase

Mistake 4: Using Claude as generator only

Mistake 4 Example
# WRONG
Accept first output as final
# RIGHT
Use Claude as "second brain that critiques"
Iterate on work, don't just accept it

The Workflow Diagram

Here’s the complete workflow I now use:

Planning Workflow
Problem Statement
|
v
Research Context
|
v
/socratic Planning <-- Pre-work Phase
|
v
Spec Document
|
v
/superpowers:brainstorming
|
v
Solution Options
|
v
/superpowers:writing-plans <-- Implementation Phase
|
v
Implementation Plan
|
v
Subagent Execution
|
v
Grill-me Review
|
v
Issues Found?
/ \
Yes No
| |
v v
Fix & Phase
Iterate Complete

Summary

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:

  1. Define the problem statement clearly
  2. Document research I’ve already done
  3. Run a Socratic planning session
  4. 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