auto

# /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

```text
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` 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 |
|----------|---------|------|
| `--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`. The chained Ralph started by the run job is bounded by `execution.auto_evolve_max_generations`.

`--complete-product` is deprecated and ignored: the run job owns `run → evaluate → ralph`, so a single Auto invocation no longer drives Ralph itself. Follow the run job's chain with `ooo status` or the job tools.

`--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, first check the persistent default: when `execution.default_policy` in
`~/.ouroboros/config.yaml` is `efficient` or `quality_first`, do not ask — omit
both arguments and the server applies the configured default (the handoff still
reports the resolved policy). Otherwise 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. Auto reaches `COMPLETE` as soon as the run has a durable handle. The run keeps going as a background job, and that job carries its own `run → evaluate → ralph` chain governed by `execution.auto_evaluate` / `execution.auto_evolve` (both default `true`, Ralph bounded by `execution.auto_evolve_max_generations`). Auto does not evaluate the run itself; the chained evaluate job does.

### Preflight blockers and recovery

`seed_preflight_unexecutable` is a start-new-session boundary, not a plain
`--resume` boundary. The persisted Seed artifact is immutable for that
session, so answering an open question cannot silently replace the artifact.
Use the displayed questions to revise the goal/Seed contract, then start a
new `ooo auto` session; the blocked session remains available for audit.

Transient interview, evaluator, and lateral-tool exhaustion is different: its
resume capability is durable and can be retried with the same session after
the external dependency or provider is healthy again. Do not treat a
`seed_preflight_unexecutable` status as a retryable provider outage.

## 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 availabl