Agent Instructions

May 13, 2026 · View on GitHub

See AGENT_INSTRUCTIONS.md for full instructions.

This file exists for compatibility with tools that look for AGENTS.md.

The marker above tells bd doctor that the intentional divergence between this file and CLAUDE.md (different audiences, different reading orders) is expected and should not be flagged.

Key Sections

  • Issue Tracking - How to use bd for work management
  • Development Guidelines - Code standards and testing
  • Project Scope - Read docs/PROJECT_CHARTER.md before adding new feature surface area
  • Visual Design System - Status icons, colors, and semantic styling for CLI output
  • Contributor Protection - Read CONTRIBUTING.md before handling external PRs
  • Maintainer PR Guidelines - Read PR_MAINTAINER_GUIDELINES.md before triaging, landing, or closing PRs

Project Scope

Before adding new feature surface area, read docs/PROJECT_CHARTER.md. Beads owns issue tracking primitives and should not encode orchestration-layer policy, become a storage engine, or casually expand the database schema when metadata would work.

PR Safety for Agents

Before triaging, reviewing, landing, closing, or otherwise maintaining PRs, read PR_MAINTAINER_GUIDELINES.md. The maintainer policy is to maximize community throughput: find useful contributor value, absorb or transform it locally when practical, preserve attribution, and use request-changes only as a last resort.

Before implementing work, opening a PR, or merging/closing a PR, run the PR preflight:

scripts/pr-preflight.sh --search "<topic keywords>" --repo gastownhall/beads
scripts/pr-preflight.sh <pr-number> --repo gastownhall/beads

External contributor PRs have priority. Review and build on their branch when possible, preserve their tests and attribution, and never close or supersede their PR silently. If a rewrite is unavoidable, explain why on the original PR and credit their design/tests.

Visual Design Anti-Patterns

NEVER use emoji-style icons (🔴🟠🟡🔵⚪) in CLI output. They cause cognitive overload.

ALWAYS use small Unicode symbols with semantic colors:

  • Status: ○ ◐ ● ✓ ❄
  • Priority: ● P0 (filled circle with color)

See AGENT_INSTRUCTIONS.md for full development guidelines.

Storage Boundary

The canonical storage boundary is in docs/PROJECT_CHARTER.md. In short: Beads talks to storage through a driver interface (dolthub/driver for Dolt). Do not add beads-side flocks, engine introspection, storage-specific retry or crash-recovery logic, or public SDK return types that leak driver internals. If the boundary is too narrow, widen the interface or route the issue to the driver instead of patching around it in beads.

Agent Warning: Interactive Commands

DO NOT use bd edit - it opens an interactive editor ($EDITOR) which AI agents cannot use.

Use bd update with flags instead:

bd update <id> --description "new description"
bd update <id> --title "new title"
bd update <id> --design "design notes"
bd update <id> --notes "additional notes"
bd update <id> --acceptance "acceptance criteria"

# Use stdin for descriptions with special characters (backticks, !, nested quotes)
echo 'Description with `backticks` and "quotes"' | bd create "Title" --description=-
echo 'Updated text' | bd update <id> --description=-

Testing Commands (No Ambiguity)

  • Default local test command: make test (or ./scripts/test.sh).
  • Opt-in ICU regex path: make test-icu-path (or ./scripts/test-icu-path.sh ./...).
  • This ICU path is maintainer-only and not part of normal validation; make test-full-cgo and ./scripts/test-cgo.sh are deprecated aliases.
  • For package- or test-scoped shipped-config CGO runs, prefer:
CGO_ENABLED=1 go test -tags gms_pure_go ./cmd/bd/...
CGO_ENABLED=1 go test -tags gms_pure_go -run '^TestName$' ./cmd/bd/...

Non-Interactive Shell Commands

ALWAYS use non-interactive flags with file operations to avoid hanging on confirmation prompts.

Shell commands like cp, mv, and rm may be aliased to include -i (interactive) mode on some systems, causing the agent to hang indefinitely waiting for y/n input.

Use these forms instead:

# Force overwrite without prompting
cp -f source dest           # NOT: cp source dest
mv -f source dest           # NOT: mv source dest
rm -f file                  # NOT: rm file

