colony-content
A lean pipeline for documentation and content work.
Every team reviews, merges and escalates differently. Colony’s pipeline runs on a workflow definition your team can read, version and diff — so the agents work the way your org works. When your process changes, you change a file, not a vendor.
Most teams start with the default pipeline — intake to merged pull request, human merge gate on. It encodes what we learned running Colony on its own development for months. You only reach for a custom workflow when the default genuinely doesn’t fit.
A workflow names every state an issue can be in, what runs there, and where each outcome leads. It is validated before anything executes — a bad file fails validation, never an issue in flight. Intake rules route work by label, type or content, so different work can follow different paths through the same pipeline. Publishing a change means a new version, not a code edit, so process changes carry the same review discipline as code changes.
Custom executors plug into the same state machine through a public, Apache-2.0 SDK — same task queue, same cost reporting, same workspace handling as the built-ins. Two plugins ship as worked examples: a content pipeline and a first-line support responder.
A lean pipeline for documentation and content work.
A first-line responder that answers issues in a dedicated support repo, with no pull request involved.
File issues, check status, estimate cost and trigger retries from Claude Code, Cursor or any MCP client — or from the CLI. Colony Cloud customers get a hosted MCP endpoint (compare self-host and cloud); self-hosted teams run their own.
For engineers: workflow schema, routing, SDK and CLI reference in the docs.
Pilot setup includes a look at how your issues move today and which workflow fits.