Workflows

An Operator workflow is a process defined once in JSON: an ordered graph of typed steps, review gates, and retry edges that an LLM agent can follow. It is the native format — Operator runs it directly, and every export format (Claude, AGNT) is derived from it.

Three terms, three different things:

Collections are deliberately separate from your kanban issue types. Jira, Linear, and GitHub Projects types describe how your team labels work; a collection describes how the agents do it. Map one onto the other once, and the workflow travels between projects, teams, and providers unchanged.

Every collection below is installable from Operator directly — they are published from this site as a machine-readable index that operator instances read on startup.

Contribute a collection

There is no single best way to run agents — the right loop depends on the work. That is exactly why these are shareable: a workflow that works for you is worth publishing, and one that does not fit is worth forking.

Official collections live in the operator repository:

1. Create collections/community/<id>/, where <id> matches ^[a-z0-9_]{3,64}$.
2. Add a collection.json conforming to the collection schema, with tier: "community" plus author, url, and license.
3. Add one <KEY>.json per issue type — see the issue type schema — and an optional <KEY>.md ticket template.
4. Add an icon.svg following the Simple Icons shape: a 24×24 viewBox, a single <path>, and no fill or stroke so it inherits the page’s color.
5. Leave checksums out — they are computed at publish time.
6. Run the CI gate locally, then open a pull request:

cargo test --test community_collections

Submissions are reviewed for prompt quality and safety, not just schema validity. A good collection describes a workflow shape worth sharing: what loop it runs, what memory it keeps, what gates it enforces, and when it stops.