baton

Use when addressing code-review feedback on a pull request this side owns - "/baton:address-review", "address the review comments", "handle the PR feedback". Collects every surface feedback lands on, builds an inventory, stops for a ruling, then applies, verifies, publishes, and answers each item where it arrived.

Use when review findings need to become tracker issues - after a code review, audit, or repo read that produced defects, gaps, or improvement ideas. Files one categorized issue per finding through the configured tracker, anchored to a commit so line references stay resolvable.

Use when a handoff describes work that is ready to build - launched as "/baton:implement-handoff <handoff locator>", usually by a session that investigate-issue started. Turns one handoff into a reviewed pull request and runs unattended.

Use when a tracker issue needs a cause and an approach before any code is written - taking an issue off the backlog, "investigate

Use when the next issue to work on has to be chosen rather than named - "what should I work on", "pick the next issue", "/baton:next-issue", or investigate-issue invoked with no issue number. Resolves one issue assigned to the user that is not already waiting on a handoff, and reports what it skipped.

Use when reviewing someone else's pull request - "/baton:review-pr", "review PR 631", "review this PR", "go through the PR and comment". Resolves the target, reviews its diff, drafts the findings for approval, and posts them as one review only on an explicit go-ahead.

Use when reviewing the branch an unattended implement-handoff run produced, before anyone else is asked to look at it - "/baton:self-review", "review the handoff branch", "check the work before I push". Reviews on the premise that everything the run wrote is an unverified claim, applies only the fixes the user approves, and publishes nothing without a separate go-ahead.

Use when baton has to be pointed at a tracker other than GitHub, or an existing backend file has to be completed or repaired - "/baton:setup", "configure the baton backend", "point baton at Linear". Writes the backend file with every operation its sections own and verifies it by running them. Does not apply to filing, investigating, implementing or reviewing work.

Use when writing or revising any text another person or a future session will read - README, repo docs, PR descriptions and comments, commit messages, reports, analyses, handoff/context notes, ADRs, runbooks, issue bodies, prompt/agent docs - or a draft of one. Sets the reader, the shape, and the admission test every sentence must pass before the document counts as done.

Use when work has to continue in a session that does not share this context - launching an implementation run in the cloud or in the background, stopping mid-task, or handing work to another person. Posts the handoff to the issue driving the work, and writes the body under write-deliverables.