Dependencies

Dependencies are explicit. A task becomes ready only when all required tasks are done. Most users see this through /flow-next:work; flowctl exposes the lower-level state.

/flow-next:work fn-1

CLI plumbing:

flowctl ready --spec fn-1
flowctl next --json

Spec-level dependencies are supported too when one spec must land before another:

flowctl spec add-dep fn-2 fn-1
flowctl spec rm-dep fn-2 fn-1

Use dependencies to model real ordering constraints. Do not encode preference or ownership as fake dependencies.

Dependency types

Type	Use for	Example
Hard technical dependency	One task cannot compile or test before another	Data model before API route
Contract dependency	One task needs a stable interface from another	Backend response shape before UI
Review dependency	A risky decision needs approval before work continues	Security model before auth implementation
Spec dependency	A whole spec needs another spec merged	Config migration before new command behavior

Anti-patterns

• “Alice owns this first” as a dependency. Use assignment, not dependency.
• “This seems easier first.” Use priority, not dependency.
• “The agent might get confused.” Split or clarify the spec.
• “Everything depends on setup.” If every task depends on one setup task, check whether the setup task is too broad.

Ready work

A healthy graph has a small number of ready tasks, not every task ready and not every task blocked. Ready tasks should be independent enough to assign to separate workers or worktrees.

flowchart TB
  A["setup contract"] --> B["API implementation"]
  A --> C["UI integration"]
  A --> D["docs and examples"]
  B --> E["completion review"]
  C --> E
  D --> E

This shape lets API, UI, and docs move in parallel once the contract is stable.