Skip to main content

Usage

Description

Manage dependencies between issues. Dependencies define blocking relationships, parent-child hierarchies, and other issue connections.

Subcommands

add

Add a dependency between two issues.
string
required
The dependent issue (the one that is blocked)
string
required
The dependency (the blocker). Can be:
  • Local issue ID (e.g., bd-xyz)
  • External reference: external:<project>:<capability> Can also be specified via --blocked-by or --depends-on flag.
string
default:"blocks"
Dependency type: blocks, tracks, related, parent-child, discovered-from, until, caused-by, validates, relates-to, supersedes
string
Alternative to positional arg (same as depends-on-id)
string
Alias for --blocked-by

remove (rm)

Remove a dependency.

list

List dependencies or dependents of an issue.
string
default:"down"
Direction: down (dependencies), up (dependents)
string
Filter by dependency type

tree

Show dependency tree.
string
default:"down"
Direction: down (dependencies), up (dependents), both (full graph)
integer
default:"50"
Maximum tree depth to display
string
Filter to only show issues with this status
string
Output format: mermaid for Mermaid.js flowchart
boolean
Show all paths to nodes (no deduplication for diamond dependencies)

cycles

Detect dependency cycles.

Examples

Add Dependencies

External Dependencies

List Dependencies

Dependency Tree

Cycle Detection

JSON Output

dep add

dep list

dep tree

dep cycles

Dependency Types

Blocking relationship: Issue A depends on (is blocked by) Issue B. Issue A cannot be closed until B is closed.Default type when not specified.
Hierarchical relationship: Used for epics and subtasks. Child issues inherit the parent’s completion dependency.Created automatically with --parent flag in bd create.
Discovery tracking: Links newly discovered issues to their source investigation.Example: Bug found during feature development.
Tracking relationship: Issue A tracks progress of Issue B (used in convoy patterns).
Alias for related
Temporal dependency: Issue A depends on B until a condition is met.
Causation tracking: Issue A was caused by Issue B (e.g., bug caused by feature).
Validation relationship: Issue A validates Issue B (e.g., test validates feature).
Replacement relationship: Issue A replaces Issue B.

External References

External references allow cross-project dependencies:

Format

Examples

Resolution

External refs are resolved at query time using routes.jsonl configuration:
  1. Check if capability is “shipped” in target project
  2. Block if not shipped
  3. Unblock when shipped
External refs are stored as-is in the database. The external_projects config maps project names to their database locations.

Tree Visualization

Terminal Output

Mermaid Diagram

Cycle Detection

Cycles hide issues from ready work and cause confusion:
Output:
Cycles prevent issues from appearing in bd ready even if they should be unblocked. Fix by removing one dependency in the cycle.

Anti-Patterns

Child→Parent Dependency

Children inherit parent completion dependency via hierarchy. Explicit dependency creates:
  • Child can’t start (parent open)
  • Parent can’t close (children not done)
  • Deadlock!

Best Practices

For Agents

  1. Use discovered-from to link bugs found during work
  2. Check cycles after adding dependencies
  3. Use external refs for cross-project dependencies
  4. Verify dependencies exist before adding

For Humans

  1. Keep dependency types semantic (blocks for blocking, tracks for tracking)
  2. Use parent-child for true hierarchies
  3. Avoid deep trees (>5 levels) - flatten if possible
  4. Document external refs in issue description

Dependency Hygiene