Dispatch a task to Hermes over the async MCP bridge, optionally run the background watcher, then verify Hermes's result as an independent satellite verifier. Use when dispatching work to Hermes ("send this to Hermes"), running the Hermes work queue, or acting as the satellite verifier of a Hermes result. Reach for it whenever you call hermes_submit or hermes_respond on the hermes-async bridge.
Standardmäßig ist der Prompt ausgewählt, der zuerst die Quelle prüft. Sie können zu einem direkten Befehl wechseln oder eine lokale Kopie herunterladen.
Quelldateien prüfen
Lesen Sie SKILL.md und alle von SkillsMP angezeigten Begleitdateien, bevor Sie sich für eine Installation entscheiden.
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Ein direkter Befehl überspringt den Prüf-Prompt. Prüfen Sie die Quelle, bevor Sie ihn ausführen.
Dispatch a task to Hermes over the async MCP bridge, optionally run the background watcher, then verify Hermes's result as an independent satellite verifier. Use when dispatching work to Hermes ("send this to Hermes"), running the Hermes work queue, or acting as the satellite verifier of a Hermes result. Reach for it whenever you call hermes_submit or hermes_respond on the hermes-async bridge.
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 returns the tool list. ( is unauthenticated and does NOT prove tool auth; the initialize is the real check.)
initialize
/healthz
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:
Bulleted, each bullet exactly ONE testable requirement. These become deterministic user_requirement claims at verify time; without them the verifier is guessing.
Require Hermes to return proof artifacts inline (command output, file excerpts, paths), not just a summary.
If you intend an expensive mode (MoA, delegation), say so in the acceptance block so cost cross-checks work.
Before hermes_submit, pipe the draft prompt through tools/scope_check.py. CAUTION means tighten the scope; SPLIT (exit 1) means restructure as a ## Delegation plan of parallel children or make it a smaller task. The 600s cap is deliberate, and the checker thresholds come from real bridge history, not vibes.
Call hermes_submit(prompt, caller). Save task_id + submit_time. One task_id per poll chain unless the user explicitly asked for parallel tasks.
Swarm dispatch (delegation-aware)
Hermes can spawn isolated child agents via delegate_task — each with its own conversation, terminal session, and toolset, running concurrently up to the host's delegation.max_concurrent_children. Exploit this instead of drip-feeding sequential bridge tasks:
When the work splits into 3+ independent slices, submit ONE task that instructs Hermes to fan out, not N serial submits. Parallel children are how big scope fits inside the 600s cap that a serial mega-prompt would blow; only child summaries return to the parent, so its context stays small.
Add a ## Delegation plan section to the prompt: one line per slice. Each child brief must be self-contained — children share no context with the parent or each other, so every path, constraint, and template goes into the slice text.
One acceptance bullet per slice, and each bullet must name a world-checkable artifact (a file, a commit, command output written to a path). Children's tool calls never reach your T2 transcript — if a child leaves nothing in the world, the verifier can't prove its work happened.
Slices must be truly independent: no ordering dependencies, no two children editing the same file. If slices need sequencing or review gates between them, keep separate bridge tasks — a swarm gives you one verify gate at the end, serial dispatch gives you one after each step.
Delegation is an expensive mode: declare it in the acceptance block (same rule as MoA) so the cost cross-check against expensiveToolsUsed works.
It is still ONE task_id — poll and watch exactly as below. Mechanics, host config knobs, and the child-evidence rule: reference.md.
Done when: a task_id is returned.
Step 2: Poll (the contract, enforced in code, not by vibe)
Constant
Value
initial sleep
30s
interval
120s
hard cap
600s from submit
Sleep 30, then hermes_status(task_id). On completed or failed, go to Step 3. On running/pending: if now - submit_time >= 600 stop as timeout, else sleep 120 and re-check. Never poll faster than 30s; never past 600s. The classic failure is failed without ever seeing completed because of too few polls before the cap. If the session cannot block in a loop, use ScheduleWakeup: +30s, then +120s per re-check, same terminal rules.
Done when: a terminal status or the 600s timeout.
Async dispatch (fire-and-forget + interrupter)
This is an additive branch after Step 2, not a replacement for the synchronous polling contract. Use it when the harness can keep working while a background process watches Hermes presence.
After hermes_submit returns a task_id, launch the watcher instead of blocking on the Step 2 polling loop:
Claude Code: run python3 tools/hermes_watch.py <task_id> from skills/hermes-dispatch/ with Bash run_in_background, or use a Monitor primitive.
Other harnesses: run nohup python3 tools/hermes_watch.py <task_id> > hermes-watch-<task_id>.log 2>&1 & from skills/hermes-dispatch/, then tail -f hermes-watch-<task_id>.log.
The watcher interrupts ONLY on:
done: terminal state with hermes_result.
stuck: past the 600s cap.
not-responding: 5 consecutive failed checks, with a RECOVERED follow-up when contact resumes.
Sparse still-alive heartbeats.
Design principle: presence = free code, judgment = LLM only at result/decision points. Polling costs zero tokens. When the watcher prints a terminal or decision line, return to Step 3 and verify the result exactly as usual.
Done when: the watcher is running for the task_id, or the synchronous Step 2 branch produced a terminal status or timeout.
Step 3: Pull evidence (never trust the paragraph)
On ANY terminal status, call hermes_result(task_id) EXACTLY once (both completed and failed). It carries a cost block.
Failure handling is mandatory, not the happy path only. A failed task is terminal without resume. A timeout returns session_id=null, so you CANNOT hermes_respond to it. result and error are independent fields; a failed task can carry both, so parse both. Only completed yields a resumable session_id.
For anything past a trivial smoke test: hermes_transcript(session_id), then hermes_decompose(transcript_or_session_id, original_prompt) to get the AtomicClaim[]. Pass your dispatch prompt (with its ## Acceptance block) into decompose, or the user_requirement claims never get generated. Do NOT re-parse the transcript by hand; always go through hermes_decompose.
A failed task has session_id=null, so T2 is unreachable: grade it at T0 (result and error text only) and escalate. Do not fabricate a higher tier.
Done when: you hold the result and (for non-trivial tasks) the decomposed claims.
Step 4: Oracle every claim
Run this pass READ-ONLY (verifier independence): either spawn a read-only-tooled subagent for the verify, or post-hoc assert the verify pass issued zero mutating tool calls. Do not treat the pass as read-only unless one of those two mechanisms is in place. The correction channel is always hermes_respond; verifier_prompt is a dead local-Pi trap, never use it.
Oracle rules per claim kind:
tool_execution: compare the assertion to embeddedEvidence, which must come only from the T2 export tool_result row, never from the hermes_result text. Deterministic PASS/FAIL where possible.
assistant_assertion: must cite a tool row or external oracle. Never PASS on prose alone; it cannot raise confidence or count toward PERFECT.
user_requirement (your ## Acceptance bullets): FAIL if no supporting tool evidence exists.
structured_assistant_claim: cap confidence at 0.55; never satisfies PERFECT unless the transcript proves a forced output mechanism.
Delegated (swarm) work: the parent T2 transcript proves only that delegate_task ran and what summary came back. A child's summary is assertion-grade, never tool_execution evidence. Oracle every swarm claim against world state (read the artifact, run the check read-only); a user_requirement resting solely on a child summary is UNSURE at best.
Confidence is clamped by evidence tier in code: T0 caps at PARTIAL, T1 caps at VERIFIED, T2/T3 are PERFECT-eligible. Any code or filesystem task (any write/fs/exec tool_execution atom) REQUIRES T2; VERIFIED or PERFECT is forbidden on T0/T1 for it.
Full claim taxonomy, AtomicClaim shape, evidence-tier table, and the independence rule verbatim live in reference.md.
Done when: every claim id has a verdict. If any row is UNCHECKED, refuse PERFECT.
Step 5: Report (both CONFIDENCE and STATUS, or it is discarded)
Emit a ## Report. The parser requires these machine-parseable lines and rejects the whole report if CONFIDENCE:, STATUS:, or EVIDENCE_TIER: is missing:
Then a per-claim PASS/FAIL/UNSURE table (every claim id), and a ### Cost subsection from hermes_result.cost or hermes_task_cost (write unavailable if the bridge returned no cost block). Surface MoA cost as unreconciled, never authoritative $0, and do not sum per-loop snapshots (see reference.md).
CONFIDENCE
STATUS
Meaning
Action
PERFECT
verified
every claim verified
report done
VERIFIED
verified
all checked passed, minor gaps
report done
PARTIAL
verified
no failures, significant unverifiable gaps
report + note gaps
FEEDBACK
failed
failures found, correction sent
reloop
FAILED
unsure
cannot verify
escalate to human
Done when: the report has all three required lines, a full claim table, and cost.
Step 6: Reloop or finish
FEEDBACK: hermes_respond(session_id, corrective_prompt) (resumes the same Hermes session), then back to Step 2. Increment the loop counter.
max_loops default 3. At the cap, escalate to the user; no silent retry.
FAILED (cannot verify): escalate to the human.
VERIFIED or better: report done to the user.
Never hermes_respond to a failed task; there is no resumable session.
Bridge tools (base names; add your harness prefix)