# For recursive operations
rm -rf directory            # NOT: rm -r directory
cp -rf source dest          # NOT: cp -r source dest

Other commands that may prompt:

  • scp - use -o BatchMode=yes for non-interactive
  • ssh - use -o BatchMode=yes to fail instead of prompting
  • apt-get - use -y flag
  • brew - use HOMEBREW_NO_AUTO_UPDATE=1 env var

Landing the Plane (Session Completion)

When ending a work session, you MUST complete ALL steps below. Work is NOT complete until git push succeeds.

MANDATORY WORKFLOW:

  1. File issues for remaining work - Create issues for anything that needs follow-up
  2. Run quality gates (if code changed) - Tests, linters, builds
  3. Update issue status - Close finished work, update in-progress items
  4. PUSH TO REMOTE - This is MANDATORY: 
    git pull --rebase
git push
git status  # MUST show "up to date with origin"
  5. Clean up - Clear stashes, prune remote branches
  6. Verify - All changes committed AND pushed
  7. Hand off - Provide context for next session

CRITICAL RULES:

  • Work is NOT complete until git push succeeds
  • NEVER stop before pushing - that leaves work stranded locally
  • NEVER say "ready to push when you are" - YOU must push
  • If push fails, resolve and retry until it succeeds

Issue Tracking with bd (beads)

IMPORTANT: This project uses bd (beads) for ALL issue tracking. Do NOT use markdown TODOs, task lists, or other tracking methods.

Why bd?

  • Dependency-aware: Track blockers and relationships between issues
  • Git-friendly: Dolt-powered version control with native sync
  • Agent-optimized: JSON output, ready work detection, discovered-from links
  • Prevents duplicate tracking systems and confusion

Quick Start

Check for ready work:

bd ready --json

Create new issues:

bd create "Issue title" --description="Detailed context" -t bug|feature|task -p 0-4 --json
bd create "Issue title" --description="What this issue is about" -p 1 --deps discovered-from:bd-123 --json

# Use stdin for descriptions with special characters (backticks, !, nested quotes)
echo 'Description with `backticks` and "quotes"' | bd create "Title" --description=- --json

Claim and update:

bd update <id> --claim --json
bd update bd-42 --priority 1 --json

Complete work:

bd close bd-42 --reason "Completed" --json

Issue Types

  • bug - Something broken
  • feature - New functionality
  • task - Work item (tests, docs, refactoring)
  • epic - Large feature with subtasks
  • chore - Maintenance (dependencies, tooling)

Priorities

  • 0 - Critical (security, data loss, broken builds)
  • 1 - High (major features, important bugs)
  • 2 - Medium (default, nice-to-have)
  • 3 - Low (polish, optimization)
  • 4 - Backlog (future ideas)

Workflow for AI Agents

  1. Check ready work: bd ready shows unblocked issues
  2. Read execution metadata first: before deciding local vs delegated work, model, or reasoning level, inspect structured metadata: 
    bd show <id> --json | jq '.[0] | {id,title,metadata,description,notes}'
    The execution metadata keys execution_agent_type, execution_suggested_model, execution_reasoning_effort, execution_mode, and execution_parallel_group are authoritative hints when present. Use description and notes as fallback context.
  3. Claim your task atomically: bd update <id> --claim
  4. Work on it: Implement, test, document
  5. Discover new work? Create linked issue:
    • bd create "Found bug" --description="Details about what was found" -p 1 --deps discovered-from:<parent-id>
  6. Complete: bd close <id> --reason "Done"

Auto-Sync

bd automatically syncs via Dolt:

  • Each write auto-commits to Dolt history
  • Use bd dolt push/bd dolt pull for remote sync
  • No manual export/import needed!

Important Rules

  • ✅ Use bd for ALL task tracking
  • ✅ Always use --json flag for programmatic use
  • ✅ Link discovered work with discovered-from dependencies
  • ✅ Check bd ready before asking "what should I work on?"
  • ❌ Do NOT create markdown TODO lists
  • ❌ Do NOT use external issue trackers
  • ❌ Do NOT duplicate tracking systems

For more details, see README.md and docs/QUICKSTART.md.