Skip to main content
Beads includes a full dependency system for ordering work and a gate system for bridging external conditions (PR merges, CI runs, timers) into the dependency graph.

Adding Dependencies

When issue-1 is open, issue-2 won’t appear in bd ready. Once issue-1 is closed, issue-2 unblocks automatically.

Removing Dependencies

Dependency Types

Dependencies have a type that determines whether they block work. Blocking types (affect bd ready): Non-blocking types (graph annotations only): Specify with --type:

Finding Ready Work

bd ready shows issues with no open blocking dependencies:
Output:
An issue is ready when ALL of its blocking dependencies are closed.

Viewing Blocked Issues

Shows every blocked issue and what blocks it. Use after closing an issue to see what just unblocked.

Visualizing Dependencies

Dependency Tree

Dependency Graph

The graph organizes issues into layers:
  • Layer 0: No dependencies (can start immediately)
  • Layer 1: Depends on layer 0
  • Higher layers: Depend on lower layers
  • Same layer: Can run in parallel

Dependency List

Cycle Detection

Beads also rejects cycles at write time — bd dep add checks for cycles before committing.

Cross-Repo Dependencies

Dependencies can reference issues in other beads rigs:
External dependencies always block. When the remote issue closes, bd ready reflects the change (checked at query time).

Gates

Gates are special issues that block dependent work until an external condition is met. They bridge the gap between beads (which tracks work) and external systems (which track code, CI, or time).

The Problem Gates Solve

When you use Dolt (server or embedded), issue state is decoupled from code state. Closing a beads issue means “work is done” but the code may still be on a feature branch, waiting for PR review:
With file-based storage (JSONL), issue updates land atomically with code in the same commit. With Dolt, they don’t. Gates solve this by making the dependency wait for the external condition — not just the beads issue status.

Gate Types

Creating Gates

Wiring Gates into Dependencies

A gate is an issue. Wire it into the dependency graph like any other:

Checking Gates

bd gate check evaluates all open gates and closes resolved ones:
Escalation marks gates whose conditions failed (e.g., PR closed without merge, CI run failed) so they surface for attention.

Listing and Inspecting Gates

Manual Resolution

For human gates or overrides:

Discovering CI Run IDs

When you create a gh:run gate before the run starts, bd gate discover matches gates to GitHub Actions runs using heuristics (commit SHA, branch, timing):

Automating Gate Checks

Run bd gate check periodically to auto-close resolved gates:
  • CI step: Add to your GitHub Actions workflow
  • Cron: */5 * * * * cd /path/to/repo && bd gate check
  • Agent hook: Run at session start or after PR operations

Recipes

PR Merge Gate (Common)

Agent A finishes work, opens PR, creates a gate so Agent B waits for merge:

CI Gate Before Deploy

Epic with Ordered Phases

See Also