/**
 * trigger-agent — a GENERIC, agent-callable skill for firing another Zibby
 * agent run from inside a running agent.
 *
 * The agent gets ONE real MCP tool, `trigger_agent`, and DECIDES for itself
 * when (and how many times) to call it — so a triage agent can trigger a fix for
 * every issue it judges worth fixing, an orchestrator can fan out to N children,
 * etc. This is the agent-driven counterpart to the engine's deterministic
 * `dispatchSubgraph` — the primitive lives in the model's hands, not in node code.
 *
 * Portable across CLOUD and SELF-HOSTED (the same reason @zibby/skills/datasetStore
 * works in both): it POSTs to `${apiBase}/projects/{PROJECT_ID}/workflows/{type}/trigger`
 * with the run's `PROJECT_API_TOKEN`, resolving `apiBase` from the env the runtime
 * injects — cloud sets `PROGRESS_API_URL` (`<base>/executions`), self-hosted's
 * docker/k8s dispatcher sets `ZIBBY_ACCOUNT_API_URL` ("reachable FROM the run") —
 * so neither environment needs a special case.
 *
 * Fire-and-forget: it triggers the run and returns its executionId; it does NOT
 * wait for the child to finish. `handleToolCall` NEVER throws — any failure comes
 * back as `{ ok:false, error }` so a bad trigger can't crash the calling agent.
 *
 * Shape mirrors the other hand-written multi-tool skills (github.js / datasetStore.js):
 * `serverName`, `allowedTools`, `tools[]`, `handleToolCall`, and a `resolve()` that
 * spawns the generic bin/mcp-skill.mjs.
 */
export declare const triggerAgentSkill: any;