This document compares two Claude Code plugins, Superpowersgithub.com/obra/superpowers and Oh My ClaudeCode (OMC)github.com/Yeachan-Heo/oh-my-claudecode, focusing on philosophy, direction, strengths/risks, and when each is a better fit.
Both projects evolve quickly. This page reflects publicly available information as of 2026-02-19, and you should re-check the "Freshness Checklist" before adopting.
Note: This is a public-source comparison. It does not include any internal details from specific organizations, repositories, or codebases.
- Superpowers: A workflow / skills framework that prevents agents from jumping straight into coding by enforcing a development methodology (design -> plan -> TDD -> review -> branch finish)
- OMC: An orchestration layer that turns your agent into many agents via parallel execution, role separation, verification loops, and observability (HUD, cost, state)
Both are powerful, but they optimize different things:
- If your #1 goal is discipline / verification / avoiding overbuilding, Superpowers is a better default.
- If your #1 goal is throughput / parallelization / operational automation, OMC tends to fit better.
|
Superpowers |
Oh My ClaudeCode (OMC) |
| GitHub |
https://github.com/obra/superpowers |
https://github.com/Yeachan-Heo/oh-my-claudecode |
| What it is |
agentic skills framework + software development workflow |
multi-agent orchestration for Claude Code |
| Core message |
"process over guessing" / TDD / evidence |
"Don't learn Claude Code. Just use OMC." / Team-first |
| Main mechanism |
skills (workflow enforcement) + worktree + TDD + code review |
modes (autopilot/team/ralph/ulw/eco...) + routing + hooks/HUD + verify/fix loops |
| Install (Claude Code) |
/plugin marketplace add obra/superpowers-marketplace then /plugin install ... |
/plugin marketplace add https://github.com/Yeachan-Heo/oh-my-claudecode then /plugin install oh-my-claudecode |
Superpowers is built to stop coding agents from immediately writing code and instead enforce a design -> plan -> implement -> verify workflow.
- Extract design intent through questions, then present design in readable chunks and require user approval.
- After approval, generate an implementation plan broken into 2-5 minute tasks; each task includes exact file paths and verification steps.
- Emphasize true RED/GREEN TDD (tests first).
- Include code review and branch finishing steps (merge/PR/cleanup) in the workflow.
Sources:
OMC routes work to specialized agents and can run tasks in parallel. It also has strong "operation" features (hooks, state, HUD, cost tracking).
- Team mode: a staged pipeline (
team-plan -> team-prd -> team-exec -> team-verify -> team-fix(loop)) and is the recommended canonical surface.
- Multiple execution modes: autopilot/ultrawork/ralph/ecomode, etc.
- Rich operational surface: HUD/statusline, state files, hooks system, analytics.
- Optional multi-AI integration (Codex/Gemini via CLI/MCP) for cross-checking and design review.
Sources:
| Dimension |
Superpowers |
OMC |
| Design phase gate |
Strong (increasingly "no implementation before approval") |
Often optional / guided (plan/PRD pipelines + routing) |
| TDD enforcement |
Strong (RED/GREEN/REFACTOR as a core workflow) |
Possible, but core focus is orchestration + verification |
| Parallelization |
Available (skills exist for dispatching parallel agents) |
Very strong (ultrawork/Team/ultrapilot) |
| Observability |
Relatively simple (workflow-centered) |
Rich (HUD/state/cost/hooks/analytics) |
| "Finish the job" bias |
via process compliance |
explicit modes like ralph + verify/fix loops |
Strengths
- Process-level guardrails against common agent failures (skip design, overbuild, skip tests)
- A "complete development loop" including git worktrees, reviews, and branch finishing
Risks / trade-offs
- Can feel heavy for small changes (design/plan gates add overhead)
- Cultural friction if your team is not aligned with TDD / process-first workflows
- There is an ongoing discussion about native integration with Claude Code Agent Teams (TeamCreate/TaskList/SendMessage)
- A known issue reports that Superpowers' key injected context (e.g., expanded using-superpowers content) may not propagate into subagent sessions
- Windows has recurring hook / path substitution issues that can freeze the CLI (platform/upstream dependency)
- The sequential subagent pattern can cause frequent permission prompts, interrupting long autonomous runs
Strengths
- Strong throughput for large refactors / cross-cutting work via specialization + parallelism + verification loops
- Strong operational tooling (HUD/state/cost/hook system)
Risks / trade-offs
- Team mode relies on Claude Code native Teams and an experimental env flag (
CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS).
- The recommended update flow includes re-running setup after updates; you need an operations routine to avoid unintended config overrides.
- Release velocity is high and breaking changes do occur; pinning versions / staged rollouts help.
- Optional multi-model integration (Codex/Gemini) is powerful, but adds cost/policy/setup considerations.
These are common failure points regardless of your codebase.
- OS/shell compatibility: are hooks
.sh-based? how does it behave on Windows/PowerShell?
- Multi-agent surface: native Agent Teams vs sequential subagent dispatch
- Context propagation: do subagents inherit the same rules/discipline as the main session?
- Update routine: do you need to re-run setup after updates? any risk of config overwrite?
- Default verification: is TDD/review enforced by default or optional?
| Scenario |
Better default |
Why |
| Agents often skip design or overbuild |
Superpowers |
hard workflow gates / checklists |
| High-risk code where tests matter (auth/payments/security) |
Superpowers |
TDD + evidence-first philosophy |
| Many large tasks touching multiple modules/layers |
OMC |
specialization + strong parallel execution |
| You want observability & cost-aware operations |
OMC |
HUD/analytics/state/hooks |
| You want to run an "agent organization" as a team |
OMC |
Team pipeline is first-class |
Both plugins inject strong session context and trigger automation. Running both at once can cause rule/routing collisions.
Recommended approach
- Apply one plugin per project (project-scoped configs are safer than global configs).
- Small feature (2-3 files)
- Superpowers: do the design/plan gates feel productive or too heavy?
- OMC: does the automatic delegation/parallelism feel like overhead?
- Medium refactor (10+ files)
- Superpowers: are task breakdown + review loops effective?
- OMC: does parallel execution + verify/fix loops deliver real speed/quality gains?
- Version pinning: for fast-moving projects, pilot -> pin -> gradual update is safer.
- Config scope isolation: prefer project-scoped configuration to limit blast radius.
- Teams dependency check: if you plan to use TeamCreate-based workflows, validate flags/permissions/OS early.