# Deps

Source: https://flow-next.dev/skills/deps/

Show spec dependency graph, execution order, and parallelizable phases.

`/flow-next:deps` visualizes how specs in `.flow/` depend on each other and what order they can run in.

It answers questions like:

* What’s blocking what?
* Which specs can I run in parallel?
* What’s the critical path?
* Why does this spec think it’s blocked?

## What you see

The skill walks every spec in `.flow/specs/`, reads its `depends_on_epics` field, and produces a three-part view:

| Section          | Content                                                                                                      |
| ---------------- | ------------------------------------------------------------------------------------------------------------ |
| Status per spec  | Each spec marked `READY` or `BLOCKED` with the blocking specs listed by ID.                                  |
| Execution phases | Groups of specs that can run in parallel. Phase 1 has no dependencies; phase 2 depends only on phase 1; etc. |
| Critical path    | The longest chain of dependencies, end to end.                                                               |

A `done` spec is treated as a satisfied dependency, so completing one spec can unblock several at once.

## When to use it

* Planning the next week of work and deciding what to start first.
* After a long break, to see where things stand without re-reading every spec.
* Before splitting work across a team - phase groupings show what is safe to parallelize.
* Diagnosing why a spec is still blocked when its prerequisites look done.

## Reading the output

`READY` does not mean prioritized. It means the spec’s prerequisites are satisfied and a worker can pick it up. Prioritization is your call - `deps` shows the graph, not the value of each node.

## Where it stops

* Not a scheduler. The graph informs human decisions; it does not assign work.
* Not aware of branch state. A spec marked `READY` may still have a feature branch with uncommitted changes; check before starting.

## Worked example

```plaintext
/flow-next:deps
```

```text
READY    fn-12-export-json-flag   (no blockers)
READY    fn-13-audit-log          (no blockers)
BLOCKED  fn-14-rate-limits        by fn-12-export-json-flag


Phase 1 (parallel-safe): fn-12-export-json-flag, fn-13-audit-log
Phase 2:                 fn-14-rate-limits


Critical path: fn-12-export-json-flag -> fn-14-rate-limits
```

Phase groupings are the parallelization map: everything in one phase can run at the same time.

* A `done` spec counts as a satisfied dependency - closing one spec can flip several to READY at once.
* READY means unblocked, not prioritized; the graph informs the decision, it does not make it.
* Check branch state before starting a READY spec - the graph does not know about uncommitted work on a feature branch.

## Dynamic usage

Recipes that compose with deps in the [cookbook](https://flow-next.dev/guides/cookbook/):

* [Parallelize](https://flow-next.dev/guides/cookbook/#parallelize) - phase groupings tell you which specs (and which disjoint tasks) are safe to run side by side.
* [Team patterns](https://flow-next.dev/guides/cookbook/#team-patterns) - run deps before splitting a milestone across teammates.

## Next step

Pick a `READY` spec and either review it or hand it to the work loop:

```bash
/flow-next:work <spec-id>
```