Editorial status: This is a board-generated deep draft. The facts currently come from public repository metadata, the README, and release entry points; the tasks, metrics, and risks below are the field-test framework still required before publication. Hypotheses are not presented as runs we have already completed.
Bottom line first
obra/superpowers entered the GitHub Developer Tools candidate pool with 268,980 stars and a latest push on 2026-08-08. That makes it worth opening, not production-ready. The decision question is whether it can complete one concrete workflow reliably while permissions, cost, licensing, and maintenance remain explainable.
Repository promise and real boundary
The public description says: An agentic skills framework & software development methodology that works.
This board covers CLI tools, agents, MCP services, and developer workflows. So the test is not only “does it run?” It is whether inputs are controllable, outputs are reproducible, failures are recoverable, and the missing engineering work between a demo and a team workflow is visible.
Repository-specific evidence: turn momentum into an executable entry point
The notes below are checked against the repository's current README, directory layout, and license entry point. They are source-backed setup notes, not a claim that TopicVerge has already completed the run. Open the official README ↗
What the official materials establish
- The README describes Superpowers as composable agent skills plus a software-development methodology, not as a model or IDE by itself.
- It lists separate installation paths for Claude Code, Codex App, Codex CLI, Cursor, Gemini CLI, GitHub Copilot CLI, and other hosts; each harness has its own install and update path.
- The default method covers clarification, design approval, an implementation plan, TDD, YAGNI / DRY, and subagent-driven task execution.
Copyable setup / integration entry points
Codex App: open the Plugins sidebar and install Superpowers from the official plugin marketplace.Codex CLI: open /plugins, search for superpowers, and install it.Claude Code: /plugin install superpowers@claude-plugins-officialA first acceptance task
- In a disposable repository, request a 30–60 minute feature such as a CLI flag with tests; do not expose production credentials or a real production checkout.
- Record whether it writes a spec and plan, waits for approval, runs tests, and which files each step reads or changes.
- Deliberately make one test fail. Check whether the agent diagnoses the failure, cleans up temporary changes, and leaves an auditable summary.
Boundaries not to ignore
- It changes an agent's workflow and skill loading; it does not solve model capability, tool permissions, or host security by itself.
- Plugin formats, versions, and update paths differ by harness. Pin the version and review skills, hooks, and scripts for each host.
- The README workflow must be validated against your repository and model; a promise to plan first is not proof of correctness.
| Field | Current value |
|---|---|
| License | MIT |
| Evidence status | Official materials checked; hands-on results pending |
What to confirm before installation
- Pin the repository commit, runtime, and package manager; do not start from an unverified latest build.
- Create a disposable workspace and least-privilege credentials; isolate config, cache, and logs from the host.
- Read the README, install scripts, permission declarations, lock files, and recent issues before running the first command.
One reproducible minimum task
- Prepare a privacy-safe 3–5 file fixture and define one goal that should finish within ten minutes.
- Allow only the directories, commands, and network domains required for that task; record every permission actually used.
- Run three times: the happy path, a missing dependency, and an interrupted run. Save commands, logs, outputs, and cleanup steps.
Pass signals
- The task finishes without writing outside the fixture directory.
- Logs explain what happened; a failed run can be retried or cleaned up without hidden state.
- With the same versions and model, results are explainable and the maintenance cost is lower than the manual workflow.
Measure it instead of guessing
| Dimension | What to record | Pass signal |
|---|---|---|
| Setup and startup | Time to first install, cold start, dependency downloads, and cleanup | A clean environment completes from recorded steps with actionable failures |
| Quality and reliability | Success rate, failure types, and acceptable-output ratio across at least three runs | Results are explainable and failed runs do not leave hidden state |
| Resources and cost | Time to first install, cold start, and task completion. | The task stays within target hardware or budget |
| Permissions and supply chain | Files, shell, network, credentials, models, plugins, and provenance | Least privilege is possible and licenses remain traceable |
Pros
- The public repository, commit history, issues, and release records can be independently checked.
- It creates a way to test a research-grade capability on a small task before committing to a full platform.
- With pinned versions, cleanup, rollback, and logging, a team can expand usage gradually instead of taking a blind dependency.
- For CLI tools, agents, MCP services, and developer workflows, it is a candidate worth comparing against the workflow you already use.
Cons and risks
- An agent or MCP tool may expose broader file, shell, or network access than the task requires.
- Dependencies, models, and third-party APIs can change the same command's behavior next week.
- A README demo is not production reliability; logging, upgrade, and rollback paths may be incomplete.
- Code, models, plugins, and generated outputs can each have different license terms.
Who should try it?
Good fit: If you can run a reversible task in a sandbox and measure whether it saves time without expanding permissions or maintenance risk.
Skip for now: If you need a fixed SLA, stable long-term APIs, or cannot absorb upgrades, debugging, and permission review for a fast-moving project.
Pre-publication test checklist
- Pin the repository commit, runtime, model or checkpoint, input fixture, and hardware.
- Save install commands, environment variables, permission requests, network domains, logs, and output hashes.
- Run the happy path, a missing-dependency path, and an interrupted-run recovery path; publish failures, not only screenshots.
- Compare one existing alternative using the same input and the same measurement rubric.
- Review code, model, plugin, media, and final-output licensing separately.
Alternatives and decision conditions
- For one fixed action, prefer a narrower script or official API.
- For tool calling, compare the permission inventory of smaller MCP implementations, not only stars.
- For SLA and audit requirements, compare hosted services on total cost and data boundaries.
Editorial decision rule: Move it forward only if it saves time on a real but reversible task and its permissions, logs, rollback, and licenses are explainable. Otherwise keep it on the watchlist.
Board evidence
| Field | Current value |
|---|---|
| Repository | obra/superpowers |
| Stars | 268,980 |
| Latest push | 2026-08-08 |
| Board method | Recent activity + topic match + stars |
| Current evidence level | Public-source review; hands-on test pending |
The next revision will add the actual environment, commands, output samples, failure logs, and version pins. Until then, the useful output is a verification plan—not a claim that the project is already reliable.