Enhancement: Plugins

[clay-good]

Note

Moved from issue #453, originally opened by @som45oul on 2026-01-07. Continuing the conversation here in Discussions — the original issue thread (including any comments) stays available at #453 for the record.

---

CHANGE TYPE

Complex - breaking change

PROBLEM

One of the strengths of OpenSpec is its simplicity.

Inevitably however varying ideas and requirements can cause "feature sprawl" in the core project, making the code base and UX more complex.

PROPOSAL

Implement a "plugin" system, and keep the core of OpenSpec pure and limited to the four basic commands (init, propose, apply, archive).

Core functionality would ship with the project as "default plugins" so the architecture is consistent. The community could develop or propose new features that could be added or removed from a plugins/ folder, making OpenSpec into a platform/ecosystem, rather than a monolith.

BENEFITS

• OpenSpec itself can stay pure and lightweight, avoiding the bloat some other similar tools are currently seeing.
• Users can add or remove plugin functionality as necessary for each project
• New features can be implemented as optional add-ons, rather than making changes to the core

CHALLENGES

• Could involve a significant rework of the current code
• May involve additional complexity that is hard to quantify at this point

[LunaticMuch]

+1 There could be many legitimate reasons for extending the openspec workflow. This is already available in other solutions like GitHub Speckit. Despite it is possible to achieve some customization using agents, I think a native plugin system would make easier and better any extension.