Menü
Walk through replaying a failed loomcycle run — inspect the failure, adjust the prompt or agent, and re-spawn. Use when a loomcycle run errored or produced a bad result and the user wants to retry with a fix.
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
| name | loomcycle-replay-failed-run |
| description | Walk through replaying a failed loomcycle run — inspect the failure, adjust the prompt or agent, and re-spawn. Use when a loomcycle run errored or produced a bad result and the user wants to retry with a fix. |
Use when a loomcycle run failed (errored or produced a bad result) and the operator wants to retry with a change rather than blindly re-running.
Steps:
Fetch the failed run. With the agent_id (or run_id) the operator
gives you, call mcp__loomcycle__get_run:
{ "agent_id": "<agent_id>" }
Read the status snapshot — the failure reason, the agent name, and (if present) the input that produced it.
Diagnose, briefly. Summarise why it failed in one or two lines: provider/tool error, bad prompt, missing capability, timeout, etc. If the cause is a loomcycle-side error (provider 5xx, tool denial), say so — a replay won't fix an operator-policy or config problem; flag that instead.
Propose the change. Suggest the smallest adjustment likely to fix it: a clarified prompt, a different registered agent, narrowed/expanded tools, or different inputs. Confirm with the operator before re-spawning.
Re-spawn with mcp__loomcycle__spawn_run, carrying the adjustment:
{
"agent": "<same-or-new-agent>",
"segments": [ { "role": "user", "content": [ { "type": "trusted-text", "text": "<revised prompt>" } ] } ]
}
Reuse the active user_id / user_bearer from /loomcycle:connect.
Compare. Report the new run's result against the old failure so the
operator can see whether the change helped. Surface the new agent_id
(cancel handle) and run_id.
Do not loop endlessly — if a second replay also fails the same way, stop and recommend an operator-side fix (config, agent definition, provider tier policy) rather than spawning a third time.
Diff two loomcycle AgentDef versions by def_id and show what changed in system_prompt, tools, max_tokens, and other fields. Use when the user wants to compare two versions of a self-evolving agent definition.
Configure a loomcycle runtime — providers, model tiers, user tiers, fallbacks, per-agent sampling and context-compaction, environment variables, deployment profiles (brew/in-system, containerized, true sandbox, server, multi-tenant, cloud), filesystem Volumes, the Bashbox in-process sandbox, the Path VFS, chunked-graph Documents, inbound webhooks, and third-party MCP servers. Use when the user wants to set up or tune loomcycle.yaml or its env, pick a deployment posture, wire provider routing/cost-cascades, gate plans, tune decoding (temperature/top_p) or compaction, lock down tool/sandbox/auth, enable or choose between Bash and the Bashbox sandbox (incl. its host-command fallback), name resources with Path, author chunked-graph Documents (and the SQL Memory they require), receive webhooks, or connect external MCP tools.
Guide the user through importing a .claude/ directory into loomcycle yaml using the `loomcycle import claude-code` CLI — dry-run first, review the report, then write. Use when the user wants to move Claude Code agents/skills/MCP servers into a loomcycle config.
Spawn a loomcycle evaluator agent to score the current Claude Code transcript (or a named run) and report the result. Use when the user wants an independent quality/score judgement of work just done via loomcycle.