Skip to content
cccskills
FreePublished on GitHub

auto

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).

The English summary is being prepared. Showing the original description.

See how to install

Files included (1)

  • SKILL.md13.3 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

/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 flagMCP argType
--skip-runskip_run=trueboolean
--max-interview-rounds Nmax_interview_rounds=Ninteger
--max-repair-rounds Nmax_repair_rounds=Ninteger
--pipeline-timeout-seconds Xpipeline_timeout_seconds=Xnumber
--efficiency-mode adaptive|quality_firstefficiency_mode=<value>string
--frugality-assurance off|observe|strictfrugality_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 cannot wake a parent turn that already ended when the child posts (a child message only queues for the parent), keep the parent turn open with the host's child-wait primitive in waits of at most 60 seconds. Relay meaningful updates and wait again until the terminal summary. User input may interrupt the wait; handle it and resume unless the user asks to stop live observation or replaces the 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 early, use that same catch-up instead of waiting indefinitely. The relay loop must not poll job tools or take cursor ownership.

    If spawn fails, do not promise live relays. The detached worker continues after the stdio turn; say durable progress will be caught up next turn or on an explicit status request.

    If response.meta.status == "delegated_to_plugin" and job_id is None, plugin mode delegated the work to a child session: follow that session's lifecycle and do not call job tools without a real job id.

  3. Relay events in at most 1-2 lines, suppressing heartbeats, raw tool output, commands, and reasoning. run_configuration reports runtime/harness/model policy; execution_plan reports total ACs, dependency/parallel levels, and the first scheduled ACs; discovery_summary reports bounded targets and purpose; other execution subtypes (ac_routing, ac_attempt_judged, ac_accepted/ac_rejected, level and harness changes) only when material. For Synapse events, distinguish queued/delivering from applied/completed, and surface rejected/delivery_uncertain and attention_required at once. English is the canonical instruction language; render facts naturally in the user's current conversation language.

  4. Interview Q&A. While the phase is interview (for example interview round N/50), call ouroboros_session_status(session_id=<auto_session_id>) and relay the current meta.pending_question plus newly answered meta.auto_answer_log entries ({round, source, question, answer}; source is conservative_default, inference, or assumption), not a bare counter. This Q&A lives in the auto-session state, so ouroboros_query_events returns nothing for it; status shows only the last 3 answers, truncated.

  5. Fallback. Only when no child session exists and the user asked to keep watching this turn, loop on ouroboros_job_wait(job_id=<job_id>, cursor=<cursor>, timeout_seconds=180, view="summary", stream="linked", wait_for="attention_or_ac_change"), replacing the cursor from response.meta.cursor each time, treating response.meta as the source of truth, and staying silent when response.meta.changed is false. Otherwise end the turn and resume from the durable cursor next interaction. Keep waiting while the status is non-terminal.

  6. Result. At terminal status the polling owner calls ouroboros_job_result(job_id) and summarizes the auto-session outcome. A detached result is not completion: keep tracking its downstream job/Ralph handles. Report stop_reason_code (or the free-form last_error blocker) verbatim. For seed_ready, summarize interview_closure_mode (None = backend and ledger agreed; ledger_only or safe_default = closed at the round cap, with defaulted_sections) and the assumption_sources entries (each with text, source, confidence; broader than assumptions).

Synapse intent refinement

Synapse is the ouroboros_session_signal channel that delivers bounded user intent to one running AC. When the user adds implementation intent during an executing auto run, call ouroboros_session_signal_targets with the observed execution_id, select the AC whose ac_content and current activity match, and send ouroboros_session_signal with that target's exact IDs. Never ask the user for internal IDs; ask a short clarification only when live ACs remain genuinely tied. Send additive refinements with contract_effect="additive", source="user", mode="redirect", and fallback_mode="after_turn". For a read-only AC question or assurance request use mode="inform", omit fallback_mode, and relay the bounded reply from the completed event. Never route shared goal/AC/constraint changes to one worker.

Active Conductor decision policy

For attention_required, treat recommended_host_actions as authoritative:

  1. VERIFY with at most one short-lived read-only host child. If unavailable, surface the evidence and stop before mutation.
  2. DECIDE from the ordered menu only after engine ownership is closed.
  3. LOG selected with ouroboros_record_conductor_decision before ACT.
  4. ACT only a menu-listed registered tool. Auto may start at most one bounded deterministic, non-relaxing successor for that attention event and must pass the audited directive/decision/predecessor receipts exactly.
  5. LOG exactly one terminal completed, failed, or declined result. Do not silently retry. Escalate any specification-changing proposal to the user; Auto never relaxes the approved goal, ACs, constraints, or non-goals itself.

RFC #1392 State Breadcrumb Footer

End the final response with exactly one line ◆ <current state> → next: <recommended action>. Derive the state from live session state via ouroboros_session_status when available, otherwise from this skill's actual outcome. Never use a linear Step N of M footer; when the next step is a real choice, list 2-3 options.

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

Scan and manage brownfield repository/worktree defaults for interviews

The English summary is being prepared. Showing the original description.

Q00/ouroboros6.2KUpdated Oct 18, 2026

cancel

Free

Cancel stuck or orphaned executions

The English summary is being prepared. Showing the original description.

Q00/ouroboros6.2KUpdated Oct 18, 2026

Use when the user wants proof that finished work meets its acceptance criteria, not just that tests pass: 'verify it is actually done', 'check it against the spec', 'evaluate the run'. Runs mechanical checks, a semantic review per criterion, and multi-model consensus when uncertain. With execution.auto_evolve on (the default), a rejected result with a Seed continues into a Ralph fix loop; pass auto_evolve: false to verify only.

The English summary is being prepared. Showing the original description.

Q00/ouroboros6.2KUpdated Oct 18, 2026

evolve

Free

Start or monitor an evolutionary development loop

The English summary is being prepared. Showing the original description.

Q00/ouroboros6.2KUpdated Oct 18, 2026

Use when the user wants to build or change something but the request is vague or open-ended: 'help me figure out what to build', 'I'm not sure what it should do', 'add X' with no details, or no clear definition of done. Runs a short Socratic interview that turns the idea into goals, constraints, and acceptance criteria before any code is written. Not for simple questions, small clear edits, or an existing Seed.

The English summary is being prepared. Showing the original description.

Q00/ouroboros6.2KUpdated Oct 18, 2026

Triage and work through Ouroboros GitHub issues and pull requests as a maintainer. Use for `ooo maintain`, backlog cleanup, review, merge readiness, duplicate PRs, and issue disposition.

The English summary is being prepared. Showing the original description.

Q00/ouroboros6.2KUpdated Oct 18, 2026

See all skills by Q00

Report a problem with this skill