Skip to content

[Feature]: Add parallelizable task planning to Spec Kit workflows #3068

@hajrashidimad

Description

@hajrashidimad

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

  1. 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.
  2. Driving multiple AI agents — or your own multiple sessions — across separate git worktrees in parallel, without them colliding on the same files.
  3. Reviewers and contributors who need to see at a glance which changes are independent and where the safe merge boundaries are.

Acceptance Criteria

  • Task generation can annotate each task with its dependencies
  • Independent tasks are grouped into parallel execution waves
  • Output stays backwards-compatible with existing /speckit.tasks lists
  • Tasks that touch the same files or share an unresolved design decision are never marked parallel
  • Documentation is updated
  • Works across all supported agents

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.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions