beads

Graph-based issue tracking represents tasks and dependencies as a connected graph stored in a .beads directory. This state is managed via standard git workflows, allowing commits, syncs, and reviews to track architecture-driven work items alongside the codebase.

You track architecture dependencies by seeding a graph from design docs into .beads/issues.jsonl. Using the bd command set, you create updates and manage dependencies, ensuring the issue state travels with your codebase through standard git commits.

Yes, the dependency graph supports multi-team planning and execution. Teams use deterministic workflows to seed, orient, evolve, and checkpoint work items, enabling structured handoffs and coordinated execution across multiple groups.

The best way to prioritize work items is using the bv viewer. It provides graph metrics and prioritization capabilities, helping teams orient their sessions to pick the next work item based on the connected dependency structure.

No, it does not require an external database or server. All issue state is stored portably in the .beads directory under git control, enabling sync and review directly through standard version control workflows without external dependencies.

Seed the initial beads graph directly from your architecture docs, start a session with beads-orient to select the next task, and begin the work loop with beads-evolve to update the graph as dependencies unfold.