task-move

Move a work item to a role

Baron's baron_issue_move op=transition resolves an abstract role to the provider's native state/column atomically (Azure: state + board column; GitHub: label + open/closed). This skill wraps it with the reference's governance: backward and reopen moves require a reason, and the reason is recorded on the item before the state changes.

The role order (the guard rule)

backlog(0) → ready(1) → in_progress(2) → in_review(3) → done(4)

Blocking is not on this line at all: it is an orthogonal flag set by `baron_issue_move op=block` and cleared
by `baron_issue_move op=unblock`, and it leaves the role untouched.

Classify the move from the item's current role to the target:

• advance — to a higher index → just move.
• regress — to a lower index (not from done) → reason required.
• reopen — from done to any active role → reason required.
• noop — same role → report and stop (idempotent, nothing to do).

Block / unblock are not moves at all. They set and clear an orthogonal flag, so they never appear in the table above and never change the role. Use baron_issue_move { op: "block", id, reason } — the reason is required by the engine, not just by this skill, and it is posted on the item before the flag is set — and baron_issue_move { op: "unblock", id, reason? }. A blocked item keeps the role it is blocked in, so there is nothing to "move back to" on unblock.

Steps

1. Resolve inputs. If the user asked to block or unblock, go to Blocking below — it is not a move. Otherwise the target role from the argument (must be one of the five workflow roles — reject anything else, listing the valid ones). The id: from the argument, else derive it from the current branch (<prefix>/<id>-<slug>); if neither, ask.
2. Reason. Look up what the move would be — baron_issue_read { op: "classify", id, role } answers advance / regress / reopen / noop without moving anything. For regress and reopen, ask the user for a one-line reason (open-ended, so ask directly rather than with a menu). Asking first is better UX than handing them a refusal — but it is not what makes the rule hold.
3. Run the recipe — call baron_recipe_run exactly once: