Looking for best practices - multiple parallel specs

[hcguersoy]

Moin folks,

I’m looking for best practices on how to handle the creation of multiple specs and how to work with them over time.
Consider a project where multiple specs are created for different features. For example, an initial spec defines the MVP, and subsequent specs extend this MVP with additional features. These later specs often build on a kind of “foundation” established by the MVP spec.
Currently, each spec is created in its own feature branch, with no awareness of the others.
So how should this be handled?

Should new feature branches be created from the existing 001-mvp branch?
How do you manage this when multiple people are working on spec definitions and later on the specifications and the implementations themselves?

So far, everything I’ve read about spec-kit feels quite “waterfall-like” to me :-(

[mnriem]

How you work with branching is up to you. We are disconnecting the spec creating from the branch creation and making that an opt-in as how you work in your organization might not fit for you. And how you manage your specs depends on how you want. Some folks commit them, others do not.

[franciscoandrades]

It would great to see some examples of this. What happens with incremental, iterative work? we end up having a lot of (sometimes highly redundant) specs. I've been developing a tool to extract similar/common modules and creating some sort of 'spec store' to abstract the specs into modular, interconnected docs easy to visualize. Maybe we should start talking about specOPS 😆