Related Pages

Related topics: Skills Library: Testing, Debugging, and Collaboration, Harness Integration, Plugin Manifests, and Porting

Introduction, Installation, and Basic Workflow

Superpowers is an agentic skills and workflow framework that ships reusable, opinionated "skills" — small markdown-defined procedures — that AI coding harnesses (Claude Code, GitHub Copilot CLI, Gemini CLI, etc.) can invoke to follow consistent engineering practices. Skills such as brainstorming, writing-plans, and executing-plans are first-class, and the project uses hooks to inject them automatically at session start.

What Superpowers Provides

Superpowers is not a model or an IDE. It is a harness-agnostic overlay that gives any compatible AI coding agent a shared set of practices. The README describes it as "skills and workflows for AI coding agents" that should be loaded automatically by supported harnesses via a SessionStart hook. Source: README.md:1-40.

The framework has two layers:

• Skills — markdown files under skills/ that describe intent, inputs, and required outputs for one workflow (e.g., brainstorming produces a spec; writing-plans produces a plan from a spec). Each skill defines when it should be invoked and what the agent must do before and after.
• Hooks — small scripts wired into the host harness that bootstrap the skill catalog into the agent's context at the start of each session and can run validation or telemetry on tool calls.

Installation

Installation is intentionally minimal because Superpowers is content, not a service. The supported approach, documented in the README, is to add the Superpowers repository as a Claude Code plugin (or the equivalent integration for your harness). Source: README.md:42-90.

For Claude Code, the project ships a .claude/settings.json describing plugin entries and a SessionStart hook; for Copilot CLI, the same hook emits the SDK-standard additionalContext JSON envelope when the COPILOT_CLI environment variable is detected. Source: CHANGELOG.md:1-60.

Other harnesses are added by writing a thin adapter that calls the same hook and forwards its output, following the porting guide. Source: docs/porting-to-a-new-harness.md:1-80. The general adoption flow is:

1. Clone or vendor the repository into a location your harness scans for plugins/skills.
2. Register the SessionStart hook (the exact mechanism varies by harness).
3. Confirm the bootstrap by starting a new session and asking the agent to list available skills.

The package.json exists primarily to support the brainstorm server (an MCP-style helper used by the brainstorming skill) and declares ESM-friendly scripts; a fix in v5.0.5 renamed server.js to server.cjs so require() works under Node 22+ where the root manifest declares "type": "module". Source: CHANGELOG.md:30-60.

Core Skills and the Basic Workflow

The daily-use workflow is a three-stage pipeline exposed as skills:

1. superpowers:brainstorming — explores intent and turns a vague request into a written spec. The brainstorming skill runs a local HTTP server (spawned by the hook) that the agent uses to manage spec state. Source: README.md:42-90.
2. superpowers:writing-plans — converts an approved spec into an executable plan with discrete tasks. Plans are normally written to docs/superpowers/plans/ unless overridden. Source: docs/using-superpowers.md:1-60.
3. superpowers:executing-plans — runs the plan, often dispatching implementation work to subagents via subagent-driven-development.

A complementary skill, using-superpowers, is the meta-skill that tells the agent to always check the skill catalog before acting — it is what guarantees skills are used automatically rather than only when explicitly named. Source: docs/using-superpowers.md:1-60.

The same flow is mirrored in the harness-specific instruction files (CLAUDE.md, AGENTS.md, GEMINI.md), which contain the per-harness bootstrap instructions the SessionStart hook emits. Source: CLAUDE.md:1-40, AGENTS.md:1-40, GEMINI.md:1-40.

Harness Support and Recent Changes

Superpowers supports multiple harnesses through adapters rather than forking the core. Documented and shipped adapters include Claude Code, GitHub Copilot CLI (added in v5.0.7), and Gemini CLI, with community-requested adapters for Hermes Agent (issue #1581), Google Antigravity (issue #1636), and Pi Agent (issue #1685). Source: CHANGELOG.md:1-30, docs/porting-to-a-new-harness.md:1-80.

Notable behavior changes that affect the basic workflow:

• v5.1.0 removed the legacy /brainstorm, /execute-plan, and /write-plan slash commands because they were no-op stubs that simply redirected users to the real skills. Users now invoke superpowers:brainstorming, superpowers:executing-plans, and superpowers:writing-plans directly. Source: CHANGELOG.md:1-30.
• v5.0.6 replaced the subagent review-loop (which dispatched a fresh agent to review plans/specs) with inline self-review after regression testing showed the review loop added ~25 minutes of overhead without measurable quality gains. Source: CHANGELOG.md:1-30.
• v5.0.7 taught the SessionStart hook to detect COPILOT_CLI and emit the SDK-standard additionalContext JSON envelope, giving Copilot CLI users the full bootstrap context. Source: CHANGELOG.md:1-30.

Users following the default plan location should also be aware of issue #1690, which notes that plans written to docs/superpowers/plans/ can be picked up by documentation tools such as Sphinx/Read the Docs; the recommended mitigation is to relocate plans or exclude that path from the docs build. Source: community context referencing issue #1690.

Getting Started Checklist

To verify a fresh installation, run this minimal sequence:

1. Start a session in any supported harness. The SessionStart hook should emit the skill catalog and the using-superpowers instructions.
2. Ask the agent to list available skills — expect to see brainstorming, writing-plans, executing-plans, and using-superpowers at minimum.
3. Pose a small feature request; the agent should invoke superpowers:brainstorming rather than coding immediately, then superpowers:writing-plans, then superpowers:executing-plans.
4. For subagent-driven work, confirm subagent-driven-development is loaded and review issue #1631, which notes that model-selection guidance is currently advisory rather than enforced at worker dispatch.

If a step is missing, consult docs/porting-to-a-new-harness.md to verify the hook is wired correctly for your specific harness. Source: docs/porting-to-a-new-harness.md:1-80.

Related Pages

Related topics: Introduction, Installation, and Basic Workflow, Subagent-Driven Development: Dispatch, Review, and Workspaces

Skills Library: Testing, Debugging, and Collaboration

The Superpowers skills library is a curated set of behavioral specifications (called "skills") that an AI coding agent invokes to enforce disciplined engineering practices. Each skill is a self-contained Markdown document with frontmatter that describes a workflow, the triggers that activate it, and the rules the agent must follow.

The testing, debugging, and collaboration subset covers the disciplines that turn raw code generation into reliable software engineering work. Rather than acting as ad-hoc advice, these skills are explicit protocols with defined steps, anti-patterns, and exit conditions. Source: README.md

Purpose and Scope

The meta-skill using-superpowers defines how an agent should discover and apply skills throughout any session. It establishes that skills are mandatory whenever triggered: the agent reads the relevant SKILL.md, follows it, and does not skip steps even when it believes it already knows the answer. Source: skills/using-superpowers/SKILL.md

The testing/debugging/collaboration cluster sits between two larger families in the library:

• Upstream — skills like brainstorming and writing-plans that define what to build before any code is written. Source: skills/using-superpowers/SKILL.md
• Downstream — skills like executing-plans that consume approved plans. The middle cluster ensures that the code produced inside those plans is correct, debugged, and reviewed. Source: skills/using-superpowers/SKILL.md

Three concerns dominate this cluster: writing code that proves itself (testing), fixing code that isn't right (debugging), and shipping code that other humans or agents can trust (collaboration).

Testing Skills

Test-Driven Development

test-driven-development enforces the red/green/refactor discipline at the unit and integration level. The skill prescribes writing the failing test first, watching it fail for the expected reason, then writing only enough production code to make it pass, and finally refactoring while keeping the suite green. Source: skills/test-driven-development/SKILL.md

The skill explicitly forbids common shortcuts:

• No production code before a failing test exists for the current change.
• No skipping tests after they pass to "clean up later."
• No assertion-free tests ("does it not throw?") in place of behavioral assertions. Source: skills/test-driven-development/SKILL.md

It pairs naturally with verification-before-completion, which the agent runs before claiming any task is done. The verification skill defines what counts as evidence — running tests, reading output, checking exit codes — so the agent cannot mark work complete on the basis of intent. Source: skills/verification-before-completion/SKILL.md

Verification Before Completion

This skill exists precisely because agents often assert success without proof. It lists concrete checks (command run, output observed, files changed) that must accompany any completion claim. Community discussion around v5.0.6 documented that inline self-review replaced the earlier subagent review loop for plan/spec quality after regression testing showed identical quality scores without the extra dispatch. Source: skills/verification-before-completion/SKILL.md

Debugging Skills

Systematic Debugging

systematic-debugging rejects guess-and-check debugging. Its steps are:

1. Reproduce the bug reliably.
2. Isolate the failure with the smallest possible input.
3. Form a hypothesis about the mechanism, not just the symptom.
4. Test that hypothesis against the running code.
5. Fix the root cause, then verify the original repro is gone. Source: skills/systematic-debugging/SKILL.md

The skill prohibits "fixing" by suppressing symptoms (e.g., adding a try/catch that swallows the exception, or padding a string to avoid a parsing error). Each fix must be traceable back to a root cause that was confirmed, not assumed. Source: skills/systematic-debugging/SKILL.md

Root Cause Tracing

When a failure surfaces far from its cause (a UI crash triggered by a database row written hours earlier), root-cause-tracing provides the protocol for following the chain backward. It distinguishes between the proximate cause (the line that threw) and the actual cause (the earlier decision that put the system in the bad state), and it requires agents to keep tracing until they find the earliest decision the agent or team made wrong. Source: skills/root-cause-tracing/SKILL.md

Collaboration Skills

Code Review (Asking and Receiving)

Two companion skills cover the review lifecycle. requesting-code-review defines what an agent must produce before handing work to a human or peer agent: the diff, the test evidence, the known limits, and explicit questions for the reviewer. reviewing-code defines the reviewer's checklist: correctness, test coverage, security implications, alignment with the plan, and clarity. Source: skills/requesting-code-review/SKILL.md, Source: skills/reviewing-code/SKILL.md

As of v5.0.6, what the release notes call "inline self-review" replaced the prior dispatch-a-subagent-to-review flow for plans and specs. The collaboration skills in this cluster still target the human or peer-agent case, not self-review. Source: skills/reviewing-code/SKILL.md

Subagent-Driven Development

For multi-agent workflows, subagent-driven-development sets the contract between a coordinating agent and worker agents. It defines how a task is decomposed, what context a worker receives, and how results are merged back. Community discussion in issue #1631 noted that the skill's guidance to use the least powerful model capable for each worker role is currently not enforced at dispatch time — workers inherit the parent agent's model — which is a known gap rather than intended behavior. Source: skills/subagent-driven-development/SKILL.md

Issue #601 tracks a complementary feature request to accumulate discoveries across tasks and surface them to subsequent subagents, so today's workers still start largely fresh per task. Source: skills/subagent-driven-development/SKILL.md

How They Fit Together

A typical session that uses this cluster proceeds through verification gates rather than branching freely. The diagram summarizes the order in which the skills normally trigger.

flowchart LR
  A[TDD: red-green-refactor] --> B[Verify before completion]
  B --> C{Defect found?}
  C -- yes --> D[Systematic debugging]
  D --> E[Root cause tracing]
  E --> A
  C -- no --> F[Request code review]
  F --> G[Reviewing code]
  G --> H[Subagent handoff if needed]

Skills are loaded lazily by trigger: the agent does not run systematic-debugging until a defect actually appears, and it does not run reviewing-code until a review is requested. Source: skills/using-superpowers/SKILL.md

Limitations to Be Aware Of

• Cross-session memory is not part of these skills; issue #551 tracks an open request for a core project memory system so learnings from one session inform the next.
• The default docs/superpowers/ location used by writing-plans/brainstorming can leak internal plans into published documentation; issue #1690 documents this for projects using Sphinx or Read the Docs.
• Inline self-review does not catch everything a dedicated reviewer would, so the collaboration skills remain relevant for high-stakes changes.

Source: skills/using-superpowers/SKILL.md, Source: skills/test-driven-development/SKILL.md, Source: skills/systematic-debugging/SKILL.md, Source: skills/verification-before-completion/SKILL.md, Source: skills/subagent-driven-development/SKILL.md

Related Pages

Related topics: Introduction, Installation, and Basic Workflow, Skills Library: Testing, Debugging, and Collaboration

Harness Integration, Plugin Manifests, and Porting

Superpowers is designed to be harness-agnostic: the core skills and workflows live in repository content, while each supported agent runtime ("harness") reads a small manifest that describes how to surface those skills, commands, and hooks in its native format. The harness integration layer is the set of directories, JSON manifests, and bootstrap scripts that make this possible.

Purpose and Scope

The harness integration layer exists so that a single source tree of skills (e.g. superpowers:brainstorming, superpowers:writing-plans, superpowers:executing-plans) can be exposed through several different agent harnesses without forking the skill content. Each harness has its own conventions for declaring plugins, registering slash commands, and injecting bootstrap context, so the repo ships a dedicated manifest directory for each supported runtime.

The community has repeatedly asked for additional harnesses — including Hermes Agent (Source: [issues/1581]), Pi Agent (Source: [issues/1685]), and Google Antigravity 2.0 (Source: [issues/1636]) — which confirms that the manifest-per-harness pattern is the intended extension point rather than special-casing inside the skills themselves.

Plugin Manifest Structure

Every supported harness has a dedicated top-level directory whose name starts with a dot and ends with -plugin (for example, .claude-plugin/, .codex-plugin/, .cursor-plugin/, .kimi-plugin/). Inside each directory lives at minimum a plugin.json file that the host runtime reads to discover metadata, commands, agents, and hook entry points. The shared marketplace listing for plugin discovery across harnesses is aggregated in .agents/plugins/marketplace.json and the Claude-specific marketplace index in .claude-plugin/marketplace.json.

Because the manifest shapes differ per harness, the values inside each plugin.json are intentionally minimal and stable: identity fields (name, version, description) and the list of entry points or paths the harness should load. The actual skill bodies, commands, and prompts remain in the shared content tree and are referenced (not duplicated) from the manifests, which keeps the surface area for drift small. Source: .claude-plugin/plugin.json

Bootstrap and Context Injection

Beyond static manifests, several harnesses rely on a session-start hook to inject Superpowers bootstrap context. The v5.0.7 release notes describe how the session-start hook detects the COPILOT_CLI environment variable and emits the SDK-standard { "additionalContext": "..." } payload so Copilot CLI users receive the same bootstrap as Claude Code users. Source: releases/v5.0.7

This pattern — environment detection inside a single hook implementation — is what makes adding a new harness a localized change rather than a fork of the skill runtime. A new harness typically needs:

1. A new top-level manifest directory (e.g. .hermes-plugin/) with a plugin.json whose schema matches that harness.
2. A discovery or marketplace entry, usually in .agents/plugins/marketplace.json so install commands can find it.
3. A bootstrap path, either through the harness's native context-injection hook or by detecting its environment variables inside the existing session-start hook.
4. Any command-name remapping required by the harness (for example, the v5.1.0 removal of legacy /brainstorm, /execute-plan, and /write-plan slash commands in favor of direct skill invocation). Source: releases/v5.1.0

Porting to a New Harness

Porting Superpowers to a new harness is treated as an additive, additive-only operation: no skill content should need to change, only the manifest, hook, and (if necessary) command-name layer. The reported feature requests for Hermes Agent and Pi Agent (Source: [issues/1581], Source: [issues/1685]) both describe this shape — the requester wants the existing skills available in the new harness's native format, not a new skill design.

The same pattern applies to experimental integrations such as Antigravity 2.0, which the community notes can be wired in with a shell wrapper around the existing skills (Source: [issues/1636]) before a first-class manifest exists. Once that wrapper proves useful, the maintainers promote it to a dedicated .agy-plugin/ (or equivalent) directory with a plugin.json, after which the shell workaround can be retired.

Known limitations of this approach show up where a harness diverges from the shared assumptions: for example, the OpenClaw/oMLX integration error (Source: [issues/1693]) is downstream of model-runtime configuration rather than the harness manifest, but it illustrates that the manifest layer cannot insulate users from harness-specific runtime quirks. Porters should therefore document harness-specific caveats in the manifest directory's own README rather than in the shared skill docs.

In summary, the harness integration layer is intentionally thin: a plugin.json per supported runtime, a shared marketplace index, and a session-start hook that adapts to the active harness via environment detection. New harnesses are added by following that pattern, not by editing skill content.

Related Pages

Related topics: Skills Library: Testing, Debugging, and Collaboration, Harness Integration, Plugin Manifests, and Porting

Subagent-Driven Development: Dispatch, Review, and Workspaces

Subagent-Driven Development (SDD) is a meta-workflow in the Superpowers skills framework that splits a multi-task plan into independently dispatched subagents, each working in an isolated workspace and producing a reviewable artifact. The skill coordinates implementer dispatch, reviewer evaluation, and workspace lifecycle through a small set of prompt templates and helper scripts under skills/subagent-driven-development/. Source: skills/subagent-driven-development/SKILL.md:1-40

Architecture and Workflow

The SDD workflow is organized around three roles and three file types. The owner process holds the parent plan and orchestrates dispatch; the implementer role executes a single task in isolation; the reviewer role evaluates the produced package and either returns it for revision or stamps it approved. The owner never edits task artifacts directly — it only relays verdict summaries and routes the next step. Source: skills/subagent-driven-development/SKILL.md:40-90

The dispatch pipeline is intentionally fresh-state: each implementer subagent starts with no prior conversation context, and instead receives a state file plus a dedicated implementer prompt. This prevents task bleed but also means cross-task discoveries are not automatically propagated (see Community Issue #601 for an open feature request to accumulate learnings across tasks). Source: skills/subagent-driven-development/SKILL.md:90-120

flowchart LR
    Owner[Owner / Parent Agent] -->|reads plan + state| Dispatch
    Dispatch -->|implementer-prompt.md + workspace| Impl[Implementer Subagent]
    Impl -->|writes code + status| WS[(Workspace Dir)]
    Impl -->|emits package| Rev[Task Reviewer]
    Rev -->|reviews via review-package| Verdict{Verdict}
    Verdict -->|approve| Done[Mark Approved]
    Verdict -->|revise| Rev2[Re-review Loop]
    Rev2 --> Rev
    Done --> Next[Next Task]
    Next --> Dispatch

Dispatch: Implementer Prompt and Model Selection

The implementer is launched by filling the template implementer-prompt.md, which lists the task scope, the workspace path, the repository path, and the verification commands the implementer must run before signaling completion. The prompt instructs the subagent to remain within the workspace, write a structured status file, and stop without attempting follow-up tasks. Source: skills/subagent-driven-development/implementer-prompt.md:1-60

A documented limitation in the current design is that model selection guidance is advisory rather than enforced: the skill recommends using the least powerful model that can handle each role, but the dispatch templates name the worker agent type only, so workers inherit the parent model from the harness. Source: skills/subagent-driven-development/SKILL.md:60-80, tracked in Community Issue #1631. This means cost/quality trade-offs depend on the calling harness rather than the skill itself.

Each implementer runs in its own workspace directory produced by the sdd-workspace helper, which stages the repository tree, copies shared fixtures, and exports the absolute path back to the dispatcher. Source: skills/subagent-driven-development/scripts/sdd-workspace:1-80

Review: Task Reviewer, Re-review, and the review-package Tool

Review is performed by a separate subagent using task-reviewer-prompt.md. The reviewer receives the implementer's workspace, the relevant plan excerpt, and the rubric (typically Correctness, Tests, Style, Spec Coverage). The reviewer must produce a structured verdict — either approved or needs_revisions with a numbered list of blocking issues — and writes this into the package alongside an inline summary. Source: skills/subagent-driven-development/task-reviewer-prompt.md:1-90

The scripts/review-package helper is the deterministic side of the review pipeline: it locates the package manifest produced by the implementer, validates required fields, and prepares the input handed to the reviewer subagent. Because the script is a thin wrapper, reviewers can be re-run idempotently without re-executing the implementer. Source: skills/subagent-driven-development/scripts/review-package:1-60

When the verdict is needs_revisions, the owner routes the same package back through the implementer with the blocker list, then re-evaluates using re-review-prompt.md. The re-review prompt is intentionally lighter than the initial reviewer — it only checks that each previously flagged blocker is addressed and that no new regressions were introduced. This two-stage loop is the reason SDD review cycles stay bounded even after multiple revisions. Source: skills/subagent-driven-development/re-review-prompt.md:1-50

Note: as of v5.0.6, the broader Superpowers project moved most plan/spec review to inline self-review rather than fresh subagent review loops, after regression testing showed identical quality scores without the ~25 min overhead. The SDD skill retains its subagent review loop because it operates across isolated workspaces where the parent cannot directly inspect uncommitted changes. Source: skills/subagent-driven-development/SKILL.md:30-50

Workspaces and Lifecycle

sdd-workspace is the only script that mutates on-disk state beyond the task package itself. It accepts a plan identifier and task index, creates a directory under the configured SDD root, symlinks or copies the repository tree, and writes a workspace.json manifest containing the task ID, owner agent, and timestamps. Cleanup is explicit — the owner deletes the workspace only after the task is marked approved and the next task is dispatched, so failed or paused reviews can resume cheaply. Source: skills/subagent-driven-development/scripts/sdd-workspace:30-100

Strict workspace isolation is what makes the inline-self-review limitation above acceptable in SDD: the parent process cannot read the implementer's changes without the workspace manifest, so dispatching a reviewer subagent remains the only reliable way to read the diff. This is the architectural reason SDD still uses a subagent review loop while the rest of the Superpowers workflows do not. Source: skills/subagent-driven-development/SKILL.md:50-70

Known Gaps and Community Discussions

• Model inheritance (Issue #1631): worker model is inherited from the parent harness, not selected per role.
• Cross-task memory (Issue #601): each subagent starts fresh; accumulating discoveries across tasks is an open feature request.
• Workspace defaults (Issue #1690): the default docs/superpowers/ location used by adjacent planning skills can leak internal plans into published Sphinx/Read the Docs builds, so SDD-adjacent workflows should override the root when the repository publishes docs.

Together these gaps suggest that SDD is stable for small, isolated tasks but not yet a turnkey solution for long multi-task plans that need persistent context or per-role model routing.

Doramagic Pitfall Log

Found 39 structured pitfall item(s), including 12 high/blocking item(s). Top priority: Installation risk - Installation risk requires verification.

1. Installation risk: Installation risk requires verification

• Severity: high
• Finding: Project evidence flags a installation risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: community_evidence:github | https://github.com/obra/superpowers/issues/503

2. Installation risk: Installation risk requires verification

• Severity: high
• Finding: Project evidence flags a installation risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: community_evidence:github | https://github.com/obra/superpowers/issues/1997

3. Installation risk: Installation risk requires verification

• Severity: high
• Finding: Project evidence flags a installation risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: community_evidence:github | https://github.com/obra/superpowers/issues/1731

4. Installation risk: Installation risk requires verification

• Severity: high
• Finding: Project evidence flags a installation risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: community_evidence:github | https://github.com/obra/superpowers/issues/743

5. Installation risk: Installation risk requires verification

• Severity: high
• Finding: Project evidence flags a installation risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: community_evidence:github | https://github.com/obra/superpowers/issues/2031

6. Installation risk: Installation risk requires verification

• Severity: high
• Finding: Project evidence flags a installation risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: community_evidence:github | https://github.com/obra/superpowers/issues/2015

7. Installation risk: Installation risk requires verification

• Severity: high
• Finding: Project evidence flags a installation risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: community_evidence:github | https://github.com/obra/superpowers/issues/895

8. Security or permission risk: Security or permission risk requires verification

• Severity: high
• Finding: Project evidence flags a security or permission risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: community_evidence:github | https://github.com/obra/superpowers/issues/1988

9. Security or permission risk: Security or permission risk requires verification

• Severity: high
• Finding: Project evidence flags a security or permission risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: community_evidence:github | https://github.com/obra/superpowers/issues/2001

10. Security or permission risk: Security or permission risk requires verification

• Severity: high
• Finding: Project evidence flags a security or permission risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: community_evidence:github | https://github.com/obra/superpowers/issues/1812

11. Security or permission risk: Security or permission risk requires verification

• Severity: high
• Finding: Project evidence flags a security or permission risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: community_evidence:github | https://github.com/obra/superpowers/issues/512

12. Security or permission risk: Security or permission risk requires verification

• Severity: high
• Finding: Project evidence flags a security or permission risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: community_evidence:github | https://github.com/obra/superpowers/issues/1917

Community Discussion Evidence

Doramagic exposes project-level community discussion separately from official documentation. Review these links before using superpowers with real data or production workflows.

• Add a Slim version - github / github_issue
• Feature request: verdict schema for optional review plugins - github / github_issue
• [[Codex] Official marketplace plugin remains at 5.1.3 while upstream is 6](https://github.com/obra/superpowers/issues/2031) - github / github_issue
• Subagent dispatches outside SDD have no model guidance, so they inherit - github / github_issue
• Design Review not showing the Spec after claude update - github / github_issue
• [[Feature] Dedicated documentation website for Superpowers](https://github.com/obra/superpowers/issues/2030) - github / github_issue
• Windows: SessionStart:startup hook fails when plugin path contains a par - github / github_issue
• SessionStart run-hook.cmd command fails under PowerShell without call op - github / github_issue
• systematic-debugging: find-polluter.sh find -path never matches (silent - github / github_issue
• Im seeing slowness in responses since using the skill - github / github_issue
• Installation risk requires verification - GitHub / issue
• Installation risk requires verification - GitHub / issue