| name | ouroboros-config |
| description | Open or drive the Ouroboros settings GUI (browser, TUI, or conversational fallback) |
/ouroboros:ouroboros-config
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)
-
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.
-
Relay the http://localhost:<port> line from the output so the user can
open it manually if the browser did not pop up.
-
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:
-
Show the current state:
ouroboros config show
-
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.
-
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>
ouroboros config set execution.default_model <model>
ouroboros config set evaluation.semantic_model <model>
ouroboros config set resilience.reflect_model <model>
ouroboros config set llm.backend <backend>
-
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.