Deps

/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.

What this is not

• 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

/flow-next:deps

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.

Tips

• 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:

• Parallelize - phase groupings tell you which specs (and which disjoint tasks) are safe to run side by side.
• 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:

/flow-next:work <spec-id>