/auto

name: auto
description: "Automatically converge from goal to A-grade Seed and execute it"
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"
  complete_product: "$complete_product"
  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 as a substitute. Full auto runs routinely exceed interactive MCP tool-call timeouts, so the background starter is the supported default: it returns `job_id` and `auto_session_id` quickly. Retain both. When `response.meta.job_observer` is present, delegate its read-only wait/result contract to exactly one independent child session. The main session keeps only start and explicit on-demand status responsibility.

If `ouroboros_start_auto` is unavailable, or if any required job polling/result MCP 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 later returns `detached`, `blocked`, `failed`, or another auto-session status, report that auto-session 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.

If the active runtime routes `ooo auto` through a background starter such as `ouroboros_start_auto`, do not stop after returning the `job_id`. Keep ownership of the conversational UX: retain the returned `job_id`, `auto_session_id`, and cursor, then delegate monitoring when the host supports child sessions. Only the fallback path monitors with `ouroboros_job_wait` / `ouroboros_job_status` in the main session. The user should not have to poll the job manually.

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
ooo auto "Build a local-first habit tracker CLI" --complete-product
/ouroboros:auto "Build a local-first habit tracker CLI"

`ooo auto` does not accept a parent Seed ID/path or infer lineage from goal prose. Mentioning an existing Seed in the goal is ordinary context, not an authorized derivative operation. Use `ooo evolve` for typed parent evolution, or `ooo run` to execute an existing immutable Seed. Do not claim preserved lineage or AC edit scope from an `ooo auto` goal alone.

CLI flag → MCP arg translation

When the user types `ooo auto` with CLI-style flags inside chat, translate to MCP arguments before invoking `ouroboros_start_auto`:

| CLI flag | MCP arg | Type | |----------|---------|------| | `--complete-product` | `complete_product=true` | boolean | | `--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` is **not** a flag for `ooo auto`; it belongs to `ooo ralph`. When `complete_product=true`, the chained Ralph uses its built-in default (10 generations) bounded by `pipeline_timeout_seconds` or Ralph's own per-iteration / wall-clock budgets.

`--pipeline-timeout-seconds` is accepted only when starting a session. Passing it with `--resume` is rejected because the original deadline is preserved across process restarts.

Before a fresh Auto start, if the user did not already choose an efficiency policy, ask in outcome language: **Efficient execution** maps to `adaptive/observe`; **Quality-first execution** maps to `quality_first/off`. `strict` assurance is a separate explicit opt-in because it may spend extra work on proof. Never infer strict from the efficiency choice. On resume, do not ask or send either argument; Auto restores the persisted contract.

Behavior

1. Starts an auto session. 2. Runs bounded Socratic interview rounds with source-tagged auto answers. 3. Generates a Seed. 4. Reviews and repairs until A-grade or blocked. 5. Starts execution only after A-grade. 6. When `complete_product=true`, chains RUN → RALPH_HANDOFF after a successful run handoff and waits for a terminal Ralph status so a single invocation iterates Ralph until QA passes, convergence, or a budget bound trips. A QA-pass on the executed product completes the auto session; recognized failure modes (`iteration_timeout`, `wall_clock_exhausted`, `oscillation_detected`, `grade_regressing`, `max_generations reached`) block the auto session with the matching `stop_reason` in `last_error` so operators can resume after the cause is addressed.

Background monitoring UX

When an auto start response includes `response.meta.job_id`:

1. Briefly acknowledge that auto started and keep the handles in local state: `job_id`, `auto_session_id` / `session_id`, and `cursor` from `response.meta` if present. Show `response.meta.dashboard_url` when available; otherwise mention `ouroboros tui open` once as the live view. Tell the user that an observer will post meaningful progress/attention/completion events here and that this conversation remains available for requirement refinement, read-only inspection/review, explicit control, or unrelated isolated work. In