Back to Beads

bd dep

website/versioned_docs/version-1.0.0/cli-reference/dep.md

1.0.45.8 KB
Original Source
<!-- AUTO-GENERATED: do not edit manually -->

Generated from bd help --doc dep

bd dep

Manage dependencies between issues.

When called with an issue ID and --blocks flag, creates a blocking dependency: bd dep <blocker-id> --blocks <blocked-id>

This is equivalent to: bd dep add <blocked-id> <blocker-id>

Examples: bd dep bd-xyz --blocks bd-abc # bd-xyz blocks bd-abc bd dep add bd-abc bd-xyz # Same as above (bd-abc depends on bd-xyz)

bd dep [issue-id] [flags]

Flags:

  -b, --blocks string    Issue ID that this issue blocks (shorthand for: bd dep add <blocked> <blocker>)
      --no-cycle-check   Skip cycle detection after adding (use for bulk wiring — run 'bd dep cycles' to verify afterwards)

bd dep add

Add a dependency between two issues.

The depends-on-id can be provided as:

  • A positional argument: bd dep add issue-123 issue-456
  • A flag: bd dep add issue-123 --blocked-by issue-456
  • A flag: bd dep add issue-123 --depends-on issue-456

The --blocked-by and --depends-on flags are aliases and both mean "issue-123 depends on (is blocked by) the specified issue."

The depends-on-id can be:

  • A local issue ID (e.g., bd-xyz)
  • An external reference: external:<project>:<capability>

For bulk wiring, pass newline-delimited JSON with --file. Each line must be an object with "from" and "to" fields, and may include "type". The aliases "issue_id" and "depends_on_id" are also accepted. Use --file - to read stdin.

External references are stored as-is and resolved at query time using the external_projects config. They block the issue until the capability is "shipped" in the target project.

Examples: bd dep add bd-42 bd-41 # Positional args bd dep add bd-42 --blocked-by bd-41 # Flag syntax (same effect) bd dep add bd-42 --depends-on bd-41 # Alias (same effect) bd dep add gt-xyz external:beads:mol-run-assignee # Cross-project dependency bd dep add bd-42 bd-41 --no-cycle-check # Skip cycle check (bulk wiring) bd dep add --file deps.jsonl # Bulk JSONL: {"from":"bd-42","to":"bd-41"}

bd dep add [issue-id] [depends-on-id] [flags]

Flags:

      --blocked-by string   Issue ID that blocks the first issue (alternative to positional arg)
      --depends-on string   Issue ID that the first issue depends on (alias for --blocked-by)
      --file string         Read dependency edges from JSONL file, or '-' for stdin
      --no-cycle-check      Skip cycle detection after adding (use for bulk wiring — run 'bd dep cycles' to verify afterwards)
  -t, --type string         Dependency type (blocks|tracks|related|parent-child|discovered-from|until|caused-by|validates|relates-to|supersedes) (default "blocks")

bd dep cycles

Detect dependency cycles

bd dep cycles

bd dep list

List dependencies or dependents of one or more issues with optional type filtering.

By default shows dependencies (what issues depend on). Use --direction to control:

  • down: Show dependencies (what this issue depends on) - default
  • up: Show dependents (what depends on this issue)

Multiple IDs can be provided for batch dep listing. With --json, the output is a flat array of dependency records across all requested issues.

Use --type to filter by dependency type (e.g., tracks, blocks, parent-child).

Examples: bd dep list gt-abc # Show what gt-abc depends on bd dep list gt-abc gt-def # Batch: deps for both issues bd dep list gt-abc --direction=up # Show what depends on gt-abc bd dep list gt-abc --direction=up -t tracks # Show what tracks gt-abc (convoy tracking)

bd dep list [issue-id...] [flags]

Flags:

      --direction string   Direction: 'down' (dependencies), 'up' (dependents) (default "down")
  -t, --type string        Filter by dependency type (e.g., tracks, blocks, parent-child)

bd dep relate

Create a loose 'see also' relationship between two issues.

The relates_to link is bidirectional - both issues will reference each other. This enables knowledge graph connections without blocking or hierarchy.

Examples: bd relate bd-abc bd-xyz # Link two related issues bd relate bd-123 bd-456 # Create see-also connection

bd dep relate <id1> <id2>

bd dep remove

Remove a dependency

bd dep remove [issue-id] [depends-on-id]

Aliases: rm

bd dep tree

Show dependency tree rooted at the given issue.

By default, shows dependencies (what blocks this issue). Use --direction to control:

  • down: Show dependencies (what blocks this issue) - default
  • up: Show dependents (what this issue blocks)
  • both: Show full graph in both directions

Examples: bd dep tree gt-0iqq # Show what blocks gt-0iqq bd dep tree gt-0iqq --direction=up # Show what gt-0iqq blocks bd dep tree gt-0iqq --status=open # Only show open issues bd dep tree gt-0iqq --depth=3 # Limit to 3 levels deep

bd dep tree [issue-id] [flags]

Flags:

      --direction string   Tree direction: 'down' (dependencies), 'up' (dependents), or 'both'
      --format string      Output format: 'mermaid' for Mermaid.js flowchart
  -d, --max-depth int      Maximum tree depth to display (safety limit) (default 50)
      --reverse            Show dependent tree (deprecated: use --direction=up)
      --show-all-paths     Show all paths to nodes (no deduplication for diamond dependencies)
      --status string      Filter to only show issues with this status (open, in_progress, blocked, deferred, closed)

bd dep unrelate

Remove a relates_to relationship between two issues.

Removes the link in both directions.

Example: bd unrelate bd-abc bd-xyz

bd dep unrelate <id1> <id2>