task-movelisted

# 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