/auto

name: auto
description: "Use when the work spans several files or replaces a framework, language, auth, storage, or API layer (rewrites and migrations included), and the user wants it to end up working and tested. Asks only what is missing, writes a spec with acceptance criteria, then runs and verifies it in the background. Not for questions, small edits, or an existing Seed (use run)."
mcp_tool: ouroboros_start_auto
mcp_args:
  goal: "$goal"
  resume: "$resume"
  cwd: "$CWD"
  max_interview_rounds: "$max_interview_rounds"
  max_repair_rounds: "$max_repair_rounds"
  skip_run: "$skip_run"
  pipeline_timeout_seconds: "$pipeline_timeout_seconds"
  efficiency_mode: "$efficiency_mode"
  frugality_assurance: "$frugality_assurance"

/ouroboros:auto

Run the full-quality auto pipeline from a single task description.

Dispatch requirement

This skill must be executed by invoking MCP tool `ouroboros_start_auto`. Do not manually inspect repositories, run shell commands, query GitHub, edit files, or otherwise emulate the auto pipeline. The background starter returns `job_id` and `auto_session_id` quickly; retain both. If `ouroboros_start_auto` or a required job wait/result tool is unavailable, stop and report that the required MCP tool is unavailable. A manual fallback is not an `ooo auto` run.

If a started auto job returns `detached`, `blocked`, `failed`, or another auto-session status, report that status and the tool's blocker. `detached` is non-terminal tracked background work: surface the job/Ralph handles and keep observing them through the same owner. Do not label a `blocked` or `failed` outcome as MCP dispatch failure; dispatch failure means the MCP tool could not be invoked.

Do not stop after returning the `job_id`: keep the conversational UX, delegate monitoring (below), and never tell the user to call job tools themselves. The user should not have to poll the job manually.

Immediately before each `ouroboros_*` call, load its schema with the active runtime's tool-discovery capability (for example `"+ouroboros auto"` for `ouroboros_start_auto` and `"+ouroboros session signal"` for the Synapse tools); a schema loaded on an earlier turn may be gone. An empty result for an already-callable tool is expected.

Usage

ooo auto "Build a local-first habit tracker CLI"
ooo auto --resume auto_abc123
ooo auto "Build a local-first habit tracker CLI" --skip-run
/ouroboros:auto "Build a local-first habit tracker CLI"

`ooo auto` takes no parent Seed and infers no lineage from goal prose (a Seed named in the goal is ordinary context); never claim preserved lineage or AC edit scope. Use `ooo evolve` for parent evolution or `ooo run` for an existing Seed.

CLI flag → MCP arg translation

Translate CLI-style flags typed in chat before invoking `ouroboros_start_auto`:

| CLI flag | MCP arg | Type | |----------|---------|------| | `--skip-run` | `skip_run=true` | boolean | | `--max-interview-rounds N` | `max_interview_rounds=N` | integer | | `--max-repair-rounds N` | `max_repair_rounds=N` | integer | | `--pipeline-timeout-seconds X` | `pipeline_timeout_seconds=X` | number | | `--efficiency-mode adaptive\|quality_first` | `efficiency_mode=<value>` | string | | `--frugality-assurance off\|observe\|strict` | `frugality_assurance=<value>` | string | | `--resume <id>` | `resume=<id>` | string |

• `--max-generations` belongs to `ooo ralph`, not `ooo auto`.
• `--complete-product` is deprecated and ignored (the run job owns the chain).
• `--pipeline-timeout-seconds` is accepted only on a fresh start; with `--resume` it is rejected because the original deadline is preserved.
• The CLI-only `--show-ledger` flag prints assumptions/non-goals; MCP responses already include that ledger summary when available.

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; relay that line once. If the user did choose, or the config says `ask`, map the choice in outcome language: **Efficient execution** is `adaptive/observe`; **Quality-first execution** is `quality_first/off`. `strict` assurance is a separate explicit opt-in because it may spend extra work on proof; never infer it. On resume, send neither argument; Auto restores the persisted contract.

Behavior

1. Starts an auto session and runs bounded Socratic interview rounds with source-tagged auto answers. 2. Generates a Seed, then reviews and repairs it until it is A-grade (passes the Seed review) or blocked. 3. Starts execution only after A-grade (unless `skip_run`). Auto reaches `COMPLETE` once the run has a durable handle; the run job then carries its own `run → evaluate → ralph` chain under `execution.auto_evaluate` / `execution.auto_evolve` (both default `true`). Auto does not evaluate the run itself. 4. Every loop is bounded and timeouts return a resumable `auto_session_id`: resume with `ooo auto --resume <auto_session_id>`. The chained Ralph is bounded by `execution.auto_evolve_max_generations` (default 3), each generation capped by Ralph's per-iteration timeout, but there is no total wall-clock cap on the chain, and the auto deadline (`--pipeline-timeout-seconds`, CLI `--timeout`) does not bound it.

**Preflight blocker.** `seed_preflight_unexecutable` is a start-new-session boundary, not a `--resume` boundary: the session's Seed is immutable, so use the displayed questions to revise the goal/Seed contract and start a new `ooo auto` session (the blocked one stays for audit). Transient interview, evaluator, or lateral-tool exhaustion is different: resume the same session once the provider is healthy.

Background monitoring

1. **Hand off.** Relay the server's start receipt (handles, runtime/harness, LLM backend, efficiency and fruga