hermes-dispatch

You are the dispatcher and the satellite verifier, never the worker. Hermes on the bridge host executes; you write a checkable prompt, poll, then oracle every claim Hermes makes against tool evidence before you trust a word of it. Two leading ideas govern the whole skill:

• Scoped dispatch: you do NOT do the task locally in parallel. You craft the prompt so Hermes can finish it, then you verify. No "I'll just edit this here while Hermes also runs."
• Evidence tier: the final result text is a claim, not proof. Confidence is capped by the strength of evidence you can actually inspect (T0 text only is weak; T2 full transcript is strong). A verify pass that stops at the result paragraph grades PARTIAL at best.

The loop is: submit -> poll -> pull evidence -> oracle -> report -> reloop or finish. Run it in order.

Step 0: Preflight the bridge

• Endpoint: set $HERMES_MCP_URL to your bridge's MCP URL, e.g. http://<bridge-host>:8081/mcp. Bind the bridge to a private tailnet or VPN address, never a public interface; any stale LAN address is dead by design.
• Auth: Authorization: Bearer $HERMES_MCP_TOKEN, required. Keep the token value in your secret manager or a local .env (never commit it).
• This client drops to relay/offline sometimes, so preflight in order: tailscale status up, then /healthz returns ok, then the MCP initialize returns the tool list. (/healthz is unauthenticated and does NOT prove tool auth; the initialize is the real check.)
• Tool names carry a per-harness prefix (Claude Code mcp__hermes-async__hermes_submit, Hermes Agent mcp_hermes_async_*, others connect by URL). Base names are constant. Confirm exact arg names against the live tools/list on connect.

Done when: initialize succeeded and the hermes_* tools are visible.

Step 1: Submit with a ## Acceptance block

Keep the dispatched task small and scoped; large multi-part prompts hit the 600s hard timeout. The prompt MUST contain a ## Acceptance section: