Analyze task dependencies for parallel execution
npx machina-cli add skill Intai/story-flow/analyze-task-dependencies --openclawAnalyze 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.
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
Source
git clone https://github.com/Intai/story-flow/blob/main/plugins/story-flow/skills/analyze-task-dependencies/SKILL.mdView on GitHub Overview
Parses story markdown to extract tasks, detects file and logical dependencies, and flags parallelization opportunities. This helps teams maximize concurrent work while avoiding conflicts and merge issues.
How This Skill Works
The tool reads the story's Tasks section, extracts each task with its agent and file path, and classifies dependencies into file dependencies, logical dependencies, and same-file conflicts. It then groups tasks into parallelizable batches and sequential chains, prioritizing parallelism unless a true code-level dependency exists.
When to Use It
- When multiple tasks modify different files and can run without conflicts.
- When you want to maximize throughput by running tasks in parallel across agents.
- When there are file-based dependencies that constrain parallel execution.
- When QA/test planning tasks depend only on the story and can run alongside implementation.
- When organizing tasks into sequential/parallel groups based on real code-level dependencies.
Quick Start
- Step 1: Read the story markdown and locate the ## Tasks section.
- Step 2: Identify file, logical, and same-file dependencies among tasks.
- Step 3: Group into parallel and sequential batches using the formats described and keep original task details.
Best Practices
- Map every task to its target files to detect potential conflicts early.
- Prefer parallel grouping unless a hard code-level dependency exists.
- Preserve original task descriptions, agent assignments, and file paths for traceability.
- Validate grouped plans against imports, stores, and API interactions.
- Iterate with stakeholders and keep the analysis reversible in the story file.
Example Use Cases
- Analyzing an API integration where one task generates a schema used by another task.
- Distributing UI tasks across components that touch different CSS/JS files.
- QA planning tasks that can run in parallel with implementation tasks.
- Refactoring tasks that affect separate modules and can proceed concurrently.
- Story-driven task planning for a backend service with multiple independent endpoints.