Specify, Plan, and Task phases are too coupled

[Matteaocha]

Context

In team-based (human) software development it is normal for multiple user-stories to inform the architecture and planning stage.

The engineering team takes a list of features that product owners would like to have, as well as long-term goals of the product, and then uses that list to inform an architecture and development strategy.

It may be the case that in order to develop a collection of stories the team needs to schedule enabling work or large-scale refactoring, which cannot be easily linked to a single user story.

Issue

The current design (specify -> plan -> tasks) (with the specify step creating a branch) makes it so that each user story creates an isolated tree of development.

This causes problems:

• design tunnel-vision
• it becomes hard to motivate enabling work

Suggestion for improvement

• Encourage people to run the specify command multiple times up-front so that multiple users stories are collected
• Update the plan stage to consider multiple user stories (essentially, the plan stage should be like an engineering lead - determining the next priorities for work based on what user-stories are out-standing)

[AlbertoBasalo]

This is related to my earlier issue [#265](#265) and builds on the same concern.

The core problem is that spec-kit currently feels like a “one-spec-shot” tool—it’s optimized for single, isolated specifications rather than supporting the broader scope of realistic enterprise projects. In practice, a single PRD (Product Requirements Document) often outlines multiple features or user stories that should be specified together.

It would be incredibly useful to have functionality that:

• Allows generating multiple specs from a single PRD, or
• Supports batch specification workflows that reflect how teams plan across multiple features simultaneously

This would better align with how product and engineering teams work in real-world scenarios, where planning and prioritization happen across a set of interrelated specs—not just one at a time.

[Matteaocha]

Yes exactly.

I mean... in reality I expect that still wouldn't cut it though, as these things often go in a feedback loop in which development strategy leads to a renegotiation of requirements.

What happens in practice is a fairly messy process involving multiple user-stories in different stages of clarity and prioritisation.

The value of a good leader is to keep workers focused on what matters most while accepting that mess.

I suspect that if spec-kit takes the position of acting like that leader, as opposed to just being a workflow, then that might be the way to go.

I could be wrong.

[foertel]

While I agree with the overall sentiment, I think this is out of scope for spec kit, right now. I am sure we might not agree on this, but ... LLMs are not yet capable of handeling the context that comes with deciding multiple specs from a big-picture PRD, let alone manage priorities and decide on ordering of tasks.

At the moment it is more: spec one feature, plan it, do it, steer and correct it, merge it, repeat. (Let's just call it 'agile'. 🙊)

As a compromise I would like to see a way to write up a high-level vision as well as 'lessons learned' and a rough overarching plan that new specs can be based on. I guess, that is kind of what constitution.md is for, but I don't feel like it is really baked into the process.

[raspy8766]

Echoing this concern, which I also detailed in a comment here. The core challenge for us is that product requirements frequently span multiple teams and repositories, making spec-kit difficult to apply in our daily workflows.

The Chat Feature example from the documentation illustrates this disconnect perfectly. While that model is effective for a startup with a monorepo, it doesn't map well to enterprise environments where backend, frontend, and infrastructure components live in separate repos and are owned by distinct teams.

Our organization is enthusiastic about adopting SDD, but we're struggling to find a pragmatic path forward for these multi-repo, cross-team projects with spec-kit as it stands today.

[github-actions]

This issue has been automatically marked as stale because it has not had any activity for 150 days. It will be closed in 30 days if no further activity occurs.