Kanbus

Feature

Issue router

Turn a labeled issue into one controlled coding-agent run that ends in a pull request and an issue in review, with your team deciding what starts and what merges.

The issue router is an optional loop that hands bounded work to a coding agent without turning the board into an opaque queue. You opt an issue in with a label. The router checks that it is eligible, gives the agent an isolated Git worktree, validates the structured result the agent returns, and opens or updates a GitHub pull request. The issue moves to your review status. Merging stays with your normal review process.

What changes for a team

  1. Mark the package. Add exactly one agent-class:<name> or agent-provider:<profile> label to an issue. Its untagged descendants travel with it as one package.

  2. Dispatch with guardrails. The router respects policy, dependencies, work-in-progress limits and routing order before it starts one eligible package with your configured agent, Codex or OpenCode.

  3. Review ordinary Git work. A valid completed result opens or updates a pull request and moves the package to review. When GitHub reports the approved pull request as merged, the router moves the package to your terminal status.

The adapter proposes changes as a structured result; it does not edit Kanbus issue data directly. Kanbus validates scope, workflow transitions and claim ownership before accepting anything.

Run it

Add a router: block to .kanbus.yml that maps the router's roles to statuses in your workflow (including a review status), sets limits, and names the agent profiles and GitHub repository. Then look at the plan before dispatching anything.

kbs router plan
kbs router run --once

run --once processes at most one eligible package and exits. For continuous operation, watch mode reconciles immediately and then polls router state and pull requests on an interval (30 seconds by default).

kbs router run --watch
kbs router status
kbs router pause
kbs router hold --class implementation
kbs router cancel kanbus-a1b2c3

Pause, hold and watch state apply to the clone you run them in; they are recorded in router history for audit but are not inherited by other clones.

Coordination that grows with you

Router state and event history are published to a dedicated Git branch, kanbus/router-state, so Git stays the durable record at every level.

Git

Enough for a single worker. Claims are soft and recorded in Git.

MQTT and Git

MQTT improves how quickly workers see each other's claims. Coordination is still soft, so duplicate starts are possible during a visibility gap.

Mutex API, MQTT and Git

A live lease is required before work starts. If the mutex service is unavailable, the router starts nothing rather than falling back to weaker coordination.

Retryable failures back off and retry up to a configured limit, then block the package with a diagnostic. If a worker dies, a later worker can take over after the lease goes stale, using a newer claim and the last accepted checkpoint. When an agent stops with a question, the issue moves to blocked; answer with a comment and move it back to the pending status, and the router resumes the same agent session.

Learn more