Related Pages

Related topics: Skills Library and Development Methodology, Brainstorming, Planning, and Subagent-Driven Execution, Harness Runtime, Branch Lifecycle, and Operations

Overview, Philosophy, and Installation

What Is Superpowers

Superpowers is a plugin/extension framework that augments AI coding agents with a curated, versioned library of reusable "skills" — structured prompt procedures and workflows that the agent invokes during a session. Rather than relying on a single monolithic system prompt, Superpowers delivers modular process guidance that an agent loads on demand from the skills/ directory.

The project ships as a single repository that provides:

• A core using-superpowers bootstrap skill that is injected into every session
• A catalog of named skills, for example superpowers:brainstorming, superpowers:writing-plans, and superpowers:executing-plans
• Harness-specific glue code and SessionStart hooks so the skills are available across multiple IDE/agent environments, with per-harness entry points documented in AGENTS.md, CLAUDE.md, and GEMINI.md

Source: README.md Source: skills/using-superpowers/SKILL.md Source: AGENTS.md

Core Philosophy

Superpowers is built on three recurring principles that shape both the skill design and the contribution conventions:

1. Skills over ad-hoc prompts. Every recurring workflow is a versioned skill file in the skills/ directory. Agents are instructed to consult the matching skill before improvising, so behavior is consistent across runs and contributors. The using-superpowers skill acts as the entry point that maps user intent to the right skill.
2. Compounding knowledge. The project is explicitly influenced by "compound engineering" ideas (community issue #230): each session is encouraged to leave behind extracted learnings, updated plans, and refined skills so the next session starts smarter than the last. Issue #601 tracks cross-task knowledge accumulation for subagent-driven-development, and issue #551 proposes a project-level memory system for retrieval across sessions.
3. Explicit process before code. Most skills enforce a "brainstorm → plan → execute" loop: superpowers:brainstorming clarifies intent, superpowers:writing-plans produces a plan, and superpowers:executing-plans carries it out. Plans are first-class artifacts (typically written under docs/superpowers/plans/) and using-superpowers directs the agent to prefer them over free-form action.

The project also deliberately keeps the surface area narrow. As of v5.1.0, the legacy /brainstorm, /execute-plan, and /write-plan slash commands were removed because they were deprecation stubs that just told the user to invoke the underlying skill directly. Users are expected to invoke superpowers:skill-name instead.

Source: RELEASE-NOTES.md Source: skills/using-superpowers/SKILL.md

Architecture at a Glance

flowchart LR
    A[Agent Session] -->|SessionStart hook| B[using-superpowers skill]
    B -->|injects core rules| A
    A -->|requests workflow| C[brainstorming]
    A -->|requests workflow| D[writing-plans]
    A -->|requests workflow| E[executing-plans]
    A -->|requests workflow| F[other skills...]
    C --> G[docs/superpowers/plans/*.md]
    D --> G
    E --> G

The bootstrap is performed by the harness's SessionStart hook, which detects the active environment (for example the COPILOT_CLI environment variable for GitHub Copilot CLI) and emits the SDK-standard additionalContext payload, as introduced in v5.0.7. The same pattern is used for Claude Code and the Gemini harness, with the per-harness configuration in AGENTS.md, CLAUDE.md, and GEMINI.md.

Source: AGENTS.md Source: CLAUDE.md Source: GEMINI.md Source: RELEASE-NOTES.md

Installation and First Run

Superpowers is distributed as a plugin for Claude Code and as comparable packages for other supported harnesses. The general install path documented in the README is:

# Claude Code (illustrative)
claude plugin install superpowers@claude-plugins-official

After installation, start a new session in your project. The SessionStart hook will automatically load skills/using-superpowers/SKILL.md and inject the bootstrap context. You can confirm the bootstrap worked by asking the agent to describe its available superpowers, or by invoking superpowers:brainstorming directly to begin a structured design conversation.

Common Installation Pitfalls

• Deprecated slash commands. Until v5.1.0, new installs shipped legacy /brainstorm, /execute-plan, and /write-plan commands alongside the current skills, which confused new users (issue #756). v5.1.0 removes those stubs entirely; use the superpowers:skill-name form instead.
• Harness coverage is uneven. Some environments (Google Antigravity in issue #270, Hermes Agent in #1581, Pi Agent in #1685) are not yet first-class targets. Until native packages exist, the README typically suggests a shell wrapper that prepends a "read and follow the superpowers repo" instruction to the agent's invocation, similar to the agy-start workaround in issue #1636.
• Plan output location. The default docs/superpowers/ directory can collide with published documentation (issue #1690). If you publish a Sphinx or Read the Docs site, configure your plan output path or exclude docs/superpowers/ from your docs build to avoid leaking internal plans.

Verifying a Clean Install

1. Start a fresh session in a test directory.
2. Confirm no /brainstorm, /execute-plan, or /write-plan slash commands appear in the agent's command palette (v5.1.0+).
3. Ask the agent to list the superpowers:* skills it can invoke; using-superpowers, brainstorming, writing-plans, and executing-plans should always be present.
4. Run superpowers:brainstorming on a small problem and confirm the plan lands under docs/superpowers/plans/ (or your configured path).

Source: README.md Source: RELEASE-NOTES.md Source: skills/using-superpowers/SKILL.md

See Also

• The using-superpowers skill is the entry point for every session; consult it for the canonical list of available skills.
• AGENTS.md, CLAUDE.md, and GEMINI.md document per-harness configuration and SessionStart hooks.
• RELEASE-NOTES.md tracks breaking changes, including the v5.1.0 removal of legacy slash commands and the v5.0.6 shift to inline self-review.
• Related community discussions: issues #230 (compounding workflows), #429 (Claude Code Agent Teams), #551 (project memory), #601 (cross-task learning), #756 (deprecated commands), #895 (plan over-specification), #1631 (model selection enforcement at dispatch), and #1690 (plan output location).

Related Pages

Related topics: Overview, Philosophy, and Installation, Brainstorming, Planning, and Subagent-Driven Execution, Harness Runtime, Branch Lifecycle, and Operations

Skills Library and Development Methodology

Overview

The Superpowers project ships a Skills Library: a curated collection of structured, invocable methodologies that an AI coding agent loads on demand to guide its behavior. Each skill is a self-contained Markdown document that defines a process, a set of rules, and expected outputs for a specific phase of software work (e.g., brainstorming, writing plans, executing plans, testing, debugging). Skills are not prompts in the conventional sense; they are *contracts* that override the agent's default heuristics.

The library is bootstrapped by the using-superpowers meta-skill, which is the first thing an agent is expected to consult in any session. As described in skills/using-superpowers/SKILL.md, the meta-skill establishes the principle that every skill exists for a reason, and the agent must always be operating under at least one relevant skill before taking action. If no skill clearly applies, the agent is required to ask the user how to proceed rather than improvising.

Anatomy of a Skill

A skill file is a Markdown document with a stable internal structure:

• Frontmatter / metadata — declares the skill's name, the conditions that trigger it, and the situations where it does *not* apply.
• When to Use — explicit triggers (e.g., "before any non-trivial code change").
• Core Principle — the one-sentence rule that anchors the methodology.
• Process — a numbered sequence of steps the agent must follow.
• Output Contract — the deliverable the skill is expected to produce (a plan file, a test, a debug report, etc.).

The trigger discipline matters: skills like using-superpowers require the agent to read the trigger list of every available skill and select the most specific match, falling back to a clarifying question when the match is ambiguous. This prevents the agent from skipping a methodology because it failed to recognize the trigger.

Core Development Methodology Skills

The library is organized around the lifecycle of a software change. The two most heavily exercised families are Test-Driven Development and Systematic Debugging.

Test-Driven Development (TDD)

The TDD skill enforces a strict red-green-refactor cycle. According to skills/test-driven-development/SKILL.md, the methodology requires that production code is written only in response to a failing test, and that the agent resists the temptation to write implementation first "just this once." The skill explicitly warns that skipping steps "always costs more time than it saves."

A companion file, skills/test-driven-development/testing-anti-patterns.md, catalogs the failure modes the agent must avoid: testing implementation details rather than behavior, asserting on mock internals, writing tests that pass without exercising any code path, and producing tautological assertions (expect(true).toBe(true)). The anti-patterns list is treated as a checklist that the agent re-reads before declaring a test "done."

Systematic Debugging

When a test fails or a bug is reported, control passes to the debugging family. The entry point, skills/systematic-debugging/SKILL.md, declares a non-negotiable rule: find the root cause before attempting a fix. Guess-and-check patching is explicitly prohibited because it tends to mask symptoms while introducing regressions.

Two supporting documents extend the core skill:

• skills/systematic-debugging/root-cause-tracing.md provides a heuristic for walking backward from an observed failure (e.g., a wrong return value) through the call chain to the point where incorrect state first entered the system.
• skills/systematic-debugging/defense-in-depth.md prescribes validating inputs at every layer a value crosses, so that an error detected deep in the stack is caught at the boundary where it was introduced rather than at the symptom site.

Skill Interaction and Workflow

Skills are not invoked in isolation. A typical session flows through several in sequence: brainstorming → writing-plans → executing-plans → TDD/debugging sub-skills as needed. The using-superpowers meta-skill governs the transitions, requiring the agent to check the trigger list at each phase boundary rather than carrying a skill forward out of habit.

The diagram below summarizes the relationship between the meta-skill, the TDD family, and the debugging family.

flowchart TD
    A[Session Start] --> B[using-superpowers: select skill]
    B --> C{Task type}
    C -- "new code" --> D[test-driven-development]
    C -- "bug" --> E[systematic-debugging]
    D --> F[Red: write failing test]
    F --> G[Green: minimal implementation]
    G --> H[Refactor]
    H --> I{Test passes?}
    I -- No --> E
    I -- Yes --> J[Done]
    E --> K[root-cause-tracing]
    K --> L[defense-in-depth validation]
    L --> D

Community context reinforces the importance of this ordering. Issue #895 reported that plans produced under writing-plans sometimes over-specify implementation details, denying the executing agent the judgment that the TDD loop is designed to exercise. The skills are expected to cooperate: writing-plans should describe *what* and *why*, leaving the *how* to TDD's red-green-refactor rhythm.

Community Considerations and Known Gaps

Several open issues illustrate how the methodology interacts with broader project direction. Issue #551 requests a core project memory system so that the reasoning captured by one skill invocation (e.g., the "why" behind a design decision in writing-plans) is recoverable in a later session — a gap that the current skill library cannot bridge because skills are stateless between sessions.

Issue #1690 highlights a side-effect of writing-plans and brainstorming writing to a default docs/superpowers/ directory: for projects that publish documentation via Sphinx or Read the Docs, internal planning artifacts can leak into the public site. Users are advised to either relocate the output or exclude the directory in their docs configuration.

Finally, the v5.0.6 release notes (v5.0.6) describe the inline self-review replacement for subagent review loops, motivated by regression data showing that a fresh subagent reviewer added roughly 25 minutes of execution time without improving plan quality. The methodology is still evolving: the skills define the *what*, but the surrounding harness determines the *how much*.

See Also

• Brainstorming and Planning Workflow — the upstream skills that feed work into TDD.
• Subagent-Driven Development — how multiple skill invocations are coordinated across dispatched agents.
• Harness Support Matrix — which agent runtimes (Claude Code, Copilot CLI, Hermes, Antigravity, etc.) currently load the skills library.

Related Pages

Related topics: Overview, Philosophy, and Installation, Skills Library and Development Methodology, Harness Runtime, Branch Lifecycle, and Operations

Brainstorming, Planning, and Subagent-Driven Execution

Overview

The superpowers plugin coordinates three complementary skills that form a single pipeline from a raw idea to executed code:

1. superpowers:brainstorming — turns a vague request into a written spec.
2. superpowers:writing-plans — turns the spec into an executable plan.
3. superpowers:executing-plans / superpowers:subagent-driven-development — carries out the plan, either inline or by dispatching subagents.

These skills are not exposed as legacy slash commands; in v5.1.0 the /brainstorm, /write-plan, and /execute-plan stubs were removed in favor of invoking the skills directly (Source: skills/brainstorming/SKILL.md:1-30).

The Brainstorming Stage

superpowers:brainstorming is the entry point for any non-trivial request. Its job is to surface requirements, constraints, and design choices before any code is written. The skill is designed to be Socratic — it asks one question at a time and resists jumping to implementation.

A defining feature is the visual companion: a local HTTP server that the agent can open in the user's browser to render diagrams, mockups, and option comparisons while the brainstorm is in progress (Source: skills/brainstorming/visual-companion.md:1-40). The server is implemented in CommonJS as server.cjs and is launched via start-server.sh; the helper.js module wires the agent to its HTTP endpoints (Source: skills/brainstorming/scripts/server.cjs:1-30, Source: skills/brainstorming/scripts/start-server.sh:1-20).

Output of the stage is a spec document. As of v5.0.6, the spec is reviewed by the brainstorming agent itself rather than by a separate reviewer subagent — the older review-loop was removed because regression testing across 5 versions showed identical plan quality with or without the loop, while doubling execution time (Source: release notes v5.0.6).

By default, specs are written into docs/superpowers/specs/, which is convenient but can accidentally publish internal plans via Sphinx/Read the Docs; teams that ship public docs are advised to relocate this path (Source: issue #1690).

The Planning Stage

superpowers:writing-plans consumes a spec and produces a structured plan: ordered tasks, file-by-file change lists, testable acceptance criteria, and explicit checkpoints. The plan is intentionally judgment-friendly — it specifies *what* and *why*, leaving the *how* to the executor (Source: skills/writing-plans/SKILL.md:1-40).

The community has flagged that earlier plan templates over-specified implementation details, leaving executors with little room to adapt to surprises found in the code; the current guidance is to keep plans at the level of intent and acceptance tests (Source: issue #895).

Execution: Inline vs. Subagent-Driven

Once a plan exists, the user can choose between two execution paths:

• superpowers:executing-plans runs the plan inline in the current session.
• superpowers:subagent-driven-development is a meta-skill that dispatches each task to a fresh subagent, runs them in parallel where dependencies allow, and aggregates results (Source: skills/subagent-driven-development/SKILL.md:1-50).

The subagent path is most useful for long, multi-task plans because it isolates context — each worker starts with a clean window — but it sacrifices shared state. A recurring complaint is that workers do not currently inherit the parent agent's model selection, even though the skill recommends using the least powerful model capable of the role; this can cause large, expensive models to be used for simple scaffolding work (Source: issue #1631). There is also an open request to accumulate discoveries from completed workers and feed them into subsequent dispatches so that subagents don't repeatedly rediscover the same facts (Source: issue #601).

End-to-End Flow

flowchart LR
    A[Vague request] --> B[superpowers:brainstorming<br/>+ visual companion]
    B --> C[Spec document<br/>docs/superpowers/specs/]
    C --> D[superpowers:writing-plans]
    D --> E[Plan with tasks<br/>+ acceptance criteria]
    E --> F{Execution mode}
    F -->|Inline| G[superpowers:executing-plans]
    F -->|Parallel workers| H[superpowers:subagent-driven-development]
    G --> I[Shipped change]
    H --> I

See Also

• Release notes — v5.1.0
• Issue #1631 — model selection at worker dispatch
• Issue #601 — accumulate learnings across subagents
• Issue #895 — plans over-specifying implementation
• Issue #1690 — docs/superpowers/ leaking into public docs

Related Pages

Related topics: Overview, Philosophy, and Installation, Skills Library and Development Methodology, Brainstorming, Planning, and Subagent-Driven Execution

Harness Runtime, Branch Lifecycle, and Operations

Overview

The Harness Runtime is the integration layer that lets the Superpowers skills library load inside any agent host (a "harness"). It is responsible for three concerns: detecting which harness is running, adapting Superpowers' event payloads to that harness' wire format, and managing the per-session branch lifecycle (skill bootstrapping, worktree/git operations, session-end cleanup).

A Superpowers installation is delivered as a plugin package — see .claude-plugin/plugin.json and the marketplace descriptor .claude-plugin/marketplace.json — and the same payload is then projected into the native format of each supported harness. As of v5.1.0 the project ships first-class integrations for Claude Code, Cursor, OpenCode, and GitHub Copilot CLI, with community-requested adapters tracked for Antigravity (#270, #1636), Hermes Agent (#1581), and Pi Agent (#1685).

Source: .claude-plugin/plugin.json

Harness Detection and Hook Wire Formats

The runtime detects the active harness at session start and selects the matching hook manifest. Claude Code reads hooks/hooks.json; Cursor reads hooks/hooks-cursor.json. On Windows, hooks/run-hook.cmd is the polyglot shim described in docs/windows/polyglot-hooks.md that lets a .cmd wrapper forward the harness' JSON-over-stdin payload into a POSIX-style script.

OpenCode uses a different integration shape entirely: a JavaScript plugin loaded at startup, .opencode/plugins/superpowers.js, which registers lifecycle callbacks against OpenCode's plugin API rather than the Claude-Code-style hook protocol.

Source: hooks/hooks.json, hooks/hooks-cursor.json, .opencode/plugins/superpowers.js

Environment-driven payload adaptation

The hooks/session-start script is the canonical entry point and performs runtime detection. As of v5.0.7 it inspects the COPILOT_CLI environment variable and, when present, emits the SDK-standard { "additionalContext": "..." } envelope that GitHub Copilot CLI v1.0.11+ expects, instead of the plain-text banner written for Claude Code. This is the template every new harness adapter is expected to follow: detect → switch output format → write the same bootstrap content.

Source: hooks/session-start

Branch Lifecycle

A "branch" in this context is a logical unit of work surfaced to the agent, not necessarily a git branch — though the two are coupled in most workflows. The lifecycle has four phases:

The end-of-session row highlights an active community concern: there is no project-wide memory system for retrieving prior plans or decisions across sessions, which the writing-plans/brainstorming default docs/superpowers/ location was proposed to fill but is not wired into the harness runtime today.

Source: hooks/hooks.json, hooks/hooks-cursor.json

Supported and Requested Harnesses

The following table summarises the current and requested integrations, with the source of evidence for each.

Common Failure Modes and Operational Notes

• Deprecated slash commands confuse new installs. v5.1.0 removed the legacy /brainstorm, /execute-plan, and /write-plan stubs (#1188). Users on older installs may still see them; the fix is to invoke the underlying skills directly (superpowers:brainstorming, etc.).
• Brainstorm server fails to start on Node 22+. v5.0.5 renamed server.js → server.cjs to escape the ESM default of the root package.json; the session-start hook depends on this server, so a missing rename breaks the bootstrap path on fresh installs.
• Plans over-specify implementation. v5.0.6 replaced the subagent review loop with inline self-review after regression testing showed no quality difference and ~25 min overhead. Operators still tuning executor judgment should track Issue #895.
• Windows hook payloads. Native cmd.exe cannot consume a POSIX shebang; always invoke hooks through hooks/run-hook.cmd and follow the polyglot pattern in docs/windows/polyglot-hooks.md.

See Also

• Plugin manifest and marketplace distribution
• Session-start hook reference
• Windows polyglot hooks guide
• Subagent Driven Development — model selection enforcement (#1631)
• Cross-session memory system proposal (#551)

Doramagic Pitfall Log

Found 26 structured pitfall item(s), including 2 high/blocking item(s). Top priority: Security or permission risk - Security or permission risk requires verification.

1. 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 | cevd_a8794497fd53411881056201b8d6df60 | https://github.com/obra/superpowers/issues/1581

2. 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 | cevd_ab70f8b1398247c2832ed51625870194 | https://github.com/obra/superpowers/issues/601

3. Installation risk: Installation risk requires verification

• Severity: medium
• Finding: Developers should check this installation risk before relying on the project: Antigravity 2.0 support
• User impact: Developers may fail before the first successful local run: Antigravity 2.0 support
• Recommended check: Before packaging this project, run the relevant install/config/quickstart check for: Antigravity 2.0 support. Context: Observed during installation or first-run setup.
• Evidence: failure_mode_cluster:github_issue | fmev_3cd7252f6ca5743aa06793d8258fa9c7 | https://github.com/obra/superpowers/issues/1636

4. Installation risk: Installation risk requires verification

• Severity: medium
• Finding: Developers should check this installation risk before relying on the project: Feature Request: Hermes Agent harness support — make Superpowers skills available in native Hermes format
• User impact: Developers may fail before the first successful local run: Feature Request: Hermes Agent harness support — make Superpowers skills available in native Hermes format
• Recommended check: Before packaging this project, run the relevant install/config/quickstart check for: Feature Request: Hermes Agent harness support — make Superpowers skills available in native Hermes format. Context: Observed when using python
• Evidence: failure_mode_cluster:github_issue | fmev_38493ac5020594e127b9094db01ae917 | https://github.com/obra/superpowers/issues/1581

5. Installation risk: Installation risk requires verification

• Severity: medium
• Finding: Developers should check this installation risk before relying on the project: Pi Agent package
• User impact: Developers may fail before the first successful local run: Pi Agent package
• Recommended check: Before packaging this project, run the relevant install/config/quickstart check for: Pi Agent package. Context: Observed during installation or first-run setup.
• Evidence: failure_mode_cluster:github_issue | fmev_81abb08cf2718798d6bf3874d5ab48d6 | https://github.com/obra/superpowers/issues/1685

6. Installation risk: Installation risk requires verification

• Severity: medium
• Finding: Developers should check this installation risk before relying on the project: v5.0.4
• User impact: Upgrade or migration may change expected behavior: v5.0.4
• Recommended check: Before packaging this project, run the relevant install/config/quickstart check for: v5.0.4. Context: Observed when using node
• Evidence: failure_mode_cluster:github_release | fmev_a66cfa915699950289e6adc9ba6aa7e3 | https://github.com/obra/superpowers/releases/tag/v5.0.4

7. Installation risk: Installation risk requires verification

• Severity: medium
• Finding: Developers should check this installation risk before relying on the project: v5.0.7
• User impact: Upgrade or migration may change expected behavior: v5.0.7
• Recommended check: Before packaging this project, run the relevant install/config/quickstart check for: v5.0.7. Context: Observed during installation or first-run setup.
• Evidence: failure_mode_cluster:github_release | fmev_c82f72cff463c8cee7702417638522f8 | https://github.com/obra/superpowers/releases/tag/v5.0.7

8. Installation risk: Installation risk requires verification

• Severity: medium
• 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 | cevd_92f8a9266fce437abbce3b0e8ae92679 | https://github.com/obra/superpowers/issues/551

9. Installation risk: Installation risk requires verification

• Severity: medium
• 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 | cevd_dc7595e0517f44b4b8f034a3891be1ba | https://github.com/obra/superpowers/issues/1685

10. Installation risk: Installation risk requires verification

• Severity: medium
• 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 | cevd_1d7f3ffcaf6d457eaa212b6de6361956 | https://github.com/obra/superpowers/issues/1690

11. Configuration risk: Configuration risk requires verification

• Severity: medium
• Finding: Project evidence flags a configuration 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: capability.host_targets | github_repo:1073224795 | https://github.com/obra/superpowers

12. Configuration risk: Configuration risk requires verification

• Severity: medium
• Finding: Developers should check this configuration risk before relying on the project: An error occurs when calling oMLX v0.4.2.dev2 via OpenClaw
• User impact: Developers may misconfigure credentials, environment, or host setup: An error occurs when calling oMLX v0.4.2.dev2 via OpenClaw
• Recommended check: Before packaging this project, run the relevant install/config/quickstart check for: An error occurs when calling oMLX v0.4.2.dev2 via OpenClaw. Context: Observed when using macos
• Evidence: failure_mode_cluster:github_issue | fmev_d81bff41370623c8daf4066025cfaf5e | https://github.com/obra/superpowers/issues/1693

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.

• subagent-driven-development: Model Selection guidance is not enforced at - github / github_issue
• Feature Request: Add a core project memory system for cross-session retr - github / github_issue
• feat(subagent-driven-development): accumulate learnings across tasks and - github / github_issue
• Feature Request: Hermes Agent harness support — make Superpowers skills - github / github_issue
• Antigravity 2.0 support - github / github_issue
• An error occurs when calling oMLX v0.4.2.dev2 via OpenClaw - github / github_issue
• writing-plans/brainstorming: default docs/superpowers/ location can leak - github / github_issue
• Pi Agent package - github / github_issue
• v5.1.0 - github / github_release
• v5.0.7 - github / github_release
• v5.0.6 - github / github_release
• v5.0.5 - github / github_release