Analyze task dependencies for parallel execution

Analyze task dependencies for parallel execution

Instructions

• Read the story markdown file using the Read tool.
• Parse all tasks from the "## Tasks" section.
• Analyze each task to identify dependencies:
• File dependencies: Tasks that update/create files that other tasks depend on
• Logical dependencies: Tasks that must complete before others
• Same-file conflicts: Tasks that modify the same file cannot run in parallel
• Parallel agents: Multiple agents of the same type can work in parallel - focus only on technical dependencies
• QA independence: Test scenario planning tasks depend only on story and can start immediately in parallel with implementation tasks
• Group tasks into parallel execution batches using these formats:
• Sequential tasks X-Y: for tasks that need to be implemented sequentially with no prerequisites
• Sequential tasks X-Y after task Z completes: for a sequential chain that depends on one prerequisite task
• Sequential tasks X-Y after tasks A-B complete: for a sequential chain that depends on multiple prerequisite tasks
• Parallel tasks X-Y: for tasks with no dependencies that can start immediately
• Parallel after task X completes: for parallel tasks depending on a single prerequisite task
• Parallel after tasks X-Y complete: for parallel tasks depending on multiple prerequisite tasks
• Number tasks sequentially (1, 2, 3...) across all groups
• Keep the original task descriptions with their agent assignments and file paths

Parallelism Strategy

When analyzing dependencies, prefer parallelism by default:

• Only create sequential dependencies when there's a true code-level dependency (file imports, component usage)
• Assume infrastructure and config will be ready at runtime
• Group tasks by file conflicts, not by logical workflow order
• Maximize the number of tasks that can start immediately
• Remember: multiple agents can work simultaneously on different files

Output Format

Present the analysis as a proposed replacement for the "## Tasks" section. Do NOT edit the story file automatically.

Ask the user: "Would you like me to update the story file with these grouped tasks?"

Only edit the story file if the user confirms.

Proposed format:

## Tasks

**Sequential tasks 1-3:**

1. Use backend-developer subagent to [original task description]
2. Use backend-developer subagent to [original task description]
3. Use backend-developer subagent to [original task description]

**Parallel tasks 4-5:**

4. Use backend-developer subagent to [original task description]
5. Use qa-tester subagent to [original task description]

**Parallel after task 4 completes:**

6. Use frontend-developer subagent to [original task description]
7. Use frontend-developer subagent to [original task description]

**Sequential tasks 8-9 after tasks 6-7 complete:**

8. Use backend-developer subagent to [original task description]
9. Use frontend-developer subagent to [original task description]

Dependency Detection Rules

Hard Dependencies (must wait):

• Tasks that modify the same file cannot run in parallel (will cause merge conflicts)
• File creation must complete before files that import/reference them
• Store/state creation must complete before components that consume the store
• Component creation must complete before parent components that render them
• Server actions must complete before frontend components that call them

Soft Dependencies (can assume will exist at runtime):

• Config values and environment variables can be assumed to exist at runtime
• Database schemas/tables can be assumed to exist if mentioned in requirements
• API endpoints can be assumed to exist if defined in requirements
• Infrastructure (S3 buckets, etc.) can be assumed to exist if initialized separately

Independent Tasks:

• Test scenario planning depends only on story, not implementation
• Infrastructure setup (S3 initialization, DB migrations) can run in parallel with code
• Config changes can run in parallel with code that uses those configs

Examples

Config Dependencies

❌ Over-sequential (incorrect approach):

Sequential tasks 1-3:
1. Add config value `auth.userId`
2. Add config value `aws.s3.bucket`
3. Implement server action that uses both config values

This creates unnecessary waiting - task 3 can be written assuming configs will exist.

✅ Properly parallel (correct approach):

Sequential tasks 1-2:
1. Add config value `auth.userId`
2. Add config value `aws.s3.bucket`

Parallel tasks 3-4:
3. Implement server action that uses both config values
4. Initialize S3 bucket

Tasks 1-2 are sequential because they modify the same file. Tasks 3-4 can run in parallel with 1-2 because they assume runtime values will exist.

Sequential Group Merging

❌ Split sequential groups (incorrect approach):

Sequential tasks 1-3:
1. Create user model
2. Create user service
3. Create user controller

Sequential tasks 4-5 after task 3 completes:
4. Add authentication middleware
5. Add protected routes

The second group's only prerequisite is the last task of the first group — this is just one sequential chain.

✅ Merged sequential group (correct approach):

Sequential tasks 1-5:
1. Create user model
2. Create user service
3. Create user controller
4. Add authentication middleware
5. Add protected routes

If a sequential group's only prerequisite is the last task of a prior sequential group, merge them into one group.

Completion

This skill is a standalone analysis task. After updating the story file (or if the user declines):

• Report that the task dependency analysis is complete.
• Do NOT proceed to implementation planning, codebase exploration, or any other workflow phases.
• STOP and wait for the user's next instruction.

Example Inputs

• Analyze task dependencies in @path/to/story.md
• Show parallel execution plan for @path/to/story.md
• What tasks can run in parallel in @path/to/story.md
• Group tasks by dependencies in @path/to/story.md