auto

Files (1)

• SKILL.md

SKILL.md (first lines)

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

```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` 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 frugality settings). Show
   `response.meta.dashboard_url` when present, otherwise mention
   `ouroboros tui open` once. Say this conversation stays available for
   refinement, read-only review, explicit control, or unrelated work in an
   isolated worktree; check for overlap with worker files before writing to
   the active auto workspace.

2. **Delegate to exactly one observer.** The start result carries
   `response.meta.job_observer`, a read-only observer contract. If the
   structured meta is missing, recover it from the final
   `<!-- ouroboros-job-observer-v1 base64 ... -->` content sentinel and fail
   closed unless all of these hold: exactly one sentinel, at the end of the
   text; the bounded payload decodes to an object whose only key is
   `job_observer`; that contract passes canonical v1 validation (it equals,
   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/session identity matches the visible start receipt; and it does not
   differ from any structured contract. 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 cursor, waits until
   terminal, fetches the result, and follows the IDs named by
   `follow_result_job_keys`; it must not edit files, control execution, or spawn
   workers. Claim an observer only after the spawn returns a live child ID. The
   main session must not poll the same job.

   - A `wait` call or a parent job-status poll is not a spawn. The contract's
     `host_lifecycle` and the runtime's `orchestrate_subagents` guidance name
     the concrete spawn and wait mechanics. Once acknowledged, if the runtime

From Q00/ouroboros, MIT.

More from Q00/ouroboros