baronlisted

# Baron Baron normalizes work orchestration so you speak **abstract roles**, not vendor states. The active providers are whatever `.baron/policy.json` binds (run `baron init` first if it is missing). ## Vocabulary (never use provider-native states) - Workflow roles: `backlog → ready → in_progress → in_review → done`. **`blocked` is not among them** — it is an orthogonal flag (`baron_issue_move { op: "block" | "unblock" }`), so a blocked item keeps the role its work is actually in, and unblocking returns it there. - Type roles: `initiative`, `epic`, `story`, `task`, `bug`, `subtask`. - Link types: `relates`, `blocks`, `blocked_by`, `duplicates`. Baron translates these to each provider's native states/types/links and negotiates capability gaps (emulate / degrade / error) — you never hardcode an Azure state or a GitHub label. ## MCP tools (this plugin registers the `baron` MCP server) Issues port: `baron_issue_write op=create`, `baron_issue_read op=get`, `baron_issue_write op=update` (edit title/body — a patch, omitted fields keep their value; the body lands in the field the type uses, so a bug's body is its repro steps. Use it to fix a title or fill in a description after creation; it does NOT move the role or the assignee), `baron_issue_move op=transition`, `baron_issue_write op=comment`, `baron_issue_write op=link`, `baron_issue_write op=assign` (provider-native handle: Azure email, GitHub login), `baron_issue_read op=iterations` + `baron_issue_write op=set_iteratio