Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →Automatically converge from goal to A-grade Seed and execute it
| Test case | Without → With | Effect | Δ tokens | Δ turns |
|---|---|---|---|---|
| case-04 | ✗→✓ | ▲ Improved | 109% | 0% |
| case-05 | ✗→✓ | ▲ Improved | 410% | 0% |
| case-06 | ✗→✓ | ▲ Improved | 33% | 0% |
| case-13 | ✗→✓ | ▲ Improved | 218% | 0% |
| case-17 | ✗→✓ | ▲ Improved | 488% | 0% |
Run the full-quality auto pipeline from a single task description.
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.
If ouroboros_start_auto is unavailable, stop and report that the required MCP tool is unavailable. A manual fallback is not an ooo auto run.
If ouroboros_start_auto is invoked successfully but returns blocked, failed, or another terminal auto-session status, report that auto-session status and the tool's blocker. Do not label that outcome as MCP dispatch failure; dispatch failure means the MCP tool could not be invoked.
textooo 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"
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 start with no user choice, 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 separate explicit consent because it may spend extra work on proof. Do not send these arguments on resume; the server restores the persisted contract.
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.During an executing auto run, additive human intent is routed by the main session: reload deferred schemas with tool discovery query: "+ouroboros session signal", call ouroboros_session_signal_targets with the observed execution ID, match the intent to live AC content, and send the selected exact target through ouroboros_session_signal. Never ask the human for internal IDs. Ask only when multiple candidates remain genuinely tied, and do not route shared contract changes to one AC.
After a start response, show dashboard_url when present or mention ouroboros tui open once. Include the returned runtime/LLM backends, efficiency mode, and frugality assurance. Say that the exact active model and execution plan will arrive from configuration/routing events rather than guessing.
If response.meta.job_observer is unavailable, recover it from the final <!-- ouroboros-job-observer-v1 base64 ... --> content sentinel. Fail closed unless the single bounded payload passes canonical v1 validation and its job/ session identity matches the visible start receipt. Visible IDs are identity anchors only; never reconstruct tools or arguments from them.
When a structured or validated recovered job_observer is present and a Task/Agent child exists, spawn exactly one read-only observer and pass the contract unchanged. It owns wait/result and the cursor exclusively. The main session must not poll the same job. Keep the conversation available for read-only review, explicit control, or unrelated work in an isolated worktree. Check active-worker overlap before writing to the Auto workspace. Without a child, use the declared linked ouroboros_job_wait fallback and never run both owners. Do not claim an observer until Task/Agent returns a live child handle. If child creation succeeds on Codex, keep the parent turn open with wait_agent calls of at most 60 seconds until the observer returns its terminal summary. Child send_message calls only queue mailbox events and cannot revive an ended parent turn. Relay meaningful updates, handle user input if it interrupts the wait, and resume waiting while the observer is active unless the user asks to stop live observation or replaces the active request. Then end only the relay loop, keep the durable job running, and offer next-turn or explicit-status catch-up. If the observer child fails, is cancelled, or exits before a terminal summary, use that same fallback instead of waiting indefinitely. This relay loop must not poll the job or take cursor ownership. If child creation fails, do not promise live proactive relays. The detached worker survives the stdio turn; catch up from durable events on the next parent turn or explicit status request. Keep the fallback polling loop open only for explicit live watching.
Relay only structured changes:
run_configuration: current runtime/harness, starting model/tier when known,efficiency mode, and frugality assurance.
execution_plan: total ACs, total dependency/parallel levels, parallelism, andfirst scheduled AC summaries.
discovery_summary: bounded targets and purpose, never raw commands orreasoning.
attention_required: surface immediately.queued/delivering is pending, not applied;applied/completed is runtime-proven and may carry a bounded AC reply; rejected/uncertain delivery is surfaced immediately.
For additive refinements send exact guards with contract_effect="additive", source="user", mode="redirect", and explicit fallback_mode="after_turn". Use mode="inform" for a read-only AC question or assurance request and omit fallback_mode entirely in that mode. Never ask for internal IDs; semantically choose the relevant target and ask only on a genuine tie.
For conductor attention, use at most one short-lived read-only verifier. If the host cannot verify, do not ACT. Otherwise VERIFY → DECIDE from the ordered recommended_host_actions → LOG selected with ouroboros_record_conductor_decision → ACT only a menu-listed registered tool → LOG completed, failed, or declined. Auto may run only one bounded deterministic non-relaxing successor and never changes the approved shared contract itself.
These are English canonical instructions. Phrase them naturally in the user's current conversation language.
| Layer | Code | Surface | Meaning | |---|---|---|---| | Interview | interview_max_rounds_exhausted | last_error_code, result.stop_reason_code | Auto interview ran max_interview_rounds without ledger+backend mutual closure, no section was safely defaultable, and no partial defaults applied — i.e. genuine deadlock with nothing the policy could close. | | Interview | interview_unsafe_gaps_remain | last_error_code, result.stop_reason_code | Auto interview ran max_interview_rounds with at least one section safely defaultable and at least one section remaining unsafe (e.g. CONFLICTING ledger entry, production/credential context). Partial defaults are rolled back so the persisted transcript and ledger stay aligned; resume can address the unsafe gap and re-run. | | Interview | interview_phase_deadline | last_error_code, result.stop_reason_code | Interview phase exceeded its per-phase timeout. | | Ralph | iteration_timeout | blocker text + (future) result.stop_reason_code | A single Ralph iteration exceeded its per-iteration timeout. | | Ralph | wall_clock_exhausted | blocker text + (future) result.stop_reason_code | The Ralph wall-clock budget was exhausted before convergence. | | Ralph | oscillation_detected | blocker text + (future) result.stop_reason_code | Ralph oscillated between two grade states without making progress. | | Ralph | grade_regressing | blocker text + (future) result.stop_reason_code | A subsequent Ralph generation produced a strictly worse grade than its predecessor. | | Ralph | max_generations reached | blocker text + (future) result.stop_reason_code | Ralph hit its configured generation cap before reaching A grade. |
Blockers without a canonical code keep using the free-form last_error text. Ralph-layer codes are surfaced via blocker text today; their result-envelope promotion is tracked as a follow-up.
When result.status == "seed_ready", result.interview_closure_mode distinguishes how the interview was closed:
| Value | Meaning | |---|---| | None | Mutual agreement — both the backend and the ledger declared the seed ready in the same round. The default healthy path. | | "ledger_only" | PR-B1 / #1148: max_rounds hit; the ledger was structurally complete but the backend refused to declare closure. The interview closes on ledger-only consensus. Defaulted sections (if any) are tagged in result.defaulted_sections. | | "safe_default" | PR-B2: max_rounds hit; the safe-default policy successfully filled every remaining required gap with auditable assumptions. Synthesis was pushed back into the persisted transcript so the seed generator sees the same assumptions the ledger records. Defaulted sections are tagged in result.defaulted_sections. |
Genuine-deadlock and partial-unsafe outcomes do not set interview_closure_mode; they reach a blocked terminal with the matching stop_reason_code above instead.
result.assumptions: tuple[str, ...] (the existing list of assumption texts) is now accompanied by result.assumption_sources: tuple[AssumptionRecord, ...], where each AssumptionRecord is a frozen dataclass with:
| Field | Type | Meaning | |---|---|---| | text | str | The assumption text (same surface as the corresponding assumptions entry where present). | | source | str | One of "assumption" (auto-answerer fallback), "inference" (model reasoning), "conservative_default" (safe-default policy). These are the three assumption-class LedgerSource values that produce assumption_only_sections. | | confidence | float | Per-entry confidence as recorded by the ledger. |
assumption_sources is a broader surface than assumptions — it includes inference- and conservative-default-class entries that assumptions (filtered to LedgerSource.ASSUMPTION only) does not surface. Callers wanting to know which assumptions the system made on the user's behalf should read assumption_sources; callers preserving the older string-only contract continue to read assumptions.
The pipeline must not hang indefinitely: all loops are bounded and timeout failures return a resumable auto_session_id. Resume with ooo auto --resume <auto_session_id>. Use --skip-run to stop after the A-grade Seed. Use --complete-product to drive the full Interview → Seed → Run → Ralph → Product chain on a single ooo auto invocation; the chained Ralph loop honors the same wall-clock deadline as the parent auto session (--timeout). The CLI-only --show-ledger flag prints assumptions/non-goals; MCP skill responses already include the same ledger summary when available.
| Case | Status | Duration (ms) | Turns | Tokens | Tool calls | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Without | With | Δ | Without | With | Δ | Without | With | Δ | Without | With | Δ | ||
case-01 | fail→fail | 8,170 | 19,962 | +144% | 1 | 1 | 0% | 413 | 3,666 | +788% | 0 | 0 | — |
case-02 | fail→fail | 9,839 | 5,456 | -45% | 1 | 1 | 0% | 882 | 3,441 | +290% | 0 | 0 | — |
case-03 | fail→fail | 19,352 | 5,667 | -71% | 1 | 1 | 0% | 3,887 | 4,097 | +5% | 0 | 0 | — |
case-04 | fail→pass | 12,642 | 3,446 | -73% | 1 | 1 | 0% | 1,754 | 3,658 | +109% | 0 | 0 | — |
case-05 | fail→pass | 4,216 | 3,631 | -14% | 1 | 1 | 0% | 726 | 3,704 | +410% | 0 | 0 | — |
case-06 | fail→pass | 13,762 | 2,422 | -82% | 1 | 1 | 0% | 2,680 | 3,567 | +33% | 0 | 0 | — |
case-07 | pass→pass | 3,871 | 3,224 | -17% | 1 | 1 | 0% | 577 | 3,542 | +514% | 0 | 0 | — |
case-08 | pass→fail | 5,108 | 5,595 | +10% | 1 | 1 | 0% | 1,005 | 4,207 | +319% | 0 | 0 | — |
case-09 | pass→pass | 4,732 | 2,528 | -47% | 1 | 1 | 0% | 684 | 3,597 | +426% | 0 | 0 | — |
case-10 | pass→fail | 6,384 | 4,279 | -33% | 1 | 1 | 0% | 1,160 | 3,930 | +239% | 0 | 0 | — |
case-11 | pass→fail | 3,321 | 5,816 | +75% | 1 | 1 | 0% | 601 | 4,294 | +614% | 0 | 0 | — |
case-12 | fail→fail | 8,661 | 3,240 | -63% | 1 | 1 | 0% | 1,304 | 3,583 | +175% | 0 | 0 | — |
case-13 | fail→pass | 7,878 | 5,534 | -30% | 1 | 1 | 0% | 1,290 | 4,099 | +218% | 0 | 0 | — |
case-14 | pass→pass | 9,335 | 2,375 | -75% | 1 | 1 | 0% | 1,307 | 3,438 | +163% | 0 | 0 | — |
case-15 | fail→fail | 6,254 | 6,753 | +8% | 1 | 1 | 0% | 1,180 | 4,066 | +245% | 0 | 0 | — |
case-16 | pass→pass | 6,269 | 4,383 | -30% | 1 | 1 | 0% | 862 | 3,761 | +336% | 0 | 0 | — |
case-17 | fail→pass | 3,344 | 4,110 | +23% | 1 | 1 | 0% | 623 | 3,662 | +488% | 0 | 0 | — |
case-18 | pass→pass | 17,618 | 3,243 | -82% | 1 | 1 | 0% | 2,958 | 3,484 | +18% | 0 | 0 | — |
case-19 | fail→pass | 10,305 | 2,226 | -78% | 1 | 1 | 0% | 1,456 | 3,410 | +134% | 0 | 0 | — |
case-20 | pass→pass | 6,481 | 4,850 | -25% | 1 | 1 | 0% | 1,023 | 3,847 | +276% | 0 | 0 | — |
case-21 | pass→pass | 10,851 | 10,360 | -5% | 1 | 1 | 0% | 1,905 | 4,922 | +158% | 0 | 0 | — |
case-22 | fail→pass | 9,362 | 10,174 | +9% | 1 | 1 | 0% | 1,313 | 4,928 | +275% | 0 | 0 | — |
DecimalAI ran this skill against gemini-3.6-flash twice over the same eval suite — once with the skill loaded and once without — and compared the two runs case by case. 22 cases were attempted, and 20 counted toward the lift figure. The other 2 produced results that are not comparable between the two arms, so they are excluded from the headline rather than averaged into it. The headline lift of +18 percentage points is the difference between those two pass rates over the 20 comparable cases. 3 cases got worse with the skill loaded, and they are included in that figure.
Without the skill loaded, the model failed this case. With it loaded, the same prompt on the same model passed. This is one improved case from the latest verified run; every case, including any that regressed, is in the table above.
Other measured skills in the registry, with their headline benchmark lift.