Menu
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.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
| 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.
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.
Diff two loomcycle AgentDef versions by def_id and show what changed in system_prompt, allowed_tools, max_tokens, and other fields. Use when the user wants to compare two versions of a self-evolving agent definition.
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.