[Feature Request] Distribute OpenSpec as a Superpowers (obra/superpowers) skill pack

[guoguoguilai]

Context

I'm using both OpenSpec and obra/superpowers in my Claude Code workflow. They complement each other well:

• Superpowers provides individual productivity skills (TDD, debugging, planning, etc.)
• OpenSpec provides structured workflow governance (proposal → spec → design → tasks → implementation → verification → archive)

A recent CSDN article compared the two frameworks and concluded that the most effective developers should be "bilingual" — using Superpowers for rapid prototyping and OpenSpec for structured, team-oriented development. I agree with this view.

Request

Is there a way (or a plan) to package OpenSpec's workflow as a Superpowers-compatible skill pack, so that:

1. Users in the Superpowers ecosystem can discover and install OpenSpec via the Superpowers marketplace/plugin system
2. The installation experience is streamlined (e.g., a single openspec skill pack that brings in all /opsx:* commands)
3. Both frameworks can coexist cleanly without manual configuration conflicts

Current State

Right now, I install them separately:

• Superpowers skills live in .claude/skills/ with their own SKILL.md format
• OpenSpec skills also live in .claude/skills/ via openspec init

They work fine side-by-side, but the installation and discovery are completely separate. A user of one framework may never discover the other.

Potential Approaches

• Superpowers plugin: Package OpenSpec as a Superpowers plugin (.claude-plugin/plugin.json format) that users can install from the marketplace
• Skill pack: Bundle the /opsx:* skills into a single installable Superpowers skill pack
• Cross-framework discovery: Add OpenSpec to the Superpowers marketplace or awesome-claude-skills list so users can find it

Why This Matters

• Lowers the barrier for Superpowers users to adopt spec-driven development
• Expands OpenSpec's reach through an established distribution channel
• Validates the "bilingual" approach — tools for speed + process for governance

Would love to hear the team's thoughts on feasibility and interest level.

[mzonghao]

Hello, Could you pls clarify why OpenSpec and Superpowers are intended to be used together?
OpenSpec already includes a propose stage, which seems similar to Superpowers’ brainstorming skill. In addition, both workflows have a planning phase, which appears to overlap.
How do you plan to handle these overlaps or potential conflicts between the two?

[dujiecn]

Hello, Could you pls clarify why OpenSpec and Superpowers are intended to be used together? OpenSpec already includes a propose stage, which seems similar to Superpowers’ brainstorming skill. In addition, both workflows have a planning phase, which appears to overlap. How do you plan to handle these overlaps or potential conflicts between the two?

Let professional tools handle professional tasks. The two tools have different functions.

[mzonghao]

Hello, Could you pls clarify why OpenSpec and Superpowers are intended to be used together? OpenSpec already includes a propose stage, which seems similar to Superpowers’ brainstorming skill. In addition, both workflows have a planning phase, which appears to overlap. How do you plan to handle these overlaps or potential conflicts between the two?

Let professional tools handle professional tasks. The two tools have different functions.

Could you describe the use case in more detail?

The CSDN article was written on 2026/01/19, but as of 2026/03/09, superpowers has been upgraded to v5, which significantly enhanced the spec workflow and also outputs spec and plan documents to the project's docs directory — increasing the overlap with openspec even further.

At this stage, having both coexist is solving a simple problem with a complex solution.

Moreover, the two have fundamentally different design philosophies: one is human-driven, the other is agent-driven.

[dujiecn]

Hello, Could you pls clarify why OpenSpec and Superpowers are intended to be used together? OpenSpec already includes a propose stage, which seems similar to Superpowers’ brainstorming skill. In addition, both workflows have a planning phase, which appears to overlap. How do you plan to handle these overlaps or potential conflicts between the two?

Let professional tools handle professional tasks. The two tools have different functions.

Could you describe the use case in more detail?

The CSDN article was written on 2026/01/19, but as of 2026/03/09, superpowers has been upgraded to v5, which significantly enhanced the spec workflow and also outputs spec and plan documents to the project's docs directory — increasing the overlap with openspec even further.

At this stage, having both coexist is solving a simple problem with a complex solution.

Moreover, the two have fundamentally different design philosophies: one is human-driven, the other is agent-driven.

My core demand is to address the issue of genuine teamwork. Therefore, the specification document needs to be made persistent and standardized. As a product for communication between product managers and technical staff. Programmers only need to implement according to the spec.

[mzonghao]

Hello, Could you pls clarify why OpenSpec and Superpowers are intended to be used together? OpenSpec already includes a propose stage, which seems similar to Superpowers’ brainstorming skill. In addition, both workflows have a planning phase, which appears to overlap. How do you plan to handle these overlaps or potential conflicts between the two?

