/work-ticket

Pick up the top-priority bead from the ready queue and ship it through the full delivery chain — claim, branch, implementation, tests, CI, PR, review — without babysitting each step.

When to use it

This is the everyday command. You run /work-ticket when bd ready --json --type=task has candidates and you want the worker agent to advance the top bead through the implementation cycle. The agent claims the bead, creates a feature branch, implements the change, runs lint and tests locally, pushes, opens a pull request, watches CI, and — on green CI — auto-launches /review-pr so the reviewer agent has the next move ready.

You watch this happen. That is the gemba walk: agents do the work, you watch the line.

If the worker takes a turn you disagree with — wrong abstraction, missed a guardrail, overthinks a simple change — interrupt and redirect. Specifying the next move (“simpler — just edit the existing function”) is the right correction, not “no don’t do that.”

For changes too small to warrant ticket ceremony (a typo, a lint violation, a one-line config tweak), use /quick-fix instead — same branch + PR discipline, no bead mutations.

How it fits in the lifecycle

/groom-backlog completes DoR so beads surface in bd ready. /work-ticket picks the top item and ships it through CI to an approved PR. Only the human merges.

What it does

Pre-flight

Before touching any bead the agent verifies:

gh CLI is authenticated and the repository is accessible
The active GitHub account matches the expected worker account (va-worker)
The beads tracker is available: bd ready --json parses and .beads/ exists

If invoked from /drain (DRAIN_CONTEXT=true), additionally:

Exactly one safety:* label is present on the bead (zero or multiple = stop, signal drain to continue with the next bead)
The safety class is drain-eligible (safety:flagged, safety:internal, or safety:reversible); safety:hot is refused and left unclaimed

Claim semantics

Claiming is atomic:


bd update <id> --claim

Two workers can never grab the same bead. If --claim fails, the bead was already taken by another worker; select the next one from bd ready. The claim is the in-progress signal — there is no board to move anything on, no card to drag.

Branch naming


git checkout -b feature/<bead-id>-short-description
# examples:
git checkout -b feature/gs-agw.2-command-trio
git checkout -b feature/va-3f2-checkout-webhook

The bead id anchors the branch name. Never use feature/issue-{N} (that was the GitHub-Issues era convention).

Implementation

The agent follows CLAUDE.md standards, reads existing patterns, and keeps changes inside ticket scope. Stale ticket descriptions are flagged in the PR body — never silently reinterpreted.

Tests and pre-push gate

All tests must pass before pushing:


npm run lint
npm run typecheck
npm test
npm run build

The pre-push hook enforces this. --no-verify is forbidden.

Pull request body

The PR body cites the bead:


Bead: <id>

Closes #N is retired — GitHub Issues are the public intake inbox, not the tracker. The bead is the work-item source of truth.

The worker copies the bead’s safety:* label onto the PR at creation:


gh pr edit <N> --add-label safety:internal   # (example)

In-review labels

Immediately after gh pr create:


bd update <id> --add-label in-review --add-label pr:<N>
bd comment <id> "PR: <url>"

The in-review + pr:<N> label pair is the persistent in-review signal on the bead — not a column, not a board state.

CI monitoring


gh pr checks <N> --watch

The agent watches checks, auto-fixes failures up to 3 times before escalating. On green CI it auto-launches /review-pr on the new PR — no human re-confirmation required between push and review.

Auto-handoff to reviewer

On green CI, the worker launches the pr-reviewer agent with the PR number. The reviewer posts a GO or NO-GO verdict as a verdict:* label and a bd comment. The human stays out of the loop until the verdict is posted. If CI never reaches green within 3 fix attempts, the handoff is skipped — an escalation comment is left on the PR and the bead stays claimed.

Workers never close beads

The worker’s authority ends at the PR. bd close belongs to the orchestrator or human path, and only after gh pr view <N> --json state,mergedAt confirms the merge. Never close, even on a clear success signal.

Usage


/work-ticket                    # pick the top bead from bd ready --json --type=task
/work-ticket gs-agw.2           # work a specific bead (drain mode)

/groom-backlog — completes DoR so beads surface in bd ready before this command picks them
/quick-fix — the lightweight sibling for changes that don’t warrant full ticket ceremony
/swarm — when a ticket admits variation across an axis and you want N parallel implementations
/review-pr — auto-chained from /work-ticket on green CI per project policy

Canonical spec: .claude/commands/work-ticket.md