Help shape the OpenSpec roadmap! What do you want to see?

[TabishB]

Hey all!
We pushed out 0.7.0 yesterday. Here’s a look at what’s next:

Near term

• Native integration with all major tools that support custom slash commands (Windsurf. Roo Code, Gemini CLI etc.)
• /verify command to check off specs and tasks more reliably
• Q&A Proposal mode where the agent asks clarifying questions to catch missing details

Longer term

• TUI dashboard (looking at opentui)
• Interactive change walkthrough with progressive disclosure, like reviewing a PR step by step
• Roadmapping features: plan multiple changes and add them to a roadmap. Right now we can only see what changes are proposed, but not the priority or the dependencies between them.

Let us know which of these you are most excited for, and drop any suggestions below.

[nicholas-alonzo]

Would you consider adding Continue as another tool?

[TabishB]

@nicholas-alonzo Hey sure, I'll add it to the roadmap. Seems like they do support slash commands: https://docs.continue.dev/customize/deep-dives/prompts

Do keep in mind openspec works with anything that uses https://agents.md/

[nicholas-alonzo]

Awesome, thank you! I'll take a look at agents.md, still learning about all these tools

[TomLucidor]

I want to see that some of the tricks (including ones in MCP) in BMAD, SuperClaude, and/or Claude Flow can be included in OpenSpec. Ideally OpenSpec can self-evolve to create sub-specs that covers soliciting requirements, tracing/documenting dependencies, and doing CI/CD by default.
"Learning from mistakes" and loop-breaking is also a plus. Documents should not just cover specs, but bug tracing + troubleshooting SOPs such that they can spot potentials for improvement, without nuking the whole codebase. https://github.com/PV-Bhat/vibe-check-mcp-server
Ideally, if there are CLI tooling out there that includes intelligent model routing, have SLMs do simple verification and script execution, while using LLMs to write quality code and thinking deeply about errors. Generalizing CCR would be good https://github.com/musistudio/claude-code-router?tab=readme-ov-file#router

[filipeestacio]

I'd like to see support for different backends. I really want to promote OpenSpec in a corporate setting, but it's being challenged on the practice of saving everything in markdown files.

I appreciate that there are advantages to keeping the notes close to the code, but for the purposes of exposing the specs and progress to non-technical staff or non-developers, it would be great if it could save context in tools like Confluence, Notion, Obsidian, etc and keep track of tasks in Jira or other task managers.

[TomLucidor]

Foam/Obsidian for minimalism and robust MCP options (less vendor locks).

[filipeestacio]

I'm experimenting with Clickup. Ideally it would be a solution leaning on MCP but agnostic from the vendor. Maybe configurable?

[feng7605]

You can consider designing the whole process, development-testing-code submission branch.

[TomLucidor]

Check BMAD first if you want a whole process ready

[mai-dev-j]

I would suggest keep it as simple as it is now, no too many docs and no long list of commands

[rendeyuwei]

1. Depending on the complexity of the task, can the process be adjusted accordingly?
2. Should summarizing lessons learned from tasks and applying them to each subsequent iteration also be established as a standard process?

[airtonix]

Same as @filipeestacio in #111 (comment)

I want to see different ways to store the planning and task artifacts.

I don't want these md files living in the repo where the agents work to implement the changes.

perhaps you can provide plugin interface a way to abstract how these artifacts are created?

Personally, i'd like to see options like:

• LocalFileSystemStore
• BasicMemoryStore
• RemoteObsidianRestStore
• ConfluenceStore
• GithubProjectStore
• JiraStore
• SqliteStore
• VibeKanbanStore
• etc

[benjaminalgreen]

+1 especially for VibeKanbanStore. I'm trying to hack something together for that since I discovered it.

[itsklimov]

I have just installed it and it seems like the framework promotes Sequential execution.

Would be cool to have planning with opportunity for parallel development.
& do development paralleled where possible.

and another think is to use subtasks/subagents where possible to save context window of the main session.

[TabishB]

