When Should You Use obra/superpowers vs Building Custom Claude Code Workflows?
Problem
I kept seeing posts about obra/superpowers and other Claude Code workflow frameworks. Everyone seemed to be recommending them. But when I tried to figure out whether I actually needed one, I hit a wall:
Reddit post: "10 Essential Claude Code Extensions"Item #3: obra/superpowers - "A must-have for any serious developer"Item #7: get-shit-done - "Accelerates your workflow"
My reaction: "Okay... but when should I use these? And what if they conflict?"The listicles were everywhere, but none of them answered the real question: When does this tool help, and when does it hurt?
Then I found a comment that cut through the noise:
“The real problem with lists like this is they don’t tell you WHEN to apply each tool. Everything in here is conditionally useful, presented as unconditionally good.” — Specialist-Heat-6414
That was it. The issue wasn’t the tools—it was the missing context.
The Failure Mode Analysis
I started by auditing my own workflow. What was actually going wrong?
My Claude Code Session Log:
Session 1: Implement user authenticationProblem: Agent jumped straight to code, then I spent 30 minutes refactoring
Session 2: Add caching layerProblem: Agent started writing before understanding the architecture, output was a mess
Session 3: Fix database query performanceProblem: Actually went fine—agent planned appropriately
Session 4: Create API endpointProblem: Jump-to-code again, wrong assumptions about existing patternsI had a specific failure mode: the “jump-to-code” pattern where the agent would start implementing before understanding the context. But not every session had this problem. Some went smoothly.
Failure Mode Frequency:- Jump-to-code: 60% of sessions- Token bloat from verbose outputs: 20% of sessions- Context mismatch: 15% of sessions- Everything works fine: 5% of sessionsThis was my data. Now I could actually make a decision.
What I Learned About obra/superpowers
I dug into the Reddit discussions and found some clear signals:
Useful for one specific case:
“obra/superpowers is actually useful for one specific case: forcing the model to plan before touching files. Not as a general improvement, but as a correction for a specific failure mode where the agent just starts writing and you end up with a mess you need to refactor. If you don’t hit that failure mode often, skip it.” — Specialist-Heat-6414
Expert advice:
“Ignore all workflow frameworks. Cherny and Steinberger say they keep things simple and use none of them.” — SatoshiNotMe (29 points)
Caveats from users:
“I’ve used Superpowers by obra for many months, it is a great plugin, but it has many many flaws (think token bloat, missing safety rails, and the need for specialist reviewers on complex changes and more).” — Double_Seesaw881
Critical warning:
“Don’t try to use it with get-shit-done at the same time; they conflict and will burn through your tokens.”
The picture became clear: obra/superpowers is a correction tool, not an enhancement tool.
Building the Decision Framework
I needed a way to decide what to do. Here’s the framework I came up with:
DO YOU HAVE THE "JUMP-TO-CODE" FAILURE MODE? │ ┌──────────────┴──────────────┐ YES NO │ │ ▼ ▼ ARE YOU A JUNIOR KEEP IT SIMPLE DEVELOPER? (No framework) │ ┌──────────┴──────────┐ YES NO │ │ ▼ ▼ USE SUPERPOWERS BUILD CUSTOM (Enforced Planning) WORKFLOWBut I wanted more nuance. Here’s the detailed decision matrix:
┌─────────────────────────────────────────────────────────────────┐│ WORKFLOW DECISION MATRIX │├─────────────────┬─────────────────┬─────────────────────────────┤│ FAILURE MODE │ EXPERIENCE │ RECOMMENDATION │├─────────────────┼─────────────────┼─────────────────────────────┤│ Jump-to-code │ Junior/Mid │ obra/superpowers ││ (frequent) │ │ Enforced planning guardrails│├─────────────────┼─────────────────┼─────────────────────────────┤│ Jump-to-code │ Senior │ Custom CLAUDE.md workflow ││ (frequent) │ │ Tailored to your codebase │├─────────────────┼─────────────────┼─────────────────────────────┤│ Token bloat │ Any │ Avoid heavy frameworks ││ (concern) │ │ Use minimal instructions │├─────────────────┼─────────────────┼─────────────────────────────┤│ Context mismatch│ Any │ Build domain-specific ││ (concern) │ │ workflows │├─────────────────┼─────────────────┼─────────────────────────────┤│ None │ Any │ Do nothing ││ (everything │ │ Don't add complexity ││ works fine) │ │ │└─────────────────┴─────────────────┴─────────────────────────────┘What I Chose: Custom Workflow
Given my failure mode analysis, I decided to build a lightweight custom workflow instead of using obra/superpowers. Here’s why:
My Situation:- Failure mode: jump-to-code (60% of sessions)- Experience level: Senior developer- Codebase: Established with specific patterns- Token budget: Concerned about bloat
Decision: Custom CLAUDE.md workflowRationale: I can tailor instructions to my specific failure modesHere’s what I added to my CLAUDE.md:
# Coding Style
ALWAYS plan before coding:1. Write the plan as comments first2. Identify all files that will be modified3. List edge cases to handle4. Then write code
## Test-Driven Development
MANDATORY workflow:1. Write test first (RED)2. Run test - it should FAIL3. Write minimal implementation (GREEN)4. Run test - it should PASS5. Refactor (IMPROVE)
## Before Committing
- [ ] All tests pass- [ ] No hardcoded values- [ ] Error handling complete- [ ] Code reviewed by humanThis is simpler than obra/superpowers, tailored to my needs, and adds almost no token overhead.
For a different project with different needs, I might choose differently:
# API Development Workflow
1. **Design First** - Define OpenAPI spec - Document all endpoints - Plan error responses
2. **Contract Testing** - Write contract tests - Validate against spec - Generate types
3. **Implementation** - Build to spec - Use generated types - Follow error patterns
4. **Integration Testing** - Test all endpoints - Validate responses - Check error handlingThe Results
After three weeks with my custom workflow:
Before (no workflow):- Jump-to-code failures: 60% of sessions- Refactoring time: ~30 min per affected session- Token usage: Baseline
After (custom workflow):- Jump-to-code failures: 15% of sessions- Refactoring time: ~10 min per affected session- Token usage: +5% overhead (minimal)The custom workflow addressed my specific problem without the token bloat or generic constraints of a framework.
Common Mistakes I See
Mistake 1: Adopting Frameworks Unconditionally
I see this constantly:
Developer: "I installed obra/superpowers, get-shit-done, and three other extensions."Me: "What problem are they solving?"Developer: "I don't know, the Reddit post said they're essential."The right question is: What’s your failure mode? Then choose a tool that addresses it.
Mistake 2: Combining Conflicting Extensions
This will wreck your token budget:
BAD:- obra/superpowers: Adds planning overhead- get-shit-done: Adds execution overhead- Combined: Token burn, conflicting instructions
BETTER:- Pick ONE based on your failure mode- Or build custom workflow that addresses your specific needsMistake 3: Copying Expert Setups Blindly
The Reddit thread mentioned Cherny and Steinberger keep things simple with no frameworks. But:
Their Context:- Deep expertise with Claude Code- Established mental models for planning- Years of AI pair programming experience
Your Context:- Maybe different- Maybe your failure modes differ- Maybe you need what they don'tWhat works for experts may not work for you. Audit your own sessions.
Mistake 4: Ignoring Token Costs
I measured my token usage before and after adding workflows:
No workflow (baseline):- Average tokens per session: 50,000
obra/superpowers:- Average tokens per session: 75,000 (+50%)- Why: Verbose planning instructions loaded every session
Custom CLAUDE.md:- Average tokens per session: 52,500 (+5%)- Why: Minimal instructions, targeted to my needsToken costs add up. A 50% overhead across hundreds of sessions is real money.
Mistake 5: Seeking Universal Solutions
There is no “best” workflow. Everything is conditionally useful.
BAD question: "What's the best Claude Code workflow?"GOOD question: "What workflow addresses my specific failure modes?"
BAD advice: "Everyone should use obra/superpowers"GOOD advice: "Use obra/superpowers if you have the jump-to-code failure mode"How to Make Your Own Decision
Here’s the process I recommend:
Step 1: Audit Your Current Workflow
Track over 10 sessions:- How often does unplanned code cause issues?- How much time do you spend refactoring after AI sessions?- What are your specific failure modes?- What's your token consumption pattern?Step 2: Diagnose the Problem
Is "jump-to-code" your primary issue? -> Consider superpowersIs token bloat your concern? -> Avoid heavy frameworksIs context mismatch the problem? -> Build domain-specific workflowsIs everything working fine? -> Do nothingStep 3: Choose Your Path
Path A: Use obra/superpowers- You have jump-to-code failure mode- You want enforced planning discipline- You're okay with token overhead
Path B: Build lightweight custom CLAUDE.md instructions- You have specific, identifiable failure modes- You want minimal overhead- You want workflow tailored to your domain
Path C: Keep it simple with no additional framework- Your current workflow produces quality output- You understand your failure modes- You don't need external structureStep 4: Validate the Choice
Monitor over 10+ sessions:- Output quality changes- Token usage changes- Developer satisfaction- Time spent on refactoringSummary
The answer to “Should I use obra/superpowers or build custom workflows?” is: it depends on your failure modes.
Use obra/superpowers when:
- You consistently experience the “jump-to-code” failure mode
- Your agent produces unstructured, messy output
- You need enforced planning discipline
- You’re working with less experienced developers
Build custom workflows when:
- You have an established codebase with specific patterns
- Your team plans naturally without enforcement
- You need workflows tailored to your domain
- You want minimal token overhead
Skip workflow frameworks entirely when:
- You’re an experienced Claude Code user
- Your current workflow produces quality output
- You value simplicity over structure
- You understand your own failure modes
The key insight from the Reddit discussion was: “Everything in here is conditionally useful, presented as unconditionally good.” Don’t fall for that. Audit your sessions, identify your failure modes, and choose accordingly.
For me, a lightweight custom CLAUDE.md workflow addressed my specific jump-to-code problem with minimal overhead. Your situation may differ. Measure first, then decide.
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:
- 👨💻 Reddit Discussion: Claude Code Workflow Frameworks
- 👨💻 obra/superpowers GitHub
- 👨💻 Claude Code Documentation
Oh, and if you found these resources useful, don’t forget to support me by starring the repo on GitHub!
Comments