Flow catalog

Open Flows → Flow Catalog (/admin/flows) to manage named YAML definitions that agents can start. Built-in definitions such as spec-review and code-review are listed alongside your own. Curated definitions are exempt from the dynamic-flow clamp profile.

Select or create a definition

The Definitions table shows ID, version, reviewer choice, enabled state, and built-in or deleted badges. Select a row to load its YAML and Version history. A reviewer shown as requester chooses leaves vendor selection to the caller.

Use New definition to start a draft. The editor validates YAML against the server’s definition format and shows validation errors. Publish creates the first version of a new ID or appends a new version of an existing ID.

Select an entry in Version history to load it into the editor. Publishing that text creates a new current version; old versions remain available.

Enable, delete, and restore

The Enabled switch controls whether a catalog definition can start new runs. Delete soft-deletes a definition, including a built-in one. Restore brings it back. A deleted definition’s enabled switch stays disabled until restoration.

Agents discover what they can run through the list_flow_definitions tool, which returns each enabled definition’s ID, version, description, and participants’ roles, vendors, and models. Disabled and deleted definitions are not listed, and prompts are never returned. Write the definition’s description for an agent choosing between flows.

Catalog publication does not provide a draft-level expected-version lock. Coordinate edits when several admins work on the same definition: a later successful publication becomes the newest version. A concurrent write conflict requires refreshing and retrying.

YAML structure

A definition has an id matching [a-z0-9-]+, an optional description, and either:

• reviewer: plus top-level rounds: for a single reviewer; or
• participants: with 1–8 named roles, each containing its own rounds:.

Do not mix these forms. Each role needs non-empty initial_prompt and follow_up_prompt. A multi-participant definition requires a known vendor for every role. A single-reviewer catalog definition can omit vendor and model so the requester chooses; model: default uses the agent’s default. workspace accepts none or mirror-requester.

Optional rounds.result markers identify findings and clean results; findings_marker and clean_marker must differ. Definitions can also include limits (max_rounds, round_timeout, idle_ttl, budget_usd), completion.close_on, and mcp. Duration values use units such as 30s, 10m, or 2h.

When a review can run without a checkout, supply initial_prompt_context_only and follow_up_prompt_context_only as well. They tell the reviewer to evaluate the submitted context without trying to read repository files.

Example

This single-reviewer catalog definition leaves vendor and model selection to the requester:

id: design-review
description: Review a design document for missing requirements and implementation risks.
reviewer:
  workspace: mirror-requester
rounds:
  initial_prompt: |-
    Review the submitted design for missing requirements and implementation risks.
    Read the relevant repository files to verify its assumptions.
  follow_up_prompt: |-
    Review the updated design and report unresolved or new findings.
  initial_prompt_context_only: |-
    Review the submitted design using only the supplied context.
    State which assumptions you could not verify without repository access.
  follow_up_prompt_context_only: |-
    Review the updated design using only the supplied context.
    Report unresolved or new findings.
  result:
    findings_marker: "FINDINGS:"
    clean_marker: "NO FINDINGS"

See Review flows for the user workflow and Flows for launch policy and dynamic limits.