Problem Statement
What's missing
/speckit.tasks produces a mostly linear checklist today. It's clear, but it never says which tasks are actually independent of each other.
In larger features, plenty of tasks don't depend on anything — docs, an isolated UI change, backend validation, a separate integration point. Right now you have to read the whole list and work out yourself what's safe to split across worktrees, branches, or sessions. That guesswork quietly pushes everything into sequential execution even when it didn't need to be.
Proposed Solution
Idea
Have task generation mark dependencies and parallelizable groups — either as a new command, /speckit.parallel-plan, or as an optional section in /speckit.tasks.
Inline annotations per task:
- [ ] T001 Create database migration for user preferences
- Depends on: none
- Parallel with: T003, T004
- [ ] T002 Add preferences API endpoint
- Depends on: T001
…and/or a wave-based plan:
## Parallel execution plan
### Wave 1 — start immediately, separate worktrees
- T001 Create database migration
- T003 Add frontend settings form
- T004 Update docs
### Wave 2 — after Wave 1
- T002 Add preferences API endpoint
- T005 Add integration tests
Why it helps
- Cuts total implementation time on bigger features
- Lets AI agents work in parallel sessions/worktrees without colliding
- Makes dependencies and merge boundaries explicit
- Nudges toward smaller, independently mergeable slices
- It's just planning info — it doesn't force parallel execution
Rough approach
Update the task-generation prompt to ask for dependencies, independent groups, execution waves, and which tasks are safe in separate worktrees. Keep output backwards-compatible with existing task lists, and don't mark tasks parallel if they touch the same files or hinge on the same unresolved design decision.
On naming, I'd lean toward /speckit.parallel-plan — it reads as an execution plan rather than a task mutation, and avoids spelling ambiguity. Alternatives: /speckit.parallel-tasks, /speckit.task-graph, /speckit.execution-plan.
AI disclosure: I used AI to help shape and draft this issue; the idea and final wording are mine.
Alternatives Considered
No response
Component
Specify CLI (initialization, commands)
AI Agent (if applicable)
None
Use Cases
- Large features where many tasks are actually independent (docs, an isolated UI change, backend validation, tests) and could safely be worked at the same time.
- Driving multiple AI agents — or your own multiple sessions — across separate git worktrees in parallel, without them colliding on the same files.
- Reviewers and contributors who need to see at a glance which changes are independent and where the safe merge boundaries are.
Acceptance Criteria
Additional Context
This is planning information only — it surfaces dependencies and parallelizable groups, it doesn't force parallel execution. Naming preference is /speckit.parallel-plan (reads as an execution plan rather than a task mutation); alternatives considered: /speckit.parallel-tasks, /speckit.task-graph, /speckit.execution-plan.
Problem Statement
What's missing
/speckit.tasksproduces a mostly linear checklist today. It's clear, but it never says which tasks are actually independent of each other.In larger features, plenty of tasks don't depend on anything — docs, an isolated UI change, backend validation, a separate integration point. Right now you have to read the whole list and work out yourself what's safe to split across worktrees, branches, or sessions. That guesswork quietly pushes everything into sequential execution even when it didn't need to be.
Proposed Solution
Idea
Have task generation mark dependencies and parallelizable groups — either as a new command,
/speckit.parallel-plan, or as an optional section in/speckit.tasks.Inline annotations per task:
…and/or a wave-based plan:
Why it helps
Rough approach
Update the task-generation prompt to ask for dependencies, independent groups, execution waves, and which tasks are safe in separate worktrees. Keep output backwards-compatible with existing task lists, and don't mark tasks parallel if they touch the same files or hinge on the same unresolved design decision.
On naming, I'd lean toward
/speckit.parallel-plan— it reads as an execution plan rather than a task mutation, and avoids spelling ambiguity. Alternatives:/speckit.parallel-tasks,/speckit.task-graph,/speckit.execution-plan.AI disclosure: I used AI to help shape and draft this issue; the idea and final wording are mine.
Alternatives Considered
No response
Component
Specify CLI (initialization, commands)
AI Agent (if applicable)
None
Use Cases
Acceptance Criteria
/speckit.taskslistsAdditional Context
This is planning information only — it surfaces dependencies and parallelizable groups, it doesn't force parallel execution. Naming preference is
/speckit.parallel-plan(reads as an execution plan rather than a task mutation); alternatives considered:/speckit.parallel-tasks,/speckit.task-graph,/speckit.execution-plan.