DEV Community: sunny yuen

You Don't Have to Learn Hermes From Scratch — I Brought My Existing Skills In

sunny yuen — Thu, 28 May 2026 21:41:06 +0000

This is a submission for the Hermes Agent Challenge: Write About Hermes Agent

I Didn't Start With Hermes

Six months ago I started building a set of agent skills and personas for how I build software. Not generic prompts — opinionated role files. A /backend-architect that owns schema and recommendation logic. A /test-engineer that writes Vitest coverage and flags weak acceptance criteria. A /project-manager that maintains planning docs and closes iterations cleanly.

These roles have evolved across multiple projects. They have layering rules, discovery checklists, inheritance from a base engineering discipline file. They produce consistent, reviewable work because they're scoped — the backend architect doesn't touch test files, the test engineer doesn't redesign the schema, each persona has a defined mandate and exits cleanly.

When I heard about Hermes Agent, my first instinct wasn't "let me learn a new system." It was: can I run my existing system inside this?

The answer is yes. That's what this article is about — what it looks like to bring a mature workflow into Hermes, what you gain, where it breaks down, and what I'd do differently.

What Hermes Is (and Isn't) to Someone Who Already Has a Workflow

Hermes is an LLM-agnostic orchestration layer. It has its own skill system, its own soul.md concept for persistent agent identity, built-in cron scheduling and MCP management. All of that is real and useful.

But it's also a runtime. If you have skills that work, you can bring them in.

I installed a local Hermes instance — few clicks, straightforward setup — and ran it inside VSCode's integrated terminal pointed at my existing persona files. No migration. No rewrite. My /backend-architect runs in Hermes the same way it runs in Claude Code.

Before settling on this, I'd tried a couple of other paths — a VPS instance with a Telegram interface for ideation, and attempting to build through a browser-based terminal. The VPS was fine for sketching ideas. The browser terminal made it clear that building production-grade tooling without proper local environment was the wrong path. Local Hermes in VSCode removed that friction.

The thing that surprised me: you don't have to choose between "learn Hermes natively" and "keep using what works." You can do both at once. Hermes becomes the runtime. Your skills stay the structure.

The Build: Production in 3 Days on a New System

The project I built with this setup is Brew Guide — a community coffee knowledge base exposed as a public MCP server. It logs real brew experiments, builds consensus recommendations from that data, and returns technique guidance (bloom timing, pour stages, agitation style) via 5 MCP tools. Production endpoint, no auth, live now.

I built it in 3 days — on Hermes, which I'd never used before.

That number is the point. Not because the build was simple (Neon Postgres, Prisma migrations, 55 passing tests, Railway auto-deploy, strict TypeScript throughout), but because I didn't spend those 3 days learning Hermes. I spent them building. The workflow did the heavy lifting on an unfamiliar runtime because the workflow was already mature.

The competition sprint — 7 deliverables including a scraper, technique JSONB on the schema, a landing page, and the competition article — reached "verified" on the first review pass. One iteration. That's the workflow functioning, not the AI being infallible.

What Breaks When You Switch Models

Here's the more interesting part, and I want to be honest about it.

During an earlier iteration, I ran the same skill set through a different model on the same codebase. Same persona files, same task scope, same Hermes orchestration. The goal: understand whether my workflow was portable across LLMs.

The observable failure mode was tool call adherence. The other model fumbled calls more often — retries, moments where it found its own path around the structured orchestration rather than following the skill specification. Tasks that took 30 minutes with Claude took most of a working day. The output required remediation: a Node version API call that crashed production, acceptance criteria tests that confirmed plumbing but not the scoring invariants the ACs required, docs that drifted from the code.

I want to be careful about what I can and can't claim. I wasn't using Hermes' native model adapters at the time — the skills were running through the same interface I'd built for Claude. So I can't say definitively whether the gap was model capability or a Hermes-model integration issue. Both are plausible.

What I can say: same instructions, same personas, dramatically different adherence to the spec. My skills were written and refined on Claude's way of parsing structured instructions. When you hand those same instructions to a model with different parsing behaviour, adherence degrades — and tool call reliability is the first thing to break.

This is the portability question Hermes is built to solve. It's a genuinely hard problem, and I didn't solve it. But surfacing where it breaks is the useful finding.

What I'd Build Differently

The gap I felt throughout came from one step I skipped: I never migrated my skills to native Hermes format.

Hermes has a soul.md concept — a persistent document that shapes agent identity across sessions. Think of it as the context your agent carries into every conversation: its values, working style, constraints. My skills work without it, but they're missing an anchor. A soul.md tuned to how I build — layering rules, persona boundaries, the engineering discipline that governs all my roles — would give Hermes native context that currently lives in my head, and make skills more robust across model handoffs.

The second missing step: model-specific skill validation. My skills assume Claude's instruction-following behaviour. A proper migration would test each persona against multiple model families and adjust language and structure where adherence breaks down. That's what "native Hermes skills" gives you — not just ported files, but skills validated against the runtime you're actually using.

The parts of Hermes where the DX is already smooth regardless: cron scheduling and hermes mcp add. Setting up the weekly coffee literature automation as a cron job was trivial. Connecting the production MCP endpoint to any client is one command. These infrastructure pieces are where Hermes earns its keep without needing any skill migration at all.

The Honest Verdict

Six months of evolved Claude skills beats Hermes' out-of-the-box defaults — for the way I specifically build software.

But that's the wrong comparison. The right question: does Hermes give you something you don't already have?

For me, two things.

LLM portability. The ability to run your skills against a local model, a different provider, without rebuilding anything. For production work with tight quality requirements, I want Claude's reliability. For experiments, local automations, cost-sensitive builds: Hermes makes the option real without a rewrite tax.

The infrastructure layer. Cron, MCP management, soul.md persistence. Not things you'd build for one project, but immediately useful once they exist.

What I'd tell a developer starting out: bring your existing workflow in first. Don't wait until you've learned Hermes natively before you build anything. Run your current skills, see what holds, see what breaks at the model boundary, and use that signal to decide what to migrate properly. The portability is the point — you don't earn it by starting over.

The project this workflow produced:

Web: brew-guide-production.up.railway.app — no login, try it now
MCP: https://brew-guide-production.up.railway.app/mcp
GitHub: yuens1002/brew-guide

Every Great Cup Starts with the Right Question — I Built the Community Behind the Answer with Hermes Agent

sunny yuen — Thu, 28 May 2026 21:29:01 +0000

This is a submission for the Hermes Agent Challenge: Build With Hermes Agent

What I Built

Real brewing knowledge lives in human experience — in roaster guides, in community notes, in what a barista learned from last Tuesday's pour. It doesn't accumulate anywhere. Every brew is forgotten. Ask any AI and you get statistical averages: 93°C, 1:16 ratio, four minutes. Technically defensible. Practically generic. Worse still for rare origins where training data is thin.

Demo

For coffee drinkers

Visit brew-guide-production.up.railway.app. No account. No setup. No AI client required.

Pick your coffee origin, roast level, and brew method. What comes back isn't a generic recipe — it's community consensus: the grind, temperature, ratio, and brew time that real people have logged and rated for that origin, plus step-by-step technique guidance (bloom timing, pour stages, agitation style). If data is sparse for your origin, the confidence tier says so honestly and falls back to method defaults rather than making something up.

This is for the person who just picked up a bag of Kenyan peaberry and wants to know how to do it justice. It works for anyone who cares about their cup — no technical knowledge required.

For developers and AI clients

Connect to any MCP-capable client in one line:

https://brew-guide-production.up.railway.app/mcp

Ask your AI: "recommend a pour over for Ethiopian light roast." What comes back is a traceable community consensus object: brew parameters, a confidence tier (high/medium/low), the source brews that contributed, and method-specific technique guidance. You can see where the knowledge came from and how certain the system is — a fundamentally different epistemic object from an AI-generated recipe.

Code

GitHub: yuens1002/brew-guide

Five MCP tools — get_brewing_methods, recommend, log_brew, search_brews, compare_brew — over Streamable HTTP transport. Public, no auth required.

My Tech Stack

Layer	Technology
HTTP	Hono 4 + `@hono/node-server`
MCP	`@modelcontextprotocol/sdk` + `@hono/mcp` (Streamable HTTP)
Database	Neon Postgres + Prisma ORM
Runtime	Node 24, TypeScript strict, ESM
Tests	Vitest (55 tests, 0 errors)
Deploy	Railway (auto-deploy from `main`)

The recommendation engine is fully deterministic — no LLM on the hot path. computeBestBrew() fetches up to 50 recent brews, scores each against your request params (origin, method, roast, variety, grind), applies recency decay (linear 1.0 → 0.1 over 365 days) and source trust weights, takes the top 5, and builds consensus via weighted average (numeric fields) or weighted mode (categorical). Sub-100ms. Reproducible. Auditable.

The voting infrastructure is live (thumbs_up/thumbs_down on recommendations, brew_recommendation_links tracking which brews followed which recommendations). Vote weighting inside computeBestBrew is the one acknowledged gap — the checks-and-balances mechanism is designed, the math isn't wired yet. That's the next commit.

How I Used Hermes Agent

I built this in 3 days — on a system I'd never used before.

That's the headline, and it's what I want to explain. I didn't start from scratch on Hermes. I installed a local instance, ran it inside VSCode's terminal, and pointed it at persona files I'd spent six months building. Three role files govern the entire build:

/backend-architect — owns schema design, the recommendation engine, all DB logic
/test-engineer — owns Vitest coverage, catches weak ACs, flags regressions
/project-manager — owns planning docs, retrospectives, and this article

Each persona has a focused mandate and a defined exit condition. The backend architect doesn't touch test files. The test engineer doesn't redesign the schema.

What the workflow looks like in practice:

Write a plan with a deliverable table (D1–D7), each with owner, files, acceptance criteria, commit schedule
Hand each deliverable to the relevant persona
After each feature, the test engineer verifies coverage and flags gaps
Review report before merge

The competition sprint — scraper, technique JSONB, landing page, this article — reached "verified" on the first review pass. 55 tests, zero TypeScript errors, all deliverables complete. One iteration.

The previous iteration of this codebase was run on a different model through the same Hermes setup. Similar scope, same skill set, same orchestration. That iteration required production hotfixes (a Node version API crash on Railway), remediation of weak acceptance criteria tests, and took the better part of a working day. The gap in tool call adherence — the other model fumbling calls and finding workarounds around the skill spec rather than through it — was the visible failure mode.

Hermes as a runtime made that comparison possible without changing anything in the workflow. Same skills, same personas, different model. The portability is the point.

Beyond orchestration, Hermes added two things directly: cron scheduling for the weekly coffee literature automation (hermes-automation/), and hermes mcp add for connecting the production endpoint to any client instantly. That MCP management DX is genuinely smooth.

What I'd build differently next time: migrate the skills to native Hermes format with a soul.md as a persistent identity anchor. The skills work as-is, but validating them against multiple model families — adjusting language and structure where tool call adherence degrades — is the proper portability work I didn't have time for. That's the experiment this project sets up.