Building Dependency Graphs

Every complex task has an implicit dependency graph — files that depend on other files, functions that call other functions, tests that require implementations to exist first. Making this graph explicit is the first step of expert-level decomposition. A dependency graph maps each deliverable as a node and each "must complete before" relationship as a directed edge. The graph reveals parallelism opportunities: nodes with no incoming edges can run concurrently.

Building the graph starts with listing every artifact the task produces — source files, tests, configuration changes, documentation updates, migration scripts. Then you trace the dependencies: does the test file depend on the implementation? Does the migration need to run before the schema types are generated? Does the documentation reference API signatures that do not exist yet? Each dependency becomes an edge. The resulting DAG (directed acyclic graph) is your execution plan.

# Dependency graph for "Add rate limiting middleware"

┌────────────────┐
│ config.ts      │──────────────────────────────┐
│ (rate limits)  │                              │
└───────┬────────┘                              │
        │                                       │
┌───────▼────────┐     ┌─────────────────┐      │
│ middleware.ts  │────▶│ middleware.test  │      │
│ (implementation│     │ (unit tests)    │      │
└───────┬────────┘     └─────────────────┘      │
        │                                       │
┌───────▼────────┐     ┌─────────────────┐      │
│ app.ts         │────▶│ integration.test│◀─────┘
│ (wire up)      │     │ (e2e tests)     │
└────────────────┘     └─────────────────┘

Parallel opportunities:
  - config.ts has no dependencies → start immediately
  - middleware.ts + app.ts are sequential (app imports middleware)
  - unit tests depend on middleware; integration tests depend on everything

1. List all artifacts Write down every file, test, config change, and documentation update the task requires. This is your node set.
2. Trace dependencies For each artifact, ask: "What must exist before I can create this?" Draw a directed edge from the prerequisite to the dependent.
3. Identify the critical path The longest chain of sequential dependencies is your critical path. Everything not on this path is a parallelism opportunity.