Comparison
Kanban skill vs.
Hermes Agent Kanban
Two agent-facing kanban boards with a lot of overlap. The difference is where the board sits in the stack: the kanban skill is a lean board layer you run any agent on top of; Hermes Agent Kanban fuses that board into its own runtime.
A plain-Markdown board in your repo. The runtime, execution, and even maintenance layer on top — swap the agent, keep the board.
Hermes Agent KanbanThe board, dispatcher, and named agents are one integrated runtime — durable and bundled, but the board doesn't detach from Hermes.
So why not just use Hermes Kanban?
Fair question — the two overlap a lot. Both are kanban boards agents plan and work from, so think of the kanban skill as a lightweight alternative to Hermes Kanban: the same board idea, minus the bundled runtime. The difference is what's underneath.
Kanban skill — a board made of files
- Plain Markdown in your repo — every task and plan change is a reviewable diff.
- No infrastructure: nothing to install, nothing to keep running.
- Execution comes from whatever harness you already use — Claude Code, Codex, Cursor, even Hermes.
Hermes Kanban — a board inside a runtime
- A durable SQLite queue at ~/.hermes/kanban.db, shared by many named agents and humans.
- A dispatcher hands ready tasks to agents and recovers crashed runs.
- Tied to the Hermes / Nous stack and its kanban_* tools.
When to use the kanban skill
Pick the skill when you want the board versioned with your code, when you're staying in a harness you already run, or when you don't want to operate a runtime just to get a task board. Reach for Hermes Kanban when you already work deeply with Hermes — its board plugs straight into the dispatcher, named profiles, and chat control you've set up. Both are durable queues in the end; the skill's is files in git, Hermes's is rows in SQLite.
Which agents can run the board?
The clearest single difference. The skill's board is plain files, so any agent that can read a repo can run it — including Hermes itself. Hermes Kanban's board sits behind the runtime's kanban_* tools, so only Hermes can.
OpenClawHermesany file-reading agent
Hermes only
…and the skill's row keeps going — Windsurf, OpenCode, Gemini CLI, anything that reads files. Hermes Kanban has no way in for other agents.
Kanban skill vs. Hermes Kanban
A is a clear win; a dash is a trade-off. The skill wins on simplicity and portability, Hermes on the durable shared queue and scale — the rest is a draw.
A file-based kanban layer — the board is plain Markdown in your repo.
A kanban feature of the Hermes agent runtime — a durable SQLite board.
None of its own — the board is just plain Markdown files in your repo.
A running gateway, a SQLite database, and a dispatcher loop.
In your repo, under version control — every task and plan change is a reviewable diff.
In a SQLite DB at ~/.hermes/kanban.db; changes go to an event log, not diffs.
One prompt: a skill file and a small script.
Install the Hermes runtime, configure profiles, run the gateway.
Your harness drives it — Claude Code spawns parallel subagents when you kick things off; scheduled jobs live in a recurring/ folder.
The runtime drives it — the dispatcher picks up ready tasks on its own and spawns a worker process per task.
No per-task queue — a run that dies mid-task just reruns on the next scheduled tick.
A durable queue auto-recovers in-flight work — claim TTLs, heartbeats, stale-claim reclaim, retries.
A card breaks into todos and a task graph — group, blocked-by, related — with deps worked out as it's written.
The dispatcher auto-runs an LLM decomposer, fanning a task into a child-task graph routed to specialists.
Memory is pruned to why-rejected and what-shipped so the agent proposes forward — curated, not a full log.
Keeps a full append-only event log and per-attempt run history for audit.
A local web board where card actions — implement, review, archive — hand the work to an agent.
A live web board with drag-drop and a side drawer, plus control from chat apps.
A solo board; grep gets unwieldy as it grows.
Scales to many agents across many boards — multi-tenant, with control from Discord / Slack / email / SMS.
What each board remembers
The essential difference: the skill's memory is an input to planning — it exists so the next proposal is smarter. Hermes's log is an output of execution — it exists so the past can be replayed.
Kanban skill
Remembers conclusions, forgets the rest.
Four small files, pruned on purpose: archive.md (what shipped), rejected.md (what we turned down, and why), redesign.md (design mistakes not to repeat), memory.md (what past scans learned). The agent reads them all before proposing or writing a card; the full history is git's job.
“Why isn't idea X on the board?”
One line in rejected.md — the idea and why it was turned down. Dead ideas stay dead.
Hermes Kanban
Remembers every event, summarizes nothing.
Every state transition lands in an append-only log; every attempt keeps its exit code and full worker output. Built for audit and crash recovery, not for steering the next idea.
“What happened to task 42 overnight?”
claimed → crashed → reclaimed → completed, with per-attempt logs to read.
Curated memory makes the agent smarter next time; the audit log makes the past reconstructable. Neither substitutes for the other.
Kanban Board GUI
Both ship a web board, but they play different roles. The skill's board is a control surface for your agent — card actions kick off runs. Hermes's board is a live window onto the dispatcher — it shows what the fleet is doing right now.
Kanban skill — local board
A local web board over the Markdown files. Card actions — implement, review, archive — hand the work to an agent, and you watch its log stream back with human-in-the-loop prompts.
Hermes Kanban — live dispatcher view
A live board that tails the event log — drag-drop between columns, a side drawer with run history and exit-status badges, and the same board steerable from Discord, Slack, or SMS.
Where each one wins
Neither is strictly better. The kanban skill optimizes for a lean, file-based board with no infra of its own; Hermes Kanban optimizes for a durable, shared work queue that many agents run against, unattended. Harness features — parallel runs, orchestration, a dashboard — are on both sides, so they aren't listed here.
Kanban skill
No infrastructure of its own
No database, no gateway, no daemon. Beyond the agent you already run, the board is plain Markdown files — nothing extra to install or keep alive, works on a plane.
Files you can diff and version
The board lives in the repo and travels with it, under whatever version control you use. Every task and plan change is a reviewable diff — no SQLite outside your project, no event log to query, no lock-in to one agent stack.
Memory that self-prunes
It records why an idea was rejected and what got shipped, so the agent proposes forward instead of re-floating dead work. It keeps only what steers the next task, not a full audit log.
Installs in one prompt
A skill file and a small script — no profiles to configure, no dispatcher to tune. It meets any file-reading agent where it already is, Hermes included.
Hermes Kanban
One board, many named agents
A single durable board that multiple named agents — and humans — claim tasks and hand off work on. The dispatcher polls ready tasks and spawns the assigned agent for each. The skill's board is driven by whatever single harness you're in.
Self-healing task queue
The queue tracks each task through crashes: claim TTLs, heartbeats, stale-claim reclaim, retries, and circuit breakers. A worker can die mid-task and the board reclaims and retries it — the skill's files are durable, but a dead run just waits for the next scheduled tick.
Auto-decomposes tasks
Drop in a rough task and the dispatcher's LLM decomposer fans it into a child-task graph, each child routed to a specialist agent — no manual breakdown. The skill splits a card into todos and a hand-tended task graph.
Fleet reach and scale
Built for many agents across many boards, multi-tenant, with control from Discord, Telegram, Slack, email, and SMS. The skill is a lean solo board that stays in your repo and terminal.
Which should you use?
Reach for the kanban skill when
- You want a file-based board — every task and plan change is a reviewable diff.
- You want no infra of its own: plain files, offline, portable, no lock-in.
- You want it agent-agnostic — Claude Code, Cursor, even Hermes itself.
- You're solo and value a lean board over a bundled engine.
Reach for Hermes Kanban when
- You already work deeply with Hermes — profiles, gateway, and chat control are set up.
- You want one durable board that many named agents — and people — share.
- You want a queue that auto-recovers in-flight tasks across crashes.
- You want the dispatcher to auto-decompose tasks and route them to specialists.
- You run fleet workloads across many boards and chat platforms.
They overlap more than the names suggest — both are agent kanban boards. The split is what's bundled: the kanban skill is a file-based board with automation left to your harness; Hermes Agent Kanban is that board wrapped in a durable, shared work queue. If you want one board many agents share, surviving crashes, use Hermes. If you want a lean board in your repo you extend only when you need to, use the kanban skill.
They can even sit side by side — the skill as the lightweight place you plan and prune in git, Hermes as the durable queue that runs the heavy, shared work once you've decided what it is.