DOCS · REFERENCE · COMMANDS · SETUP

configure-teams/synthex:configure-teams

Setup

Wizard for standing review pools — enable routing and pick routing and matching modes.

Invocation

Run from inside Claude Code in any project where Synthex is installed:

/synthex:configure-teams

Some commands accept parameters; see the source-of-truth file linked below for the full parameter list and workflow.

Lifecycle phase

Setup. One-time project scaffolding.

No agents declare this command's lifecycle phase. The command runs structurally — delegating to whichever agents the command's workflow names directly.

Source

The command's parameters, workflow, and sub-agent invocations are defined in markdown at bluminal/lumenai/blob/main/plugins/synthex/commands/configure-teams.md.

Last modified:

What it does, end-to-end

configure-teams/synthex:configure-teams is a short wizard for the standing_pools block in .synthex/config.yaml. It asks whether to turn on pool routing, then how routing and matching should behave, and writes your answers. It never starts a pool — that's always your call, via start-review-team/synthex:start-review-team, because a running pool costs tokens for as long as it's alive.

Unlike the other pool commands, it doesn't need Agent Teams. It only writes config, so it runs on any host — a teammate on another tool can set up the shared config even if they'll never run a pool themselves.

It needs an initialized project. If .synthex/config.yaml doesn't exist (and no legacy standing_pools block is found either), it tells you to run init/synthex:init first.

The questions

  1. Enable standing review pools? Enable continues to the next two questions. Skip writes nothing.
  2. Routing mode — what happens when no pool matches:
    • prefer-with-fallback (default) — run the review with fresh reviewers, silently.
    • explicit-pool-required — abort with an error telling you to start a pool.
  3. Matching mode — how closely a pool's roster must fit:
    • covers (default) — the pool includes every reviewer the command needs.
    • exact — the pool's roster is exactly the reviewers the command needs.

It then writes three keys:

standing_pools:
  enabled: true
  routing_mode: prefer-with-fallback
  matching_mode: covers

Other standing_pools keys (default_reviewers, ttl_minutes, default_name, …) are left alone. Edit the config file directly to change them — see Standing review pools.

Re-running it

The wizard is safe to re-run.

  • Never configured, or previously turned off — it runs the questions again, keeping any other standing_pools keys you've set.
  • Already enabled — it shows the current routing and matching modes and offers:
    • Re-run the wizard — answer the questions again.
    • Reset to disabled — set standing_pools.enabled: false and keep the rest of the block. Running pools are left alone; they stop via stop-review-team/synthex:stop-review-team or TTL.
    • Leave as-is — exit without changes.

Coming from synthex-plus

If your project still has a .synthex-plus/ directory, Synthex's session-start upgrade nudge points you here. When standing_pools lives only in the old .synthex-plus/config.yaml, the wizard reads it and treats the run as a re-run. Whatever you choose is written to .synthex/config.yaml — never to the legacy file. Delete .synthex-plus/ once the new block is in place. The migration guide has the full steps.

See also

  • Standing review pools
  • start-review-team/synthex:start-review-team — start a pool once routing is on
  • list-teams/synthex:list-teams — see running pools