@itsklimov Yep, there's some better parallel support coming. it's a bit tricky because working on things in parallel leads to spec conflict which we would need to define mechanisms to resolve.

[aleksandr1592]

I’m also very interested in sub-agents - not necessarily running in parallel, although that would be nice. What I really want is the ability to break tasks down so that each agent only has the context it actually needs. It would also be great to introduce roles into the workflow, such as developer and QA.

[WarlockSyno]

I would love for the workflow of https://github.com/GWUDCAP/cc-sessions and this be combined. Sessions is very good at keeping Claude on task and preventing it from making changes that are not approved or planned, but the workflow is lacking without the spec based tasks.

It would be amazing if some of the hooks and scripts that cc-sessions uses were integrated to keep Claude on task. I much prefer to use OpenSpec but Claude likes to do whatever it wants sometimes and forgets what and why we are working on something.

Part of the sessions task creation process has some benefits over the OpenSpec one, but overall OpenSpec is a lot nicer to use.

Oh and the Sessions status line is really nice to use too.

[Karnak19]

What I'd like to see is a ticketing system linking/integration using MCP or CLI during the init command. In my case we are using Linear with the MCP but it should works with any other.

I've modified the commands to ensure:

• the proposal create a ticket
• the apply moves the ticket to in progress, creates a branch, then start to work.
• the archive is moving the ticket to in review, commit, push the branch and opens a PR.

Why ? I fear to use openspec update and have to re-update the part for my Linear integration.

We could go further to also sync our specs in our code and in the cloud to have it shared with non-tech people in the team

[RodrigoGP-RSM]

Have you considered implementing writing specifications as a skill rather than a custom command, or extending the tool using the Open Skill Standard?

[TabishB]

@RodrigoGP-RSM Yes, we'll add official skill support soon. FWIW I don't think skills will drastically change OpenSpec. The way we use AGENTS.md / CLAUDE.md pretty much work like a skill at the moment.

[ShuBuShao]

希望能够支持多语言

[xihangzhou]

I would like to know how to split my spec into small parts that can describe some domain knowledge so that AI can produce more accurate code

[TabishB]

@xihangzhou This is being looked into, I have this problem myself. Will most likely come as a skill for "breakdown"

[harikrishnan83]

• A Constitution (as in Spec-Kit) or Steering Docs (like Kiro) to establish the rules for how the application should be built. The project.md file seems to be a mix of both tech and non-tech and does not seem to be enforced strictly.
• Since OpenSpec is brownfield friendly it will be good to have a separate command like /openspec:baseline? this will clearly articulate that I am currently establishing the source of truth spec and anything here on out will be delta specs. Right now when I introduce OpenSpec to an existing codebase, I am using the project.md to establish baseline and it seems to mix up tech, domain and other aspects.
• Right now design as well as implementation related artifacts are all generated during openspec:apply. If we have an /openspec:plan phase where artifacts such as schema design etc. are created as standards based documents, then it will be easy to review those to make sure those are aligned before we proceed to tasking.

I have not yet not yet fully thought through below point.

• Since many of us may be moving to OpenSpec from other tools, does it make sense provide any optional pathways that help with transitioning without context loss when spec format changes? or is it enough to just ignore those spec formats and let OpenSpec create a baseline spec based on the implementation alone? (I do realise that in other tools the specs may be out of sync with the implementation and that can cause confusion)

[GITHUBWYW]

I have a question about the large language model. Does the openspec support Gemini very well? It seems like the response from Gemini isn't same with Claude.

[TabishB]

@GITHUBWYW OpenSpec works with most models it's just the quality of the results vary depending on the model used. Usually models with high reasoning perform better in general at planning tasks. We recommend using Opus 4.5 and GPT 5.2 at the moment for OpenSpec.

It can still work relatively well with Gemini 3. It's hard to provide instruction sets that are different per model, so it becomes a matter of how well can a model follow instructions.

Either ways in grand scheme of things don't sweat over details like these - just give it a try and see if it produces good results for you :)

[mdlmarkham]

What about using Beads to manage the backlog?