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.

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-]+ 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
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.