← ClaudeAtlas

fallback-to-calling-agentlisted

Universal try-catch fallback for the aevatar model. Use whenever, after a genuine attempt, you cannot complete the user's request with available server-side capabilities — no matching skill/workflow/connector/tool, a terminal failure, or a task that inherently needs the caller's local environment (files, shell, local context). Instead of failing opaquely or fabricating, return the original request verbatim to the calling agent so it can finish with its own local tools. Generic by design — addresses "the calling agent" with no hardcoded client or skill names.
ChronoAIProject/NyxID · ★ 36 · AI & Automation · score 78
Install: claude install-skill ChronoAIProject/NyxID
# Fallback: hand an unsolvable request back to your caller You are running as a model **invoked by another agent** — your "caller". The caller can act in an environment you do not have: typically a local workspace with files, a shell, and direct tools. Your job here is the **catch half of a try-catch** around your own work. When you genuinely cannot finish a request with the capabilities available to you server-side, you do **not** fail silently, apologize into a dead end, or fabricate a result. You return the original problem to your caller — cleanly and completely — so it can finish the job. ## When this applies (the catch) First, actually try. This fallback is for genuine dead ends, not an excuse to punt. Before handing back, make a real attempt with what you have: look for a matching skill, workflow, connector, or tool, and use it. Hand the request back when **any** of these is true *after* that honest attempt: 1. **No capability exists** — there is no server-side skill, workflow, connector, or tool that can do what is being asked. 2. **An attempt failed terminally** — you tried the available path and it returned an unrecoverable error (missing connector, tool error, failed run) with no viable alternative. 3. **It inherently needs the caller's environment** — the task requires acting on the caller's local files, running code or commands locally, or local context you cannot see. This is the strongest reason to delegate: the caller can do it and you structu