The problem
Spec-Driven Development works great when you're focused on one feature at a time. In practice, though, teams (and even solo developers) end up with multiple features at different stages:
specs/001-memory-engine/ → spec ✓ plan ✓ tasks 44/45 implemented ✓
specs/002-voice-refactor/ → spec ✓ plan ✓ tasks 0/18 not started
specs/003-discord-threads/ → spec ✓ plan ✗ — —
specs/004-scheduler-v2/ → spec ✓ plan ✓ tasks 12/30 in progress
specs/005-multi-backend/ → spec ✓ plan ✗ — —
Right now, there's no built-in way to answer simple questions like:
- Where are things at? Which features have specs only? Which have plans? Which are partially implemented?
- What should I work on next? Across all features, which tasks are ready and which are blocked?
- Are there conflicts? Do tasks from different features touch the same files?
Each /speckit.* command operates within a single feature directory. There's nothing that gives you the big picture across all of them.
What exists today
- The community
status extension shows progress for the current feature only (single-feature view).
/speckit.taskstoissues pushes tasks to GitHub Issues, but once they're issues, the spec→plan→task lineage is lost — they're just flat items in a backlog.- The
spec-driven.md document describes the philosophy beautifully but doesn't address multi-feature coordination.
What's missing
Three things, in order of complexity:
1. Multi-feature lifecycle view (simple)
A way to see all features and where each one stands in the SDD lifecycle:
Feature Spec Plan Tasks Impl Phase
001-memory-engine ✓ ✓ 44/45 ✓ Done
002-voice-refactor ✓ ✓ 0/18 — Ready to implement
003-discord-threads ✓ — — — Needs planning
004-scheduler-v2 ✓ ✓ 12/30 ◐ In progress
005-multi-backend ✓ — — — Needs planning
This requires no new metadata — it can be derived entirely from what files exist (spec.md, plan.md, tasks.md) and the checkbox counts in tasks.md.
2. Cross-feature task selection (medium)
When you're ready to implement, you might want to pick tasks from different features in a single session. For example: "I'm going to work on the database layer today — show me all DB-related tasks across all features."
Today, each tasks.md is isolated. There's no way to query or filter across them.
3. Conflict detection (advanced)
Two features might have tasks that modify the same files. Knowing this upfront — before you start implementing — helps you decide the right order and avoid merge conflicts.
Why this matters for SDD
The spec-driven.md document says:
"This is supportive of a team process, where team-reviewed specifications are expressed and versioned, created in branches, and merged."
If SDD supports team processes with parallel branches, it needs a way to keep track of what's happening across those branches. Without it, the more features you spec out, the harder it becomes to know what's done, what's next, and what conflicts.
Possible approaches
I see a few ways this could work. Not proposing a specific solution — just opening the conversation.
A. Extension — A community extension (like status but multi-feature) that scans specs/*/ and aggregates state. Lowest friction, no core changes.
B. Core concept — A /speckit.status command in core that understands the SDD lifecycle phases. This would make the lifecycle a first-class concept rather than something derived from file existence.
C. Workflow metadata — A lightweight specs/status.json (or similar) maintained by the existing commands. Each /speckit.* command updates it as a side effect (e.g., /speckit.plan marks the feature as "planned"). Other tools can then read it.
Context
I ran into this while using Spec Kit on a real project. I had one feature not fully implemented and wanted to start planning a second one, but realized I had no way to see the overall state of features in I would had more than one. The problem will only grow as more features accumulate.
Happy to contribute to whichever approach makes sense for the project.
The problem
Spec-Driven Development works great when you're focused on one feature at a time. In practice, though, teams (and even solo developers) end up with multiple features at different stages:
Right now, there's no built-in way to answer simple questions like:
Each
/speckit.*command operates within a single feature directory. There's nothing that gives you the big picture across all of them.What exists today
statusextension shows progress for the current feature only (single-feature view)./speckit.taskstoissuespushes tasks to GitHub Issues, but once they're issues, the spec→plan→task lineage is lost — they're just flat items in a backlog.spec-driven.mddocument describes the philosophy beautifully but doesn't address multi-feature coordination.What's missing
Three things, in order of complexity:
1. Multi-feature lifecycle view (simple)
A way to see all features and where each one stands in the SDD lifecycle:
This requires no new metadata — it can be derived entirely from what files exist (
spec.md,plan.md,tasks.md) and the checkbox counts intasks.md.2. Cross-feature task selection (medium)
When you're ready to implement, you might want to pick tasks from different features in a single session. For example: "I'm going to work on the database layer today — show me all DB-related tasks across all features."
Today, each
tasks.mdis isolated. There's no way to query or filter across them.3. Conflict detection (advanced)
Two features might have tasks that modify the same files. Knowing this upfront — before you start implementing — helps you decide the right order and avoid merge conflicts.
Why this matters for SDD
The
spec-driven.mddocument says:If SDD supports team processes with parallel branches, it needs a way to keep track of what's happening across those branches. Without it, the more features you spec out, the harder it becomes to know what's done, what's next, and what conflicts.
Possible approaches
I see a few ways this could work. Not proposing a specific solution — just opening the conversation.
A. Extension — A community extension (like
statusbut multi-feature) that scansspecs/*/and aggregates state. Lowest friction, no core changes.B. Core concept — A
/speckit.statuscommand in core that understands the SDD lifecycle phases. This would make the lifecycle a first-class concept rather than something derived from file existence.C. Workflow metadata — A lightweight
specs/status.json(or similar) maintained by the existing commands. Each/speckit.*command updates it as a side effect (e.g.,/speckit.planmarks the feature as "planned"). Other tools can then read it.Context
I ran into this while using Spec Kit on a real project. I had one feature not fully implemented and wanted to start planning a second one, but realized I had no way to see the overall state of features in I would had more than one. The problem will only grow as more features accumulate.
Happy to contribute to whichever approach makes sense for the project.