Dependency Mapping

Dependency Mapping

Techniques for identifying task dependencies, detecting blocking relationships, and optimizing execution order for maximum parallelization.

Quick Start

Analyze dependencies:

Map the dependencies between these tasks and identify what can run in parallel

Find critical path:

What is the critical path through this task list? Which tasks block the most work?

Detect issues:

Check these tasks for circular dependencies or unnecessary blocking relationships

Dependency Types

Direct Dependencies

Most common: Finish-to-Start (FS) - default assumption for task planning.

Dependency Categories

Dependency Detection

Code-Level Dependencies

Identify dependencies based on what code changes require:

## File Dependency Analysis

### Schema Changes (Foundation Layer)
- prisma/schema.prisma modifications
- Must complete before: Any code using affected models

### Type Definitions
- types/*.ts, interfaces/*.ts
- Must complete before: Code importing these types

### Shared Utilities
- lib/*.ts, utils/*.ts
- Must complete before: Consumers of these utilities

### API Endpoints
- app/api/**/*.ts
- Must complete before: Frontend calling these APIs

### UI Components
- components/*.tsx
- Can often parallel with API work (mock data)

Dependency Questions

For each task, ask:

1. Inputs: What files/data does this task need that don't exist yet?
2. Outputs: What does this task produce that others need?
3. Side Effects: Does this task change shared state (DB, cache, files)?
4. Contracts: Does this task define interfaces others will implement?

Dependency Matrix

Create a matrix to visualize all relationships:

         | T1 | T2 | T3 | T4 | T5 | T6 |
---------|----|----|----|----|----|----|
Task 1   |    |    |    |    |    |    |
Task 2   | X  |    |    |    |    |    |  (T2 depends on T1)
Task 3   |    |    |    |    |    |    |
Task 4   | X  | X  |    |    |    |    |  (T4 depends on T1, T2)
Task 5   |    |    | X  |    |    |    |  (T5 depends on T3)
Task 6   |    |    |    | X  | X  |    |  (T6 depends on T4, T5)

Visualization Formats

Text-Based DAG (Directed Acyclic Graph)

[T1: Schema] ─────────┬─────────────────────────┐
                      │                         │
                      v                         v
             [T2: API Routes] ────────> [T4: Integration]
                      │                         │
                      v                         │
             [T3: Auth Middleware]              │
                      │                         │
                      └─────────────────────────┘
                                                │
                                                v
                                        [T5: E2E Tests]

Gantt-Style Parallel Groups

Group 1:  ████████ T1: Schema
          ████████ T3: UI Components

Group 2:       ████████ T2: API Routes (after T1)
               ████████ T4: Auth (after T1)

Group 3:            ████████ T5: Integration (after T2, T4)

Group 4:                 ████████ T6: Tests (after T5)

Mermaid Diagram Syntax

graph TD
    T1[Schema Design] --> T2[API Routes]
    T1 --> T4[Auth Middleware]
    T2 --> T5[Frontend Integration]
    T4 --> T5
    T3[UI Components] --> T5
    T5 --> T6[E2E Tests]

Parallelization Analysis

Identifying Parallel Opportunities

Tasks CAN run in parallel when:

• No shared file modifications
• No producer-consumer relationship
• Different architectural layers
• Independent features

Tasks MUST run sequentially when:

• One creates what another reads
• Database migrations involved
• Shared state modifications
• Output validation required

Parallel Execution Groups

Organize tasks into execution groups:

## Parallel Execution Plan

### Group 1: Foundation (Start Immediately)
No dependencies - can all start at once
- T1: Database schema design
- T3: UI component scaffolding
- T7: Documentation structure

### Group 2: Core Services (After Group 1)
Depends on foundation work
- T2: API route implementation (needs T1)
- T4: Authentication middleware (needs T1)

### Group 3: Integration (After Group 2)
Depends on core services
- T5: Frontend-backend integration (needs T2, T4)
- T6: Cache layer implementation (needs T2)

### Group 4: Validation (After Group 3)
Depends on integration
- T8: End-to-end tests (needs T5)
- T9: Performance tests (needs T5, T6)

### Group 5: Finalization (After Group 4)
Depends on validation
- T10: Documentation updates (needs T8, T9)

Maximum Parallelization Algorithm

1. List all tasks with their dependencies
2. Find tasks with NO dependencies -> Group 1
3. Mark Group 1 as "completed"
4. Find tasks whose dependencies are all "completed" -> Group 2
5. Mark Group 2 as "completed"
6. Repeat until all tasks assigned to groups

Critical Path Analysis

Finding the Critical Path

The critical path is the longest sequence of dependent tasks.

## Critical Path Example

All Paths:
- Path A: T1 -> T2 -> T5 -> T8 (4 tasks)
- Path B: T1 -> T4 -> T5 -> T8 (4 tasks)
- Path C: T3 -> T5 -> T8 (3 tasks)
- Path D: T1 -> T6 -> T9 (3 tasks)

Critical Path: A or B (4 tasks, tied)

Implications:
- Any delay in T1, T2/T4, T5, or T8 delays the entire project
- T3, T6, T9 have "slack" - can be delayed without project delay
- Focus quality efforts on critical path tasks

Critical Path Optimization

Dependency Problems

Circular Dependencies

Detection:

T1 depends on T4
T4 depends on T2
T2 depends on T1
-> CIRCULAR: T1 -> T4 -> T2 -> T1

Resolution strategies:

1. Interface extraction: Define shared interface, implement independently
2. Merge tasks: Combine circular tasks into single task
3. Stub creation: Create stub/mock to break dependency
4. Architectural refactor: Redesign to eliminate cycle

Hidden Dependencies

Common hidden dependencies:

• Environment variables needed by multiple tasks
• Shared configuration files
• Database state assumptions
• External service availability
• Build artifacts

Detection questions:

• What must be true in the environment for this task to work?
• What database state does this task assume?
• What external services must be available?

Over-Constraining

Signs of over-constraining:

• Sequential tasks that could be parallel
• Dependencies based on "preference" not necessity
• Same agent assigned to too many sequential tasks

Questions to challenge dependencies:

• Is this dependency technical or organizational?
• Could we use mocks/stubs to break this dependency?
• Is the dependency on the whole task or just part of it?

Dependency Documentation

Per-Task Dependency Block

## Task: Implement User API

### Dependencies

**Requires (Blocking):**
- T1: User schema must be defined
- T3: Authentication middleware must exist

**Requires (Non-Blocking):**
- API documentation template (nice to have)

**Produces (Blocks):**
- T5: Frontend integration needs these endpoints
- T7: API tests need endpoints to test

**Shared Resources:**
- Database connection pool
- Error handling utilities

Project Dependency Summary

## Dependency Summary

### Bottleneck Tasks
Tasks that block the most downstream work:
1. T1: Schema Design (blocks 5 tasks)
2. T4: Auth Middleware (blocks 4 tasks)
3. T2: API Routes (blocks 3 tasks)

### Longest Chain
T1 -> T4 -> T2 -> T5 -> T8 -> T10 (6 tasks)

### Parallel Capacity
- Maximum tasks executable in parallel: 4
- Average parallelization: 2.3 tasks per group

### External Dependencies
- Google OAuth credentials (T4)
- Stripe API keys (T6)
- Production database access (T9)

Integration with Workflow Planner

This skill provides the workflow-planner agent with:

1. Dependency detection methods for analyzing task relationships
2. Parallel group generation algorithm for execution planning
3. Critical path identification for risk assessment
4. Dependency problem detection for plan validation

The workflow-planner uses these techniques when generating:

• Task Breakdown table (Dependencies column)
• Parallel Execution Groups section
• Complexity Assessment (dependency graph rating)

Example: Full Dependency Analysis

Task List:

1. Create User model schema
2. Create Post model schema
3. Implement user registration API
4. Implement user login API
5. Implement create post API
6. Build registration form UI
7. Build login form UI
8. Build post creation UI
9. Integrate registration flow
10. Integrate login flow
11. Integrate post creation flow
12. Write authentication tests
13. Write post API tests
14. E2E test full user flow

Dependency Matrix:

Parallel Groups:

Group 1: T1, T6, T7, T8 (foundations)
Group 2: T2, T3, T4 (after T1)
Group 3: T5, T9, T10, T12 (after dependencies)
Group 4: T11, T13 (after T5, T10)
Group 5: T14 (final validation)

Critical Path: T1 -> T2 -> T5 -> T11 -> T14 (5 groups)

Bottleneck: T1 (blocks 12 downstream tasks directly or indirectly)