zanaat-dev/baron

> Let your coding agent write to your work tracker — and keep the same flow when you change trackers.
> Baron is an open-source layer that turns issues, branches, PRs, CI runs, and deployments into one
> normalized contract, so your agent never learns a vendor's API, states, or column names.
Docs and site: baron.zanaat.dev
## The problem
AI coding agents bake one vendor's API and one team's process into prompts. The moment your
issues live in Azure DevOps but your code is on GitHub, or your board columns aren't literally "To Do
/ Done", or you switch trackers next quarter — the prompts break, and the agent falls back to raw,
vendor-specific tools. You've hardcoded vendor lock-in into the way you work.
## What Baron does
Plenty of tools let an agent read your tracker. Baron is about the other direction: writing —
creating work items, moving them, cutting branches, opening and merging PRs — which is where an agent
does damage when it guesses a vendor's state machine wrong.
The agent speaks one abstract vocabulary in terms of roles (backlog → ready → inprogress →
inreview → done; blocking is an orthogonal flag, so a blocked item keeps the role the work is
actually in), and Baron translates to each provider's real API, states, and
quirks. You confirm that mapping once, at baron init, and it is committed to your repo as
configuration — not re-guessed by the model on every call.
Each port binds to a provider independently, so issues on Azure DevOps, scm on GitHub, and
notify on Slack is a normal setup rather than a special case.
## What it looks like
You: Start work on STORE-142.
Baron ▸ runs the task-start recipe as a single call:
✓ Loaded STORE-142 "Add rate limiting to the login endpoint" (type role: task)
✓ Checked it: not done, has a canonical branch, not assigned to someone else
✓ Branched feature/STORE-142 from the repo's default branch
✓ Moved STORE-142 → inprogress, assigned to you
✓ Commented on the item: "Started work — on branch feature/STORE-142."
That same prompt on Azure DevOps sets the work item state to Active; on GitHub it applies an
in-progress label — because inprogress is a role, not a vendor state.
The checks matter as much as the actions: if the item is already done, belongs to someone else, or is
a container that should never be branched, the run stops before anything is created. The branch
name is derived by Baron from the item's type role, so every agent and every recipe derives the same
name for the same item instead of inventing one.
## Why it's different
Capability ports, not "a tracker." issues / scm / ci / deploy / notify, each bound to
a provider independently — so a consumer mixes providers rather than betting on one vendor spanning
everything.
Normalize, don't raw-proxy. New capabilities become first-class normalized ports; a clearly
labeled provider-native escape hatch is the explicit last resort, never the default path.
Capability gaps are never silent. When a provider lacks something (say, native issue hierarchy),
Baron either emulates it (e.g. labels), degrades with a warning, or errors loudly — decided by
policy, never swallowed.
Workflows are recipes, not prompts. Multi-step flows (task-start, task-finish, task-land,