Let professional tools handle professional tasks. The two tools have different functions.

Could you describe the use case in more detail?
The CSDN article was written on 2026/01/19, but as of 2026/03/09, superpowers has been upgraded to v5, which significantly enhanced the spec workflow and also outputs spec and plan documents to the project's docs directory — increasing the overlap with openspec even further.
At this stage, having both coexist is solving a simple problem with a complex solution.
Moreover, the two have fundamentally different design philosophies: one is human-driven, the other is agent-driven.

My core demand is to address the issue of genuine teamwork. Therefore, the specification document needs to be made persistent and standardized. As a product for communication between product managers and technical staff. Programmers only need to implement according to the spec.

Could you provide a code example?

A repo or detailed documentation describing what standardized documents you've established in openspec, and how those documents are used within superpowers.

Based on your description, my guess is that product and technical managers use openspec to describe what needs to be built overall, then commit that to git, and developers use those spec documents as a basis for development with superpowers?

Is that correct?

[dujiecn]

Hello, Could you pls clarify why OpenSpec and Superpowers are intended to be used together? OpenSpec already includes a propose stage, which seems similar to Superpowers’ brainstorming skill. In addition, both workflows have a planning phase, which appears to overlap. How do you plan to handle these overlaps or potential conflicts between the two?

Let professional tools handle professional tasks. The two tools have different functions.

Could you describe the use case in more detail?
The CSDN article was written on 2026/01/19, but as of 2026/03/09, superpowers has been upgraded to v5, which significantly enhanced the spec workflow and also outputs spec and plan documents to the project's docs directory — increasing the overlap with openspec even further.
At this stage, having both coexist is solving a simple problem with a complex solution.
Moreover, the two have fundamentally different design philosophies: one is human-driven, the other is agent-driven.

My core demand is to address the issue of genuine teamwork. Therefore, the specification document needs to be made persistent and standardized. As a product for communication between product managers and technical staff. Programmers only need to implement according to the spec.

Could you provide a code example?

A repo or detailed documentation describing what standardized documents you've established in openspec, and how those documents are used within superpowers.

Based on your description, my guess is that product and technical managers use openspec to describe what needs to be built overall, then commit that to git, and developers use those spec documents as a basis for development with superpowers?

Is that correct?

Yes, you're right. So, how can we integrate with superpowers? As far as I know, superpowers can also generate documents with separate directories. I expect to leverage the powerful development capabilities of superpowers. Document collaboration and maintenance use openspec.

[mzonghao]

Hello, Could you pls clarify why OpenSpec and Superpowers are intended to be used together? OpenSpec already includes a propose stage, which seems similar to Superpowers’ brainstorming skill. In addition, both workflows have a planning phase, which appears to overlap. How do you plan to handle these overlaps or potential conflicts between the two?

Let professional tools handle professional tasks. The two tools have different functions.

Could you describe the use case in more detail?
The CSDN article was written on 2026/01/19, but as of 2026/03/09, superpowers has been upgraded to v5, which significantly enhanced the spec workflow and also outputs spec and plan documents to the project's docs directory — increasing the overlap with openspec even further.
At this stage, having both coexist is solving a simple problem with a complex solution.
Moreover, the two have fundamentally different design philosophies: one is human-driven, the other is agent-driven.

My core demand is to address the issue of genuine teamwork. Therefore, the specification document needs to be made persistent and standardized. As a product for communication between product managers and technical staff. Programmers only need to implement according to the spec.

Could you provide a code example?
A repo or detailed documentation describing what standardized documents you've established in openspec, and how those documents are used within superpowers.
Based on your description, my guess is that product and technical managers use openspec to describe what needs to be built overall, then commit that to git, and developers use those spec documents as a basis for development with superpowers?
Is that correct?

Yes, you're right. So, how can we integrate with superpowers? As far as I know, superpowers can also generate documents with separate directories. I expect to leverage the powerful development capabilities of superpowers. Document collaboration and maintenance use openspec.

Exactly, that's where I see the functional overlap between openspec and superpowers — the two are converging in functionality and will likely become even more aligned over time.

Perhaps you should wait and see — there may be a unified approach down the road.

[jordanmiguel]

+1 that would be awesome.

[iceking2001]

Indeed, I’ve also noticed that some people are exploring ways to combine the two.

In the following article, there’s a rules example showing how they integrate both through a claude.md file:
https://juejin.cn/post/7605494530017165352

There’s also another article that demonstrates a practical approach using prompts:
https://vocus.cc/article/699e6bf2fd8978000156935e

Their commonality is that both approaches use OpenSpec to manage specifications, while Superpower is used to execute the implementation.