Start and monitor an Ouroboros development loop that revises project concepts and acceptance criteria, the conditions for judging completion. Run and evaluate successive generations, focus revisions on failed criteria, inspect progress, or rewind to an earlier generation.
Start or monitor an evolutionary development loop
Review the instructions the agent will receive before you install.
Start, monitor, or rewind an evolutionary loop that refines the ontology and acceptance criteria across generations.
Gen 1: Seed → Execute(all ACs) → Judge → Gate
Gen 2+: Wonder(failed ACs) → Reflect(active ACs only) → Execute(active) → Gate(all)
...until the gate passes, the loop stagnates, or 30 generations are reached
ooo evolve "build a task management CLI" # start
ooo evolve "build a task management CLI" --no-execute # ontology-only (fast)
ooo evolve --status <lineage_id> # lineage status
ooo evolve --rewind <lineage_id> <generation_number> # rewind
Ouroboros tools may be deferred, and a schema loaded on one turn can unload by the next. Immediately before each ouroboros_* call, load it with the active runtime's tool-discovery capability: "+ouroboros evolve" for ouroboros_evolve_step, ouroboros_lineage_status, and ouroboros_evolve_rewind; "+ouroboros interview" for ouroboros_interview; "+ouroboros seed" for ouroboros_generate_seed; "+ouroboros lateral" for ouroboros_lateral_think. A call whose schema is not loaded fails with "Invalid tool parameters". If the tool is already callable, discovery is a no-op and an empty result is expected. Use the fallback only when the tool is genuinely absent.
ouroboros_interview with the user's input as initial_context, until ambiguity ≤ 0.2.ouroboros_generate_seed with the interview session_id.ouroboros_evolve_step with a new lineage_id (e.g. lin_<seed_id>), seed_content (the Seed YAML), and execute (true by default for Execute→Evaluate each generation; false for --no-execute). Generation 2+ calls pass only lineage_id. Each call runs exactly one generation; state is rebuilt from events between calls.action:
continue: inspect active_ac_indices, then call again with lineage_id. Only failed or reopened ACs evolve; frozen PASS ACs are reverified, not regenerated.ontology_stable: not success. Call again for the same lineage with execute: true and process that response; never report convergence before a converged action.converged: the independently evaluated outcome passed. Show the final ontology.stagnated: the ontology stayed unchanged, or rejected scores moved less than 0.01, across a 3-generation window. Hand off to ooo unstuck (ouroboros_lateral_think).exhausted: the 30-generation cap was hit. Show the best generation.failed: report the error. If it names an expired lineage owner, first confirm the prior owner process is dead, then make one call with recover_expired_claim: true; never set it for a slow or still-running owner.continue. With execute: true each generation already ran Execute→Evaluate, so never offer ooo evaluate with the lineage_id: formal evaluation takes an execution session_id, which the lineage id is not.Executed generations include a QA verdict unless skip_qa: true; use its score to track quality across generations. A passing Gen 1 may converge immediately.
Call ouroboros_lineage_status with lineage_id; show generation count, ontology evolution, and convergence progress. This only reads status; it does not resume the loop.
Call ouroboros_evolve_rewind with lineage_id and to_generation (kept, inclusive; later generations are truncated). Continue by calling ouroboros_evolve_step with the same lineage_id.
Never launch a full-graph control arm on your own: it would consume the savings being measured. Only when the user asks, call ouroboros_evolve_step for an existing Gen 2+ lineage with benchmark_control: true, execute: true, and an explicit clean Git project_dir in a distinct worktree at the treatment commit. A smaller active set is a working-set observation, not a savings claim; the frugality verdict comes from the server's receipts.
Explain the evolutionary loop and suggest installing the MCP server (see Getting Started), then running ouroboros mcp serve --runtime claude-cli and adding it to the runtime's MCP configuration.
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.
No reviews yet. Tell others what you thought.
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.
Turn a multi-file development task or technology migration into a specification with acceptance criteria, then launch background implementation and verification. The workflow clarifies missing requirements, reviews the specification, and tracks progress and blockers through linked jobs.
Register and search existing Git repositories and worktrees, then choose which projects Ouroboros interviews use as context. You can also generate a configuration containing verified build, test, and other check commands for the evaluation workflow.
Stop stuck Ouroboros executions or background jobs by ID, or cancel all running and paused executions in the current project. It reports whether cancellation is complete or has been requested, with guidance for checking the final status.
Verify finished work against acceptance criteria using executable checks and a review of whether each requirement is met. Multiple models can review uncertain cases, and rejected work can enter an automated repair loop when the required Seed is available.
Turn a vague development idea into clear goals, constraints, and acceptance criteria through a guided interview. It checks unresolved decisions and confirms the agreed goal before moving toward a Seed, the requirements document used by Ouroboros.
Start the introductory guidance for Ouroboros by sending `ooo` or asking to begin. This entry point passes control to the welcome skill, including before runtime-specific setup has been completed in the Marketplace plugin.