beads issue tracking

📁 sttts/beads-skill 📅 Jan 1, 1970
2
总安装量
0
周安装量
#71138
全站排名
安装命令
npx skills add https://github.com/sttts/beads-skill --skill 'Beads Issue Tracking'

Skill 文档

Beads Issue Tracking

This skill provides workflow guidance for projects using the beads issue tracker.

Activation

Only apply these instructions when a .beads directory exists in the project root. If no .beads directory is present, this skill does not apply.

Session Start

Every session start, run bd prime to get AI-optimized workflow context.

Checking What’s Next

When the user asks “What’s next?”, run bd ready --pretty and propose the top items without asking for confirmation. Show a list like:

In-progress tasks:
- <task id>: <oneliner>
- ...

Ready tasks:
- <task id>: <oneliner>
- ...

Creating Issues

Treat user phrases “Add task” and “Add epic” as instructions to use bd create with the appropriate type.

Use sensible keywords in task IDs following the pattern <prefix>-<epic>-<task>:

  • prefix: domain area (e.g., infra, api, ui)
  • epic: one or two keywords for the epic
  • task: one keyword for the specific task

Example Commands

# Create a task
bd create "Allow blueprints to run in plan only mode" --id infra-blueprint-planonly --type task

# Create an epic
bd create "Expose Terraform errors to conditions" --id infra-tferrors --type epic

# Create a task under an epic
bd create "Phase 1: Enable log subresource" --id infra-tferrors-logsub --type task --parent infra-tferrors

Task State Management

Always set tasks in-progress when working on them, and close when finished.

Always put the MR/PR URL as label on tasks. When the user references a PR, use bd list --label "<URL>" to find the task.

Epics

Every epic work MUST happen in a dedicated worktree. Create it with:

bd worktree create .git/checkouts/<branch-name>

Always use the same worktree and branch. Never divert without the user telling you.

Landing the Plane (Session Completion)

When ending a work session, 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
    bd sync
    git push origin <branch-name>
    git status  # MUST show "up to date with origin"
    
  5. Label – Put the PR/MR URL on the task
  6. Clean up – Clear stashes, prune remote branches
  7. Verify – All changes committed AND pushed
  8. Hand off – Add a bd comments add <task-id> "HANDOFF: ..." comment explaining what the next agent should do (e.g., check MR status, address feedback, close task)

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” – push immediately
  • If push fails, resolve and retry until it succeeds
  • Only close a task when the MR is merged. Rather defer a task for an hour if uncertain.
  • When deferring a task, ALWAYS add a handoff comment first: bd comments add <task-id> "HANDOFF: ..." explaining what the next agent should do
  • Never leave the worktree unless asked. Only exception: switching to another epic or a task that already has a worktree.
  • Never touch the main checkout without the user telling you.