/ouroboros:ouroboros-config

SkillWeb & browsing

Lets your agent open and adjust the Ouroboros settings screen in a browser, terminal, or chat.

Available today. Use it from your connected AI after setup.

Connect ahel once, and every AI you use reads what you have installed.

Then ask your AI: use the /ouroboros:ouroboros-config skill

About this capability

Open or drive the Ouroboros settings GUI (browser, TUI, or conversational fallback)

What this skill tells your AI

The instructions your AI receives, as published by q00/ouroboros in skills/config/SKILL.md and read by ahel’s review.

Settings for ~/.ouroboros/config.yaml: per-stage runtime/model selects, global runtime + LLM backend, install badges for missing CLIs, and env-override warnings.

Usage

ooo config
/ouroboros:ouroboros-config

Trigger keywords: "ooo config", "open settings", "configure ouroboros", "change model", "change agent"

Instructions

Pick the branch that matches where you (the agent) are running. The decisive question: can the user open a browser pointed at this machine?

Branch A — local harness (Claude Code / Codex on the user's own machine)

  1. Launch in the background (the command serves until stopped):

    if command -v ouroboros >/dev/null 2>&1; then
      ouroboros config
    else
      uvx --python '>=3.12' --from 'ouroboros-ai[tui]' ouroboros config
    fi
    

    The command detects the non-interactive context itself and serves the settings app over a local web server, auto-opening the user's browser. The uvx fallback is required for a Marketplace-plugin-only install, where the MCP server exists but ouroboros is not on PATH. In a development checkout use uv run ouroboros config.

  2. Relay the http://localhost:<port> line from the output so the user can open it manually if the browser did not pop up.

  3. Tell the user: edit → Save → then ask you to stop the server. Remind them a running MCP server may need a reconnect to pick up backend changes. Tell them they can reopen these settings any time with ooo config; saving a model choice never locks it permanently.

Branch B — remote host the user can reach over the network (SSH box, home server)

The user cannot see a browser opened here, but may be able to reach this host. Serve without auto-open and hand over the URL:

ouroboros config --web --host 0.0.0.0 --no-browser

Relay the printed URL with this host's address substituted, plus the SSH tunnel fallback the command prints (ssh -L <port>:localhost:<port> <this-host>).

Branch C — chat gateway, no browser path at all (e.g. hermes driven from Discord)

Do NOT start a server nobody can reach. Drive the same settings conversationally over the scriptable surface:

  1. Show the current state:

    ouroboros config show
    
  2. Present the user a short menu in chat — default agent, per-stage agents, per-stage models — with the current values, and ask what to change.

  3. Apply each choice with the validated setter (same write path as the GUI):

    ouroboros config set orchestrator.runtime_backend <agent>
    ouroboros config set orchestrator.runtime_profile.stages.<interview|execute|evaluate|reflect> <agent>
    ouroboros config set clarification.default_model <model>        # interview & seed
    ouroboros config set execution.default_model <model>            # execute
    ouroboros config set evaluation.semantic_model <model>          # evaluate
    ouroboros config set resilience.reflect_model <model>           # reflect
    ouroboros config set llm.backend <backend>                      # internal LLM calls
    
  4. Confirm with ouroboros config show and summarize what changed.

If a set is rejected, relay the validation error verbatim — it lists the valid keys/values.

All branches

If the command fails with a missing-dependency hint, relay it verbatim (pip install 'ouroboros-ai[tui]'). Scriptable edits always remain on ouroboros config show|set|backend|init|validate.

End your final message with the state breadcrumb footer (RFC #1392), e.g.:

◆ Settings GUI serving at <url> → next: Save in browser, then stop the server
◆ Config updated via chat (<keys>) → next: reconnect MCP if the backend changed

RFC #1392 State Breadcrumb Footer

Your final response MUST end with exactly one breadcrumb footer line:

◆ <current state> → next: <recommended action>

Derive <current state> from live session state via ouroboros_session_status when that MCP projection is available; otherwise derive it from this skill's actual outcome. Never use a linear Step N of M footer because Ouroboros is an evolutionary loop. When the next action is genuinely a choice, list 2-3 honest options in the next: clause. The breadcrumb line must be the last line of the response.

Signals

GitHub stars
6k
Forks
594
Last commit
Sep 2026
Advanced
Catalog kind
skill
Gateway key
ouroboros-config
Source
github.com/q00/ouroboros