Flow catalog

Flow Catalog (/admin/flows) is where curated flow definitions live — the named, reviewed flows your team can run (for example spec-review and code-review). Unlike the dynamic flows bounded by the clamps on Flows, catalog definitions are curated and exempt from those caps. This page is admin-only.

The definition list

Definitions are listed with their Id, current version, reviewer/participants, and an enabled toggle. Built-in and deleted definitions carry a small label marking them as such. The enable toggle is disabled for a deleted definition — restore it first.

Actions

Each row offers:

Enable / disable — a disabled definition stays in the catalog but can’t be run.
History — the version history for the definition.
Load into editor — opens the current YAML in the editor.
Delete / Restore — any definition, built-ins included, can be deleted; a deleted definition can be restored later, and its enable toggle stays disabled until it is.

The YAML editor

New and Edit open the YAML editor. Publishing is keyed by the definition’s id: re-publishing an existing id appends a new version rather than overwriting the old one in place — every prior version stays in History. Server-side validation errors surface inline in the editor. There’s no per-draft “expected version” guard, so if two admins edit the same definition, the later publish simply becomes the newest version; a genuine race on the underlying catalog stream is rejected as a conflict and needs a retry.

Definition shape

A definition is a YAML document. At a high level:

id (required) — must match [a-z0-9-]+.
Participants — either a participants: map of 1–8 roles, or the legacy single-reviewer form with top-level reviewer: and rounds: (never both). Each participant requires a vendor (a known vendor), a model, a workspace, and rounds.initial_prompt + rounds.follow_up_prompt. rounds.result (with findings_marker and clean_marker, which must be distinct) is optional.
Optional sections — limits (max_rounds, round_timeout, idle_ttl, budget_usd), completion.close_on, and mcp.

The built-in spec-review definition, as a worked example:

id: spec-review
reviewer:
  vendor: codex
  model: default
  workspace: mirror-requester
rounds:
  initial_prompt: |-
    Review this spec/design for gaps, ambiguity, risks, missing acceptance criteria, and implementation concerns. You are running inside a checkout of the repository at your working directory; read the relevant source files to ground your review, verifying the spec's assumptions, referenced components, and acceptance criteria against the actual code.
  follow_up_prompt: |-
    Review the updated spec/design. Focus on unresolved or newly introduced findings. Consult the relevant source files in your working directory to ground your review.
  result:
    findings_marker: "FINDINGS:"
    clean_marker: "NO FINDINGS"

Flows — the clamps that bound dynamic (non-catalog) flows.
Review flows — the user-facing feature these definitions drive.