Analyze task dependencies for parallel execution git:20260910.adf7c27A

Immutable. This exact content is served forever at /api/v1/blob/01b65879ed9250f4.

---
name: Analyze task dependencies for parallel execution
description: Parse story markdown to identify task dependencies and parallel execution opportunities.
user-invocable: false
---

# 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. Every heading states its prerequisites, so groups reading "no prerequisites" all start at the same time no matter what order they appear in:
  - `**Sequential tasks X-Y, no prerequisites:**` for a sequential chain that can start immediately
  - `**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, no prerequisites:**` for parallel tasks 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:

```markdown
## Tasks

**Sequential tasks 1-3, no prerequisites:**

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, no prerequisites:**

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, no prerequisites:
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, no prerequisites:
1. Add config value `auth.userId`
2. Add config value `aws.s3.bucket`

Parallel tasks 3-4, no prerequisites:
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 have no prerequisites because they assume runtime values will exist.

### Sequential Group Merging

❌ **Split sequential groups (incorrect approach):**
```
Sequential tasks 1-3, no prerequisites:
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, no prerequisites:
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