Files

T

beads/crew/dave f03c754df1 refactor: move Claude Code plugin to dedicated subdirectory (GH#985)

Move all plugin content to claude-plugin/ subdirectory for cleaner
separation from core beads functionality:

- claude-plugin/.claude-plugin/plugin.json - plugin manifest
- claude-plugin/commands/ - all slash commands
- claude-plugin/agents/ - task-agent (now in correct location)
- claude-plugin/skills/beads/ - beads skill with resources

Root .claude-plugin/ now only contains marketplace.json pointing
to ./claude-plugin.

Note: After updating, users may need to clear plugin cache:
  rm -rf ~/.claude/plugins/cache/beads-marketplace/

Fixes #985

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

Executed-By: beads/crew/dave
Rig: beads
Role: crew

2026-01-09 22:59:11 -08:00

2.0 KiB

Raw Blame History

Using bd for Static Reference Data

bd is primarily designed for work tracking, but can also serve as a queryable database for static reference data with some adaptations.

Work Tracking (Primary Use Case)

Standard bd workflow:

Issues flow through states (open → in_progress → closed)
Priorities and dependencies matter
Status tracking is essential
IDs are sufficient for referencing

Reference Databases / Glossaries (Alternative Use)

When using bd for static data (terminology, glossaries, reference information):

Characteristics:

Entities are mostly static (typically always open)
No real workflow or state transitions
Names/titles more important than IDs
Minimal or no dependencies

Recommended approach:

Use separate database (not mixed with work tracking) to avoid confusion
Consider dual format: maintain markdown version alongside database for name-based lookup
Example: A terminology database could use both terms.db (queryable via bd) and GLOSSARY.md (browsable by name)

Key difference: Work items have lifecycle; reference entities are stable knowledge.

When to Use This Pattern

Good fit:

Technical glossaries or terminology databases
Reference documentation that needs dependency tracking
Knowledge bases with relationships between entries
Structured data that benefits from queryability

Poor fit:

Data that changes frequently (use work tracking pattern)
Simple lists (markdown is simpler)
Data that needs complex queries (use proper database)

Limitations

bd show requires IDs, not names:

bd show term-42 works
bd show "API endpoint" doesn't work
Workaround: bd list | grep -i "api endpoint" to find ID first
This is why dual format (bd + markdown) is recommended for reference data

No search by content:

bd searches by ID, title filters, status, labels
For full-text search across descriptions/notes, use grep on the JSONL file
Example: grep -i "authentication" .beads/issues.jsonl

2.0 KiB Raw Blame History