Skip to main content
Beads supports several types of links between issues to create a knowledge graph. These links enable rich querying and traversal beyond simple blocking dependencies.

replies-to - Conversation Threading

Creates message threads, similar to email or chat conversations. Created by:
  • Orchestrator mail reply commands (orchestrator handles messaging)
  • bd dep add <new-id> <original-id> --type replies-to (manual linking)
Use cases:
  • Agent-to-agent message threads
  • Discussion chains on issues
  • Follow-up communications
Example:
Viewing threads:

relates-to - Loose Associations

Bidirectional “see also” links between related issues. Not blocking, not hierarchical - just related. Created by:
  • bd dep relate <id1> <id2> - Links both issues to each other
Removed by:
  • bd dep unrelate <id1> <id2> - Removes link in both directions
Use cases:
  • Cross-referencing related features
  • Linking bugs to associated tasks
  • Building knowledge graphs
  • “See also” connections
Example:
Multiple links: An issue can have multiple relates-to links:

duplicates - Deduplication

Marks an issue as a duplicate of a canonical issue. The duplicate is automatically closed. Created by:
  • bd duplicate <id> --of <canonical>
Use cases:
  • Consolidating duplicate bug reports
  • Merging similar feature requests
  • Database deduplication at scale
Example:
Behavior:
  • Duplicate issue is automatically closed
  • Original (canonical) issue remains open
  • duplicate_of field stores the canonical ID

supersedes - Version Chains

Marks an issue as superseded by a newer version. The old issue is automatically closed. Created by:
  • bd supersede <old-id> --with <new-id>
Use cases:
  • Design document versions
  • Spec evolution
  • Artifact versioning
  • RFC chains
Example:
Behavior:
  • Old issue is automatically closed
  • New issue remains in its current state
  • superseded_by field stores the replacement ID

Schema Fields

These fields are added to issues:

View Issue Details

Shows all link types for an issue:

View Threads

Follows replies-to chain to show conversation history.

JSON Output

Returns all fields including graph links:

Comparison with Dependencies

Use Cases

Knowledge Base

Link related documentation:

Bug Triage

Consolidate duplicate reports:

Version History

Track document evolution:

Message Threading

Build conversation chains (via orchestrator mail):

Best Practices

  1. Use relates-to sparingly - Too many links become noise
  2. Prefer specific link types - duplicates is clearer than generic relates-to
  3. Keep threads shallow - Deep reply chains are hard to follow
  4. Document supersedes chains - Note why version changed
  5. Query before creating duplicates - bd search first

See Also