bd-workflow
How to use bd (beads) for issue tracking, ready work, status updates, and comments in this repo.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
How to use bd (beads) for issue tracking, ready work, status updates, and comments in this repo.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use the local pr-watch CLI/daemon to watch GitHub pull request activity, wait for PR changes, and fetch normalized event deltas without manually managing webhook forwarding or event subscriptions.
One lifecycle for Lambda repos: choose a bd task, start work, land the PR, and watch GitHub via Dumbwaiter MCP until it merges.
Default Python stack for Lambda: uv + Astral tools, typed code, schemas, and Hypothesis.
Zero Framework Cognition Principles
Provider-agnostic wait-for-change skill that uses the Dumbwaiter MCP server to wait on PR events (GitHub first) via wait.start/status/cancel/await, with progress notifications and durable state.
Default TypeScript stack for Lambda: pnpm workspaces + Turbo, strict TS, and sensible DX helpers.
| name | bd-workflow |
| description | How to use bd (beads) for issue tracking, ready work, status updates, and comments in this repo. |
This document expands the abbreviated rules in AGENTS.md. Read this whenever you interact with task tracking, planning docs, or MCP helpers.
.beads/issues.jsonl, so repos capture task history.--json) plus "ready" filtering.bd ready --json -n 0 # find unblocked work
bd create "Issue title" -t task -p 2 --json
bd update bd-42 --status in_progress --json
bd close bd-42 --reason "Completed" --json
Always run bd with --json. Pipe/parse as needed.
bug, feature, task, epic, chore.0 (critical) through 4 (backlog). Respect existing priority unless the PM/user changes it.bd ready --json -n 0. Do this before asking what to work on.bd update <id> --status in_progress --json (add notes if relevant).bd create "Fix follow-up" -p 1 --deps discovered-from:<parent> --json).bd close <id> --reason "Completed" --json at that point; merge or green CI is not required. If CI later fails or review feedback arrives, flip back to in_progress, address it, and close again once satisfied..beads/issues.jsonl alongside code. Never leave tracker changes uncommitted..beads/issues.jsonl automatically (5s debounce) after changes.git pull, bd imports newer JSONL back into the local state. No manual sync needed..beads/*.jsonl, prefer git merge (not rebase) so the custom merge=beads driver can resolve cleanly; avoid rewriting history that would replay bd edits and create duplicate entries.pip install beads-mcp.~/.config/claude/config.json:{
"beads": {
"command": "beads-mcp",
"args": []
}
}
mcp__beads__* calls instead of the CLI if your client supports MCP.AI-generated planning/design docs should live under history/ (add it to .gitignore if desired). Keeping the repo root clean avoids confusing ephemeral plans with durable docs.
.beads/issues.jsonl in every relevant commit.history/.--json.When the user says "let's land the plane", you MUST complete ALL steps below. The plane is NOT landed until git push succeeds. NEVER stop before pushing. NEVER say "ready to push when you are!" - that is a FAILURE.
MANDATORY WORKFLOW - COMPLETE ALL STEPS:
File beads issues for any remaining work that needs follow-up
Ensure all quality gates pass (only if code changes were made) - run tests, linters, builds (file P0 issues if broken)
Update beads issues - close finished work, update status
PUSH TO REMOTE - NON-NEGOTIABLE - This step is MANDATORY. Execute ALL commands below:
# Pull first to catch any remote changes
git pull --rebase
# If conflicts in .beads/beads.jsonl, resolve thoughtfully:
# - git checkout --theirs .beads/beads.jsonl (accept remote)
# - bd import -i .beads/beads.jsonl (re-import)
# - Or manual merge, then import
# Sync the database (exports to JSONL, commits)
bd sync
# MANDATORY: Push everything to remote
# DO NOT STOP BEFORE THIS COMMAND COMPLETES
git push
# MANDATORY: Verify push succeeded
git status # MUST show "up to date with origin/main"
CRITICAL RULES:
git push completes successfullygit push - that leaves work stranded locallygit push fails, resolve the issue and retry until it succeedsClean up git state - Clear old stashes and prune dead remote branches:
git stash clear # Remove old stashes
git remote prune origin # Clean up deleted remote branches
Verify clean state - Ensure all changes are committed AND PUSHED, no untracked files remain
Choose a follow-up issue for next session
REMEMBER: Landing the plane means EVERYTHING is pushed to remote. No exceptions. No "ready when you are". PUSH IT.
Example "land the plane" session:
# 1. File remaining work
bd create "Add integration tests for sync" -t task -p 2 --json
# 2. Run quality gates (only if code changes were made)
go test -short ./...
golangci-lint run ./...
# 3. Close finished issues
bd close bd-42 bd-43 --reason "Completed" --json
# 4. PUSH TO REMOTE - MANDATORY, NO STOPPING BEFORE THIS IS DONE
git pull --rebase
# If conflicts in .beads/beads.jsonl, resolve thoughtfully:
# - git checkout --theirs .beads/beads.jsonl (accept remote)
# - bd import -i .beads/beads.jsonl (re-import)
# - Or manual merge, then import
bd sync # Export/import/commit
git push # MANDATORY - THE PLANE IS STILL IN THE AIR UNTIL THIS SUCCEEDS
git status # MUST verify "up to date with origin/main"
# 5. Clean up git state
git stash clear
git remote prune origin
# 6. Verify everything is clean and pushed
git status
# 7. Choose next work
bd ready --json
bd show bd-44 --json
Then provide the user with:
CRITICAL: Never end a "land the plane" session without successfully pushing. The user is coordinating multiple agents and unpushed work causes severe rebase conflicts.