/run

name: ouroboros-run
description: "Use when an Ouroboros Seed (a spec file with a goal and acceptance criteria, such as *.seed.yaml) already exists and the user wants it executed: 'run the seed', 'execute this spec', 'ooo run'. Executes it and verifies every acceptance criterion. Not for raw requests without a Seed (use interview or auto)."
aliases: [execute]
mcp_tool: ouroboros_start_execute_seed
mcp_args:
  seed_path: "$1"
  cwd: "$CWD"

/ouroboros:ouroboros-run

Execute a Seed specification through the Ouroboros workflow engine as a background job. A completed run enqueues formal evaluation by default, and a rejection continues through a bounded Ralph loop.

Usage

/ouroboros:ouroboros-run [seed_file_or_content]

Instructions

Loading MCP tools (deferred-schema guard)

Ouroboros tools may be deferred, and a schema loaded on one turn can unload by the next. Immediately before each `ouroboros_*` call, load it with the active runtime's tool-discovery capability: `"+ouroboros execute"` for `ouroboros_start_execute_seed`, `ouroboros_job_wait`, `ouroboros_job_result`, and `ouroboros_ac_tree_hud`; `"+ouroboros session signal"` for `ouroboros_session_signal_targets` and `ouroboros_session_signal`. A call whose schema is not loaded fails with "Invalid tool parameters". If the tool is already callable, discovery is a no-op and an empty result is expected. Use the **Fallback (No MCP Server)** section only when the tools are genuinely absent.

Execution Steps

1. **Do not create or switch branches yourself.** For a background execution job, `use_worktree` defaults to true: the server runs the task in its own worktree and reports `worktree_path` / `worktree_branch` in the job result. Tell the user the task was isolated only when those fields are present. A `dispatch_mode="plugin"` response delegates to a child session and carries no worktree.

2. **Get the Seed.** Read a given file path with the active runtime's `inspect_code` capability, use inline YAML directly, or otherwise take the most recently generated Seed in the conversation.

Before a fresh start, do not ask about an efficiency policy unless the user raised it or `execution.default_policy` in `~/.ouroboros/config.yaml` is explicitly `ask`. Otherwise omit both arguments: the server applies the configured default (quality-first when nothing is configured), and its start receipt names the running policy and the change command. If the user did choose, or the config says `ask`, map the choice in outcome language:

• **Efficient execution**: start parallel/decomposed work economically and

strengthen the route only when recovery requires it. Send `efficiency_mode="adaptive"` and `frugality_assurance="observe"`.

• **Quality-first execution**: keep child work at the parent starting tier.

Send `efficiency_mode="quality_first"` and `frugality_assurance="off"`.

`frugality_assurance="strict"` is a separate explicit opt-in because it may spend extra work on proof; never infer it from the efficiency choice. Do not ask again on resume: the server restores the persisted policy and rejects a resume-time change.

3. **Start background execution:**

   Tool: ouroboros_start_execute_seed
   Arguments:
     seed_content: <the seed YAML>
     efficiency_mode: <only when chosen: adaptive or quality_first>
     frugality_assurance: <only when chosen: observe, off, or explicit strict>
     session_id: <only when resuming an existing session>

Omit `model_tier` by default so the runtime selects automatically. Include `model_tier: <user choice>` only when the user explicitly requested a tier. The call returns at once with `job_id`, `session_id`, and `execution_id`.

4. **Hand off.** Relay the server's start receipt (IDs, backends, `Efficiency Mode` with any change command, dashboard). Then add:

• Live view: if `execution.tui_autolaunch: true` (or legacy top-level `tui_autolaunch: true`) is set, run `ouroboros tui open`; otherwise offer it once without blocking. If it prints a manual command (headless, SSH), relay that once.
• Observation: a confirmed read-only observer (step 5), or durable catch-up mode.
• This conversation stays available: the user can refine requirements, review code, or work on an unrelated task in an isolated worktree; check for active-worker conflicts before editing this run's workspace.

5. **Delegate observation to exactly one observer.** The start result carries `response.meta.job_observer`, a read-only observer contract with its own wait and result tools, `instructions`, `restrictions`, and fallback. If the structured meta is missing, recover the contract from the final `<!-- ouroboros-job-observer-v1 base64 ... -->` content sentinel and fail closed: if there is more than one sentinel or it is not at the end of the text, the bounded payload does not decode to an object whose only key is `job_observer`, that contract fails canonical v1 validation (it must equal, field for field, the v1 contract the server builds from its own `job_id`, `cursor`, `session_id`, `execution_id`, and `follow_result_job_keys`, so a changed tool, argument, or instruction, or an extra field, fails), its `job_id` differs from the visible start receipt, or the structured and inline contracts differ, do not spawn an observer and report a transport-integrity failure. Never rebuild the contract from visible IDs.

With a valid contract and an independent child-session primitive, spawn exactly one observer through the active runtime's `orchestrate_subagents` capability and pass the contract unchanged. It owns the job cursor, follows the contract (including `follow_result_job_keys` for chained evaluation and Ralph), and stays read-only. Claim an observer only after the spawn returns a live child ID/path. The main session must not poll the same job while the observer owns it. If plugin mode