superpowers
Frameworkobra/superpowers
An agentic skills framework & software development methodology for coding agents.
Overview
Superpowers provides a set of composable skills and initial instructions that give coding agents a structured development workflow. It enforces test-driven development, systematic debugging, and collaborative planning through a plugin system for multiple coding assistants.
README Preview
# Superpowers\n\nSuperpowers is a complete software development methodology for your coding agents, built on top of a set of composable skills and some initial instructions that make sure your agent uses them.\n\n## Quickstart\n\nGive your agent Superpowers: [Claude Code](#claude-code), [Codex CLI](#codex-cli), [Codex App](#codex-app), [Factory Droid](#factory-droid), [Gemini CLI](#gemini-cli), [OpenCode](#opencode), [Cursor](#cursor), [GitHub Copilot CLI](#github-copilot-cli).\n\n## How it works\n\nIt starts from the moment you fire up your coding agent. As soon as it sees that you're building something, it *doesn't* just jump into trying to write code. Instead, it steps back and asks you what you're really trying to do. \n\nOnce it's teased a spec out of the conversation, it shows it to you in chunks short enough to actually read and digest. \n\nAfter you've signed off on the design, your agent puts together an implementation plan that's clear enough for an enthusiastic junior engineer with poor taste, no judgement, no project context, and an aversion to testing to follow. It emphasizes true red/green TDD, YAGNI (You Aren't Gonna Need It), and DRY. \n\nNext up, once you say "go", it launches a *subagent-driven-development* process, having agents work through each engineering task, inspecting and reviewing their work, and continuing forward. It's not uncommon for Claude to be able to work autonomously for a couple hours at a time without deviating from the plan you put together.\n\nThere's a bunch more to it, but that's the core of the system. And because the skills trigger automatically, you don't need to do anything special. Your coding agent just has Superpowers.\n\n\n## Sponsorship\n\nIf Superpowers has helped you do stuff that makes money and you are so inclined, I'd greatly appreciate it if you'd consider [sponsoring my opensource work](https://github.com/sponsors/obra).\n\nThanks! \n\n- Jesse\n\n\n## Installation\n\nInstallation differs by harness. If you us
FAQ (5)
TroubleshootingWhy does the Superpowers brainstorm server crash when receiving large WebSocket messages?
A missing payload size check in skills/brainstorming/scripts/server.cjs allowed a client to trigger a huge Buffer.alloc, crashing the process. This is fixed by PR #1555 (merged into dev), which adds a max frame size limit (e.g., 10 MB). Upgrade to the latest version containing this fix, or patch manually by rejecting frames > MAX_FRAME_BYTES in the WebSocket handler.
TroubleshootingWhy do agents hit the output token limit when generating multiple plans?
Update to Superpowers v5.1.0+ where plan writing no longer dispatches subagents, avoiding token limits. As a workaround in older versions, manually write plans using a condensed format or split planning into parts. For CLI Opus models, reduce plan detail to stay within output limits.
TroubleshootingWhy does oh-my-opencode disappear after upgrading OpenCode to 1.4.0?
Upgrade OpenCode to version 1.15.10 or later, where this bug is resolved. If you must stay on 1.4.0, track issue #1492 for a permanent fix related to the native skill tool.
TroubleshootingWhy does skill(name="...") fail in OpenCode even though skills are listed in 'opencode debug skill'?
The agent's tool list is missing the skill function tool. To work around: (1) Create symlinks from the plugin's skills directory to ~/.config/opencode/skills/superpowers/ (Option A). (2) Update the bootstrap text to instruct the agent to fall back to glob for SKILL.md and read it when skill() fails (Option C). Alternatively, inject skill content via the messages.transform hook if the tool is absent (Option B).
TroubleshootingHow to confirm architecture assumptions before writing implementation plans in Aider?
After brainstorming and spec self‑review, run a lightweight handoff readiness check. Ensure scope, non‑goals, outputs, and verification expectations are explicit enough for a planner. If any unresolved question would materially change architecture, data flow, user‑facing behavior, or tests, ask the single smallest clarification question, update the spec, and re‑run self‑review. This prevents premature architecture decisions from lurking into code‑detailed plans.