Beads Workflow
Using beads for issue tracking and workflow management in swarm.
Overview
Beads (bd) is an external CLI tool used by swarm for issue tracking and task management. It provides a git-native issue tracking system where issues are stored as files in a dedicated branch, making them accessible to both humans and AI agents without requiring an external service.
Swarm integrates with beads at two levels:
- Prompt injection — Available tasks are included in each agent's system prompt
- Agent workflow — Agents use
bdcommands to claim and close tasks during their sessions
Prerequisites
Beads must be installed before using swarm:
# Install beads
cargo install bd
# Verify installation
bd --version
Swarm checks for the bd binary at startup. If it's not found, swarm exits with an error and installation instructions.
How It Works
Task Discovery
During prompt building, swarm runs bd ready --json to fetch available (unclaimed) tasks. The results are injected into section 13 of the prompt pipeline:
## Available Tasks (from `bd ready`)
- #42: Implement health check endpoint [priority: high]
- #43: Add input validation to API routes [priority: medium]
- #51: Write integration tests for auth flow [priority: low]
This gives each agent awareness of what work is available without any manual coordination.
Agent Workflow
Agents interact with beads using these commands:
| Command | Description |
|---|---|
bd ready | List available (unclaimed) tasks |
bd show <id> | View full task details |
bd update <id> --status in_progress | Claim a task |
bd close <id> | Mark a task as complete |
bd sync | Synchronize with the shared beads branch |
A typical agent workflow:
- Agent sees available tasks in its prompt
- Claims a task with
bd update <id> --status in_progress - Works on the task (writing code, running tests)
- Closes the task with
bd close <id> - Next prompt cycle picks up remaining tasks
Shared Beads Branch
All agents in a session share a beads branch at:
swarm/<session-id>/beads
This branch uses optimistic concurrency — agents read and write independently, and conflicts are resolved on sync. This works well because:
- Issue files are small and rarely edited by multiple agents simultaneously
bd synchandles merge conflicts automatically- The worst case is a brief delay before an agent sees another's claim
Getting Started
Step 1: Initialize Beads
In your project directory:
bd onboard
This sets up the beads branch and initial configuration.
Step 2: Create Tasks
Create tasks for your project:
bd create "Implement health check endpoint" --priority high
bd create "Add input validation to API routes" --priority medium
bd create "Write integration tests for auth flow" --priority low
Or create tasks from spec documents:
bd create "Implement feature X per specs/042-feature-x.md"
Step 3: Start a Swarm Session
swarm start
Agents will automatically see available tasks in their prompts and can claim work.
Step 4: Monitor Progress
Check task status:
bd ready # See unclaimed tasks
bd list # See all tasks
bd show <id> # View task details
Spec-Driven Workflow
Swarm's recommended workflow (from CLAUDE.md) is spec-driven:
- Plan — Design the feature or fix
- Write specs — Create spec documents in
specs/capturing contracts - File beads tasks — Create tasks referencing the specs
- Run swarm — Agents pick up tasks and implement them
- Review — Verify agent work against the specs
This approach ensures agents have clear, well-defined tasks with acceptance criteria, rather than vague instructions.
Example Spec-to-Task Flow
- Write a spec:
<!-- specs/042-health-check.md -->
# Health Check Endpoint
## Contract
- GET /health returns 200 with JSON body `{"status": "ok"}`
- Response includes `uptime_seconds` field
- Endpoint requires no authentication
- File tasks from the spec:
bd create "Implement GET /health endpoint per specs/042-health-check.md"
bd create "Add health check integration test per specs/042-health-check.md"
- Start swarm — agents see the tasks, read the referenced spec, and implement accordingly.
Session Completion
When ending a work session, the recommended workflow is:
- File issues for remaining work — Create beads tasks for anything unfinished
- Update issue status — Close finished tasks, update in-progress items
- Sync and push:
bd sync
git push
This ensures the next session (or the next developer) has clear context on what's done and what remains.
Commands Reference
| Command | Description |
|---|---|
bd onboard | Initialize beads for a repository |
bd create <title> | Create a new task |
bd ready | List unclaimed tasks |
bd ready --json | List unclaimed tasks as JSON (used by prompt builder) |
bd list | List all tasks |
bd show <id> | Show task details |
bd update <id> --status <status> | Update task status |
bd close <id> | Close a completed task |
bd sync | Sync with shared beads branch |
Troubleshooting
"bd: command not found"
Install beads with cargo install bd and ensure it's in your PATH.
Tasks not appearing in agent prompts
- Verify
bd readyreturns tasks when run manually - Check that
bd ready --jsonproduces valid JSON output - Ensure beads is initialized in the project (
bd onboard)
Agents claiming the same task
This can happen due to the optimistic concurrency model. The impact is usually minor — both agents do the same work, and the duplicate can be discarded at review time. To reduce this:
- Use specific task descriptions that make it clear which agent should handle them
- Structure tasks around agent specializations (backend tasks for the backend agent, etc.)
Sync conflicts
bd sync handles most conflicts automatically. If a conflict can't be auto-resolved:
- Check
bd listfor the current state - Manually resolve any remaining conflicts
- Run
bd syncagain
Related
- Prompt Pipeline — How beads tasks are injected into prompts
- ADR-008: Beads Integration — Design rationale for beads as external dependency
- ADR-010: Beads Prompt Section — Design rationale for prompt injection
- Contributing: Spec Workflow — The spec-driven development process