v0.2.0 - Kanban-native runs

Hermes Workflows v0.2.0 - Kanban-native runs

A workflow run is now Kanban-native and chat-interactive: a node drives the real board card instead of spawning a parallel one, the operator resolves a review gate by simply replying in chat, a wait node blocks on an external signal (a merged PR) with zero idle workers, and long autonomous runs can go quiet - all on top of editor and run-observability polish.

What ships

Kanban-native execution

• Drive existing cards - an agent_task with adopt: true + task_ref assigns and promotes one or more real board cards (literal id or a typed {{nodes.X.output.task_ids}} reference) instead of creating new ones, gating on every driven card and failing loud on a missing one.
• Native review stage - an optional review_profile routes a finished driven card once through Hermes' own review status before the node settles.

Operator interaction

• Resolve a gate from chat - replying in the run's origin chat with approved / rejected / needs_changes (plus an optional note) routes to the paused run and confirms back, instead of being swallowed by the gateway agent.
• Operator note payload - a gate decision can carry a note, consumable downstream as {{nodes.<gate>.review_note}}.
• /workflow chat command - list / run / status / review / cancel / explain in the CLI and messengers.

Worker-free waits

• wait node - the engine tick polls github_pr_merged (gh pr view) with no Kanban card and no LLM worker; success on MERGED, failure on CLOSED, optional timeout. Retires the agent_task poll-loop stopgap.

Run health and lifecycle

• Blocked underlying cards are surfaced with one operator notice instead of hanging silently; status reads live card state so it no longer lags the tick; hermes-workflows cancel <run_id> stops a run from the shell.

Notifications, editor, authoring

• notifications.subscribe_cards: false silences per-card completion pings while keeping run-level notices; node-type icons on the canvas; the inspector opens read-only during a run; multiline spec strings round-trip as readable block scalars; script nodes always get HOME for credential CLIs.

Process wins

• The work is the real board card, so a run reuses the native dispatcher, review, and notifier rather than a parallel mechanism.
• The operator acts where they already are - chat or dashboard - and a long autonomous run costs zero idle workers and no notification noise.
• Every new field is additive and validated; specs round-trip losslessly.

Notes

• Instant GitHub-webhook resolution for the wait node and Telegram inline buttons for gates need upstream Hermes event-to-run wiring; they are declared and documented, not stubbed.
• Host-gated firing aside, everything here works today via the engine tick, the CLI, and chat.

v0.1.0 - Workflows on Hermes natives

Hermes Workflows v0.1.0 - Workflows on Hermes natives

The first release of Hermes Workflows - a dashboard plugin for Hermes Agent that lets you draw a multi-step automation as a graph and run it on Hermes' own primitives, with a human in the loop only where you put one. It is not a second engine: every node compiles to a native Hermes Kanban card, Cron job, or profile run, so a workflow is something you can read, schedule, deliver, and observe with the tools Hermes already gives you. Where a single scheduled prompt (an Automation Blueprint) isn't enough, a workflow is the layer above it.

What ships

• Visual authoring lifecycle. Create a workflow from a modal, grow the graph in an @xyflow/react editor (every node field, duplicate, auto-layout), validate, preview the compiled Hermes plan, then press Play to run it in place - the canvas shows live per-node progress and hands off to the run inspector when it settles.
• Five node types. agent_task (a prompt assigned to a profile, with a per-node model and skills picked from the host /api/skills catalog), script (a deterministic shell step, gated by an enable flag and an env allowlist), condition (branch on a node outcome or a review decision), human_review (pause for a channel-agnostic decision), and finish.
• Triggers. manual, cron, and declarable webhook / github / api event triggers.
• Inter-node data flow. A node consumes a prior node's output via input_mapping: { x: "{{nodes.<id>.output}}" }, substituted at schedule time and failing loud if an expected output never materialised - the workflow stays portable, no host path baked in.
• First-class delivery. A workflow declares where its result is delivered (Hermes DeliveryTarget syntax, or origin); a result containing [SILENT] suppresses delivery so nothing-to-say runs stay quiet.
• Runs, Schedules, Settings. Open / cancel / retry / export-logs; pause / resume / run-now / edit cron schedules (tagged Workflow, distinct from blueprint jobs); a settings view backed by the Hermes config. Runs are single-flight.
• Observability. Per-node telemetry (duration, tokens, tool calls, errors), pending dangerous-command approvals, and an opt-in per-run JSONL trace.

Built on Hermes natives

flowchart LR
    WF["Workflow graph"] -->|compiles to, no second engine| N["Kanban · Cron · Profiles · delivery router · /api/skills"]
    N --> Run["Autonomous run<br/>branching · data flow · review gates"]
    Run -->|"result (or [SILENT])"| Ch["your channel"]
    style WF fill:#5d3a9b,stroke:#ce93d8,color:#fff
    style N fill:#1e3a5f,stroke:#90caf9,color:#fff

The TypeScript engine is the single interpreter of the spec; the Python orchestrator only executes its decisions. Cron runs through cron.jobs, delivery through the gateway's own router, skills from the host catalog - there is no parallel runtime to learn or trust.

Notes

• Native alignment with Automation Blueprints. Workflows reuse the same primitives and conventions as Hermes blueprints (delivery + [SILENT], the /api/skills catalog, typed template parameters that render across surfaces, and the Schedules surface).
• Host-gated, deferred upstream (no stubs): firing an event trigger and the live /workflow slash command + hermes:// deep-link need host handlers the plugin cannot add - the host webhook system dispatches events only to agent prompts / direct delivery, and cron.jobs.create_job is time-only. v0.1.0 ships the real, tested schema and pure emitters those surfaces will consume.

Install

hermes plugins install itechmeat/hermes-workflows --enable
hermes gateway restart

Open the Workflows tab and create your first graph. Full tour: the README and docs/.