Workflow

The Workflow tab shows the active workflow definition the pipeline executes for this repository. A workflow definition is a state machine: a named set of states, the transitions between them, the executors that perform work in each state, and the operator actions that move issues between states manually.

Navigate to the tab at /repos/<owner>/<name>/workflow. For an end-to-end walkthrough of how one issue moves through Colony’s pipeline, see The Workflow.

Selecting a version

The left panel lists every registered workflow version, grouped by workflow ID. The workflow with the most recent active issue is badged Active.

Each entry shows:

Field	Description
Name	Human-readable name from the workflow definition (falls back to the workflow ID if omitted).
Version	Integer version number, displayed as v<N>. Higher numbers are newer registrations.
Source	Where the definition was loaded from (for example, a file path or plugin package).
Age	Relative time since the version was registered (for example, “3 days ago”).

Click any entry to load its detail in the main panel. The dashboard auto-selects the active version on load; if no active version exists, it selects the highest-numbered version.

Caution

Selecting an entry here changes only what the page displays. It does not activate that definition for the repository. New issues pin the runtime-resolved workflow, while existing issues retain their pinned version. The current Cloud runtime does not load arbitrary registered YAML through the repository workflow selector as though it were a built-in.

Data source: GET /pipeline/workflow-definitions.

State machine graph

The detail panel opens with a visual graph of the state machine. Each node represents a state; arrows represent valid transitions. The graph is read left-to-right from the intake (initial) state.

The header above the graph shows:

• Workflow name and version — the definition’s display name and integer version.
• Initial state — the state new issues enter when they are first routed into the pipeline.
• Trigger label — the GitHub label that routes new issues into this workflow (if the definition declares one).

States

Below the graph, a table lists every state in the workflow:

Column	Description
State	The state key used internally (for example, analyzing, in-review, done). Matches the state names in pipeline events and metrics.
Label	Human-readable display name shown in the dashboard (falls back to the state key if omitted).
Trait	The behavioral category of the state. One of: Active (work in progress), Blocked (cannot proceed without action), Awaiting human (waiting on a human step such as code review), or Terminal (final — no further transitions).
Executor	The executor that runs the work for this state, if any. See Executors and plugins below. States without executors (for example, purely transitional or manual states) show —.
Transitions	The states this state can transition to. — indicates a terminal state with no outbound transitions.

Data source: GET /pipeline/workflow-definitions/:workflowId?version=<N>.

Executors and plugins

The Executors & Plugins section (below the states table) summarises every executor referenced in the workflow, grouped by type:

Built-in executors (builtin:<name>) are provided by Colony’s core runtime. For example, builtin:review runs the code review step; builtin:merge handles PR merging.

Plugin executors (plugin:<package>/<key>) are provided by Colony plugins. The package name (for example, colony-content) is the npm package that registers the executor; the key (for example, analyze, draft) identifies the specific step within that plugin.

See the Colony plugin docs for how to author and register a plugin executor, and the workflow docs for how states wire together.

Operator actions

The Operator actions section lists every action an operator can trigger manually on issues in this workflow (for example, slash commands or dashboard controls). Each action entry shows:

Field	Description
Name	The action identifier (for example, /colony:reimplement, /colony:clarify).
From	The states the issue must be in for the action to be applicable. If empty, the action is valid from any state.
To	The state the issue moves to after the action runs.
Framework	When shown, indicates this action is a built-in framework action rather than a workflow-specific one.
Description	What the action does.
Side effects	Additional effects beyond the state transition (for example, closing a PR, posting a comment).

---

Strategist and strategy

Strategy (charter, risk envelope, snapshot proposals, and the Strategist cycle) is documented on the dedicated Strategy page.