القائمة
يُحدَّد Prompt الذي يراجع المصدر أولًا بشكل افتراضي. يمكنك التبديل إلى أمر مباشر أو تنزيل نسخة محلية.
اقرأ SKILL.md وأي ملفات مرافقة يعرضها SkillsMP قبل أن تقرر التثبيت.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
يتجاوز الأمر المباشر Prompt المخصّص للمراجعة. افحص المصدر قبل تشغيله.
npx skills add https://github.com/Q00/ouroboros --skill ouroboros-runيبقى الأمر في سطر واحد. مرّر أفقيًا لمراجعته كاملًا قبل النسخ.
تفضّل نسخة محلية؟ نزّل الملفات المتاحة حاليًا لدى SkillsMP.
استنادا إلى تصنيف SOC المهني
عرض SKILL.md
| name | ouroboros-run |
| description | Execute a Seed specification through the workflow engine |
| aliases | ["execute"] |
| mcp_tool | ouroboros_execute_seed |
| mcp_args | {"seed_path":"$1","cwd":"$CWD"} |
Execute a Seed specification through the Ouroboros workflow engine.
/ouroboros:ouroboros-run [seed_file_or_content]
Trigger keywords: "ouroboros run", "execute seed"
.yaml fileWhen the user invokes this skill:
The Ouroboros MCP tools are often registered as deferred tools that must be explicitly loaded before use. You MUST perform this step before proceeding.
tool discovery query: "+ouroboros execute"
mcp__plugin_ouroboros_ouroboros__ (e.g., ouroboros_execute_seed, ouroboros_session_status). After runtime tool discovery returns, the tools become callable.IMPORTANT: Do NOT skip this step. Do NOT assume MCP tools are unavailable just because they don't appear in your immediate tool list. They are almost always available as deferred tools that need to be loaded first.
CRITICAL — deferred-schema guard (prevents "Invalid tool parameters"):
This skill makes execution MCP calls across multiple turns, and each turn runs
in a fresh tool context. A deferred tool's schema loaded on one turn is NOT
guaranteed to still be loaded on the next. If you call any execution ouroboros_*
MCP tool while its schema is not loaded in the current turn, the runtime
rejects the call with "Invalid tool parameters" before it reaches the server.
Therefore: immediately before EVERY execution MCP call in this skill, re-run
tool discovery query: "+ouroboros execute" to reload the execution tool family,
including ouroboros_start_execute_seed, ouroboros_job_wait,
ouroboros_ac_tree_hud, and ouroboros_job_result (idempotent — a no-op when
already loaded). If the load returns no matching tool (and the tool is not already callable — an empty load for an already-exposed tool is an expected no-op, not absence), switch to the documented
fallback instead of retrying the failing call.
Detect git workflow (before any code changes):
CLAUDE.md for git workflow preferencesmain/master:
ooo/run/<session_id>Check if the user provided seed content or a file path:
Before a fresh start, when the user has not already chosen an efficiency
policy, 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 start
handoff still reports the resolved policy). When it is ask or unset, ask
in outcome language:
efficiency_mode="adaptive" and frugality_assurance="observe".efficiency_mode="quality_first" and frugality_assurance="off".frugality_assurance="strict" is a separate explicit opt-in because it may
spend extra work on proof. Never enable it merely because efficient execution
was chosen. Do not ask again on resume; the server restores the persisted
policy and rejects an attempted resume-time change.
Start background execution with ouroboros_start_execute_seed:
Tool: ouroboros_start_execute_seed
Arguments:
seed_content: <the seed YAML>
efficiency_mode: <adaptive or quality_first>
frugality_assurance: <observe, off, or explicit strict>
max_iterations: 10 (or as specified by user)
Omit model_tier by default so the runtime selects automatically. Include
model_tier: <user choice> only when the user explicitly requested a tier.
This returns immediately with a job_id, , and .
If the final run result meta contains chained_evaluate_job_id:
ouroboros_job_result after terminal statusfinal_approved: true; otherwise render not approved and list failed ACs or the failure reason from the evaluation resultNext: ooo evaluate <session_id> as the manual retrychained_ralph_job_id, continue observing
that job before presenting the final outcome. Report approval/convergence or
the bounded Ralph stop reason; do not call the run blocked merely because
its first evaluation was rejected.If chained_evaluate_job_id is absent, keep the legacy path verbatim:
Next: ooo evaluate <session_id> for formal 3-stage verificationNext: Fix the issues above, then ooo run to retry -- or ooo unstuck if blockedNext: Review failures above, then ooo run to retry -- or ooo unstuck if blockedIf the MCP server is not available, inform the user:
Ouroboros MCP server is not configured.
To enable full execution mode, run: /ouroboros:setup
Without MCP, you can still:
- Use /ouroboros:interview for requirement clarification
- Use /ouroboros:seed to generate specifications
- Manually implement the seed specification
User: /ouroboros:ouroboros-run seed.yaml
[Reads seed.yaml, validates, starts background execution]
Background execution started.
Job ID: job_a1b2c3d4e5f6
Session ID: orch_x1y2z3
Execution ID: exec_m1n2o3
[Relay]
In progress: Deliver is at Task 1/3 and Subtask 12/16.
Current work is finishing the workflow routing Subtask.
[Relay]
Level update: parallel level 1/1 has finished, and Task progress advanced to 3/3.
Execution is complete. Fetching the final job result now.
[Fetching final result...]
Result:
Seed Execution SUCCESS
========================
Session ID: orch_x1y2z3
Goal: Build a CLI task manager
Duration: 45.2s
Messages Processed: 12
Verification Status: executed_unverified
Formal Evaluation: NOT evaluated by the 3-stage evaluator
Next: `ooo evaluate orch_x1y2z3` for formal 3-stage verification
# Newer server path:
Verification Status: evaluation_enqueued
Chained Evaluation Job ID: job_eval987
[Poll ouroboros_job_wait/job_status, then fetch ouroboros_job_result]
Formal Evaluation Verdict: APPROVED
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.
session_idexecution_idIf resuming an existing session, include session_id:
Tool: ouroboros_start_execute_seed
Arguments:
seed_content: <the seed YAML>
session_id: <existing session ID>
Recommended monitoring stance: delegate observation to one child session.
TUI surfacing at job start (RFC #1392):
After job_id, session_id, and execution_id are returned, surface a live
view once without delaying execution or observer delegation:
If response.meta.dashboard_url exists, show it as the primary live view.
If execution.tui_autolaunch: true (or legacy top-level
tui_autolaunch: true) is present in the loaded Ouroboros config, run
ouroboros tui open unconditionally and mention the dashboard in one
short line.
Otherwise mention once that the TUI can be opened in a new terminal with
ouroboros tui open. Offer to open it, but do not block the run waiting for
an answer. Remember the answer for this session and do not repeat the offer.
If the user accepts, run ouroboros tui open.
If ouroboros tui open reports a manual command because the environment
is headless, SSH, or unsupported, relay that command once and continue.
The dashboard is an external observer. It does not change which chat session owns MCP polling.
After IDs are returned, print only this short handoff:
Execution started in background.
Job ID: <job_id>
Session ID: <session_id>
Execution ID: <execution_id>
Live view: <dashboard_url, or `ouroboros tui open`>
Runtime/harness: <response.meta.runtime_backend>
LLM backend: <response.meta.llm_backend>
Efficiency: <response.meta.efficiency_mode>
Frugality assurance: <response.meta.frugality_assurance>
Observation: <confirmed read-only child observer, or durable catch-up mode>.
With a confirmed observer, meaningful progress, attention, and completion
events will be posted here. Without one, the run still survives this turn
and I will catch up from durable events on your next message or status request.
This conversation stays available while the run continues.
We can refine requirements, inspect or review code, or work on an unrelated
task in an isolated worktree. I will check for active-worker conflicts before
editing this run's workspace.
For full details later: `ouroboros_ac_tree_hud(session_id=<session_id>)`
Text-only host compatibility (OMP and similar bridges):
If response.meta.job_observer is unavailable, inspect the response content
for the final sentinel block:
<!-- ouroboros-job-observer-v1 base64
<payload>
-->
Base64-decode <payload>, then fail closed unless it passes the canonical v1
validation implemented by extract_job_observer_inline_handoff: exactly one
bounded terminal sentinel; fixed protocol, role, ownership, wait/result tools,
restrictions, and follow-result keys; internally consistent IDs; and a
job_id matching the visible start receipt. Use visible Job/Session/Execution
IDs only as identity anchors, never to reconstruct the nested contract. If
structured and inline surfaces differ or validation fails, do not spawn an
observer; report a transport-integrity failure.
When a structured or recovered job_observer is present and the host has an
independent child/subagent session primitive, spawn exactly one observer
session and pass that object unchanged. Codex uses spawn_agent, OMP uses
one native Task child, and Claude Code uses one Task/Agent child. The observer must:
On Codex, call the native spawn_agent primitive exactly once with
task_name="run_observer" and include the structured or recovered
job_observer unchanged in the child message. A wait call is not a spawn.
Require the spawn result to return a live child ID/path before saying an observer is connected or before ending the start turn.
On OMP, submit exactly one Task item named RunObserver with the recovered
or structured contract unchanged, require the returned live agent/job ID,
and use the host wait/inbox relay until the observer returns terminal.
A job-status poll in the parent is not an observer spawn.
remain read-only: no repository edits, execution control, or worker fan-out;
own the job cursor exclusively and reload deferred MCP schemas immediately before each observer tool call;
call the declared wait.tool with the declared arguments, update its local
cursor from response meta, and repeat until terminal;
call the declared result.tool after terminal status;
follow any job IDs named by follow_result_job_keys, including chained
formal evaluation, before returning one compact final summary;
send sparse progress notices only when the host supports child-to-parent messages and the state meaningfully changes.
The main session must not poll the same job while the observer owns it. It may
continue the user conversation, refine requirements, perform read-only
inspection/review, handle explicit status/control requests, or work on an
unrelated task in an isolated worktree. Before writing to the active run's
workspace, check for overlap with worker files or isolate the work. If
job_id is absent because plugin mode already delegated the whole execution,
follow that plugin child lifecycle instead.
On Codex, a confirmed observer also requires a parent relay loop. After
spawn_agent returns a live child ID/path, keep the parent turn open with
wait_agent calls of at most 60 seconds. A child send_message only queues a
mailbox event and cannot wake a parent turn that has already ended. Relay
meaningful observer updates, then wait again until the child returns its
terminal summary. User input may interrupt the wait; handle it and resume the
relay loop while the observer remains 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 wait loop must never call Ouroboros job tools or compete for the
observer's cursor.
Handle observer messages as events, not as a transcript:
phase_changed / progress_advanced: relay at most 1-2 concise lines.
Interpret the structured subtype, not raw logs:
run_configuration: state the current runtime/harness, starting model or
tier when known, efficiency mode, and frugality assurance. If the exact
model is not known yet, say it will be reported by the first routing event.execution_plan: state total ACs, total dependency/parallel levels,
whether work can run in parallel, and the first scheduled AC summaries.discovery_summary: say which bounded targets the AC is examining and
the purpose; never expose search queries, raw commands, or reasoning.level_started / level_completed: say which parallel level is active
or finished and the meaningful success/failure counts.ac_routing / harness_changed: say "currently running with" and report
only initial routing or a real model/tier/harness change.ac_verified: report the completed AC and its compact assurance evidence.attention_required: surface the blocker or pending decision immediately
and ask the user only when human judgment is required.terminal: fetch/present the final result and any chained evaluation..queued / .delivering: say the exact AC has a pending or claimed
intent signal and name
the effective boundary; do not claim application yet..applied / .completed: confirm runtime-proven application and
relay the bounded AC reply when present..rejected / .delivery_uncertain: surface immediately and never
claim the AC changed course.Render every relay in the user's current conversation language. Keep event codes and effective-mode values unchanged only when exact diagnostics help. These are English canonical host instructions. Phrase the facts naturally in the active conversation language.
This ownership split is the default for SOL-class models: the main model performs one start handoff, while a small isolated context owns the repetitive wait/result state machine.
If child creation is unavailable, fails, or returns no live child, do not claim that an observer exists or promise live proactive messages. The detached worker survives the stdio MCP turn. Tell the user that progress is durable and will be caught up on the next parent turn or explicit status request. Keep the turn open only when the user explicitly asked for live watching; then use the fallback below.
Fallback: low-token relay loop in the main session.
Use this only when response.meta.job_observer is absent, the host has no
independent child session primitive, and the user explicitly asked to keep
watching in the current turn. Do not run it in parallel with a delegated
observer. Otherwise end the turn safely and catch up from the same cursor on
the next parent turn.
Use ouroboros_job_wait, not repeated ouroboros_ac_tree_hud, for routine
monitoring. Keep the latest cursor and previous progress counters from the
tool meta payload.
This loop is intentionally harness/model friendly:
response.meta as the source of truth.response.text for counts, status, or cursor.response.text only as a human-readable current-message hint.ouroboros_job_result after a terminal status.cursor = <cursor from start/status response, or 0>
prev_status = "running"
prev_phase = null
prev_ac_completed = 0
prev_sub_ac_completed = 0
prev_message = null
loop:
Tool: ouroboros_job_wait
Arguments:
job_id: <job_id from step 3>
cursor: <cursor>
timeout_seconds: 180
view: "summary"
stream: "linked"
wait_for: "attention_or_ac_change"
cursor = response.meta.cursor
if response.meta.changed is false:
# Do not narrate unless the user explicitly asked for heartbeat updates.
continue
status = response.meta.status
phase = response.meta.current_phase
ac_completed = response.meta.ac_completed
ac_total = response.meta.ac_total
sub_ac_completed = response.meta.sub_ac_completed
sub_ac_total = response.meta.sub_ac_total
# The metadata field names remain legacy-compatible; relay them to users as Task/Subtask progress.
message_hint = first non-empty non-metadata line from response.text, or null
# Build one short relay update from structured fields.
if status in ["completed", "failed", "cancelled", "interrupted"]:
print terminal_relay(status, phase, ac_completed, ac_total, sub_ac_completed, sub_ac_total)
break
if ac_completed > prev_ac_completed:
print task_progress_relay(phase, ac_completed, ac_total, sub_ac_completed, sub_ac_total, message_hint)
elif sub_ac_completed > prev_sub_ac_completed:
print subtask_progress_relay(phase, ac_completed, ac_total, sub_ac_completed, sub_ac_total, message_hint)
elif phase != prev_phase or status != prev_status:
print phase_or_status_relay(status, phase, ac_completed, ac_total, sub_ac_completed, sub_ac_total)
elif message_hint != prev_message:
print current_work_relay(phase, ac_completed, ac_total, sub_ac_completed, sub_ac_total, message_hint)
prev_status = status
prev_phase = phase
prev_ac_completed = ac_completed or prev_ac_completed
prev_sub_ac_completed = sub_ac_completed or prev_sub_ac_completed
prev_message = message_hint or prev_message
Notes:
timeout_seconds: 180 means the MCP call can block for up to 3 minutes.
This keeps the main session available often enough for a live relay while
still avoiding noisy polling.view: "compact" for very long jobs or when the user only wants a
heartbeat. The raw tool may still return legacy text such as
job_x | running | AC 3/17; relay that to users as Task progress.view: "summary" for normal monitoring. It includes the job message
plus Task/Subtask counts derived from legacy ac_completed/sub_ac_completed
metadata fields.view: "full" only when the user asks for detailed job status.Relay style examples:
In progress: Deliver is at Task 1/3 and Subtask 12/16. Current work is the Subtask 3 regression test.Level update: parallel level 1/1 has finished, and Task progress advanced to 3/3.Completed: execution finished. Fetching the final job result now.Relay output contract for other harnesses/models:
phase, Task completed/total and Subtask completed/total when present.Do not paste the full raw tool output unless the user asks for raw status. Do not add speculative ETA unless the tool provides one.
Synapse intent refinement: When the user gives additive implementation intent during an active run, the main session owns target selection; never ask the user for internal AC/session IDs.
Immediately before each Synapse call, reload its deferred schemas with
tool discovery query: "+ouroboros session signal".
execution_id from the start result or observer contract and call
ouroboros_session_signal_targets(execution_id=...).ac_content, display path,
and current HUD activity when needed. One active target may be selected
directly. With multiple targets, select only when one is materially more
relevant; ask a short user-language clarification only for genuine ties.ouroboros_session_signal
with the selected target's exact scope/attempt/execution guards,
contract_effect="additive", source="user", mode="redirect", and
fallback_mode="after_turn". Copy expected_contract_version when target
discovery supplies it, and create one stable idempotency key for this exact
user turn. If the target went stale, rediscover once instead of asking for
IDs.mode="inform" and
contract_effect="additive", and omit fallback_mode entirely because it
is valid only for redirect. Synapse runs a no-tools reply turn when the
runtime supports it; relay the bounded reply from the completed event..applied or .completed before saying it was reflected.Never use Synapse to change approved goals, ACs, constraints, or non-goals; those require an approved shared successor or replacement contract.
Active Conductor attention handling: recommended_host_actions is the
authoritative menu. Never invent a mutating tool call.
phase="selected" through
ouroboros_record_conductor_decision before ACT. For a specification
change in run mode, obtain explicit user approval and bind its receipt.completed, failed, or declined outcome. Do
not silently retry a failed conductor action.Use ouroboros_ac_tree_hud only for manual drill-down or anomaly checks.
Do not call full tree HUD in the normal polling loop.
Use these targeted calls:
# Explicit short HUD, useful for a one-off check
Tool: ouroboros_ac_tree_hud
Arguments:
session_id: <session_id>
cursor: <cursor>
view: "summary"
# Lowest-token one-line HUD
Tool: ouroboros_ac_tree_hud
Arguments:
session_id: <session_id>
cursor: <cursor>
view: "compact"
# Full tree only when user asks "show details", progress looks stuck,
# or debugging requires seeing the task/subtask structure.
Tool: ouroboros_ac_tree_hud
Arguments:
session_id: <session_id>
cursor: <cursor>
view: "tree"
max_nodes: 30
Treat unchanged cursor=<cursor> from explicit compact/summary views as a
no-op. Do not explain it to the user unless they explicitly asked for
heartbeat messages.
Fetch final result in the polling owner with ouroboros_job_result.
The delegated observer performs this call on the default path. The main session performs it only on the fallback path from step 6.
Tool: ouroboros_job_result
Arguments:
job_id: <job_id>
Present the execution results to the user:
Post-execution QA and formal evaluation (automatic):
ouroboros_start_execute_seed automatically runs QA after execution.
The QA verdict is included in the final job result text. This QA check is
not the formal 3-stage evaluator. On servers that return
chained_evaluate_job_id, the run has already enqueued the formal
evaluator as a separate bounded background job.
To skip: pass skip_qa: true to the tool.