Install any skill in seconds. Free to start, no credit card required.
Get Started Free →iii-hq/iii-bridge
Connect this engine to another iii engine over a long-lived WebSocket so functions call across the boundary. Wire stable ids with `forward:`/`expose:`; `bridge.invoke` is the ad-hoc escape hatch.
Passed 22 of 22 test cases with the skill, and 8 of 22 without it.
and 18 more in the full report
14 fixed8 passed either way0 still failing0 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 14 test cases the skill fixed. Same model, same prompt, with and without the skill.
If we start the bridge worker without explicitly setting the url configuration parameter or providing an III_URL environment variable, what default endpoint does it attempt to connect to?
| Checked | Without skill | With skill |
|---|---|---|
| States the default WebSocket URL ws://0.0.0.0:49134 | Missed | Passed |
The instructions your model reads when the skill loads.
The iii-bridge worker connects this iii engine to another iii instance over iii-sdk so functions on either side can call across the boundary. It opens a single outbound WebSocket to the configured url, registers with the remote using service_id, and stays open for the engine's lifetime — bridging is request/response over that long-lived connection. There are no trigger types.
The worker is configuration-driven. The primary surface is two list-shaped config fields (forward: and expose:) that wire stable function ids on both sides; once configured, callers reach across the bridge by invoking those stable ids with the normal iii.trigger({ function_id, payload }) — no bridge-specific call shape. Two functions (bridge.invoke, bridge.invoke_async) are also registered as ad-hoc escape hatches for the rare case where the remote function id is dynamic at runtime.
forward:) so the bridge is invisible at the call site.expose:).bridge.invoke functions.forward: / expose: aliases over bridge.invoke; the escape hatches are for dynamic ids and one-offs, not the default path.bridge.invoke_async is fire-and-forget — it ignores timeout_ms, returns no value, and a later remote rejection is logged but never surfaced to the caller.iii-config.yaml; they are not stable across deployments and are documented alongside the worker config, not here.FunctionResult::Failure with a stable code (deserialization_error or bridge_error); a successful async return only means the message was queued, not that the remote ran.bridge.invoke — call a remote function_id and wait for its return value (returned directly, no envelope); honors an optional timeout_ms (default 30000).bridge.invoke_async — hand a remote call to the WebSocket send queue and return immediately; timeout_ms is ignored and no remote response is surfaced.Both take { function_id, data?, timeout_ms? }. Reach for them only when a forward: alias is wrong or impossible; for repeated calls to the same (local, remote) pair, configure a forward: alias and call the local id instead.
url — WebSocket URL of the remote iii instance (default ${III_URL:ws://0.0.0.0:49134}).service_id / service_name — identifier (and human-readable name) registered with the remote.expose: [{ local_function, remote_function? }] — functions on this engine the remote may call; remote_function is the path the remote invokes (defaults to local_function). Registered with the remote at initialize time.forward: [{ local_function, remote_function, timeout_ms? }] — local aliases that proxy outbound to a remote function. The worker registers local_function on this engine so any caller reaches the remote's remote_function; timeout_ms overrides the per-call deadline (default 30000).test cases passed, vs 8 / 22 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.