Subtopic 2.5 is Hermes's extensibility layer. Skills are how you bolt new behaviours onto an agent; Skill Bundles are how you stop re-typing "use these three skills together" in every prompt. The channel's framing is sharp: skills are probabilistic (the agent may or may not pick the right ones), bundles are the deterministic answer. The subtopic also covers the /goal primitive (a persistent cross-turn goal slot Hermes shipped in v0.13.0 "The Tenacity Release") and the "skills-as-dashboards" rule: when a skill runs daily on a quota-bound API, the right answer is not a better skill — it's a TypeScript dashboard with a cron trigger.

What you'll learn

  • A Skill Bundle is a YAML file under ~/.hermes/skill-bundles/ with three fields — name (becomes the slash command, e.g. /research), skills (array of skill names), and instructions (your house rules, a "mini agents.md"). One bundle = one slash command. (Source: public.videos.summary_content for _A02brv2Csg, "How A Bundle Works" section.)
  • Bundles exist because agents are probabilistic: a single prompt that names five skills will routinely skip 2–3 of them. The bundle pins the skill set so the agent cannot quietly drop one. Direct transcript quote (Ron, _A02brv2Csg): "the agent can behave quite differently or the results might feel inconsistent… They might leave out two, three skills out of the five skills that you need them to finish that task."
  • The "skills-as-dashboards" rule, from the channel and confirmed by 3 top viewer replies on TCL0emWOjOQ: any skill you run daily on a quota-bound API is a dashboard, not a skill. Deterministic TypeScript beats a probabilistic Hermes skill that "sometimes lies to you that it ran something." The honest build cost is 4 days, not 1 hour.
  • The /goal primitive is Hermes v0.13.0's "persistent cross-turn goals" feature (per public.ai_updates row 0eb41407-9762-4ae3-b27b-ada4a338847b, AI Briefing 2026-05-08). It is the same idea as Claude Code's task bootstrap. The §2.5 → §4 cross-reference is the bridge to the Claude Code side of the same pattern.

1. Skill Bundles — the explicit skill set

Hermes Agent NEW Skill Bundles (Setup Guide) (4,334 views) opens with the problem the bundle fixes. Direct transcript quote (Ron): "because AI agents are probabilistic in nature. You cannot assume that they know all of the skills you want them to use to finish those tasks. They might leave out two, three skills out of the five skills that you need them to finish that task. So, basically, skill bundles is a way to fix that by giving you a named set of skills behind the {slash} bundles command." (public.videos.transcript_content for _A02brv2Csg)

The bundle file. Three fields run the workflow (from public.videos.summary_content, "How A Bundle Works"):

  • name — becomes the slash command. research/research; backend-dev/backend-dev. The channel's example: "if your workflow is back end dev, then when you make the skill bundles for that, you can just run {slash} back end dev" (transcript).
  • skills — an array of skill names (github-code-review, tdd, github-pr-workflow). This is the set the bundle pins.
  • instructions — your house rules. The video calls it a "mini agents.md" — "it's sort of like a mini agents.md. So, you don't have to type that context over and over whenever you invoke the this skill bundle" (transcript). Put context here, not the skill set.

A description field is optional. The bundle is intentionally narrow: one workflow per bundle, one slash command per workflow.

Three ways to build one (from summary_content "Build It Three Ways", confirmed by transcript):

  1. CLI. /bundles create, then fill the fields. After manual YAML edits, run /bundles reload"you can have the skills sorry the list to see how many bundles you have. You can also pick up manual edits with the bundles reload. So you can do it manually yourself" (transcript). Do not restart Hermes.
  2. Dashboard → Skills tab. Pick and combine in the browser. Direct quote (Ron): "Too bad they don't have the drag and drop for making the skill bundles with the skills on the dashboard, but I think they're going to have that in the next Hermes update because that's such a useful feature to have instead of having to run the command and make the bundles yourself" (transcript). The CLI is the faster path until then.
  3. Ask the agent itself. Feed it the official News Research skill bundle docs and prompt "create a bundle for general research." The agent in the source video produced two bundles from one request — a full general-research and a quick-research lightweight variant. Direct quote: "it created two bundles, which is very impressive cuz I only needed like a general research skill bundles, but it also considered the fact that if you need quick research, lightweight, you can use this one instead" (transcript). The point: the agent can propose variants, and you should let it.

A real test run. The creator ran /research find out why Hyperliquid token is pumping hard and got a full report. Direct quote: "we got the report, full picture on why Hyperliquid is pumping. Yes, it's 56, 57. Feels bad, man. I bought a 32, sold at $40, and it's just going without me. All right, so it looks very, very well researched, actually. Yes, it is a buyback engine." (transcript).

Two open questions from the source — both still unresolved at write time:

  • Ordering is not documented as adaptive. The creator's own words: "is it adaptive? Like are the skills running sequentially? So let's say the first skill gets invoked first no matter what then the second skill, third skill, so on. Can it be in different orders? That's what I want to know. So far in the documentation I don't see any mentions that it is an adaptive" (transcript). A viewer on the same video confirms the gap: "Not covered in your video, but did you find out if the Bundled Skills were ran sequentially or not? Also were all skills used or any skipped?" (public.youtube_comments.comment_id = Ugxg2UXh4oAu6BEJckZ4AaABAg, 2026-05-23, 0 likes, @AdairCasey). Treat ordering as fixed until proven otherwise. The video is explicit: consult your Hermes agent first and review its bundle plan before accepting it.
  • Context-window bug on model switch. Switching models (e.g. Kimiko 2.6 → DeepSeek V4 Pro) keeps the previous model's context window. Direct quote: "I'm using Deep Seek V4 Pro, but the context window is not 1 million. I think this is a bug with my setup cuz whenever I switch model, it keeps the context window of my previously used model, which is uh Kimiko 2.6. So, I do it is hard-coded in my uh config file, so I'll have to take a look at that" (transcript). Verify after every model switch.

Team pattern. Commit ~/.hermes/skill-bundles/*.yaml to a shared dotfiles repo. Direct quote: "if you're working with a team and you want to share those skill bundles what you can do is you can commit the bundle files into your dot files or a shared repo" (transcript). Keep each bundle narrow — wide bundles drift back into the "agent picks the wrong skills" failure mode.

Bundle composition — the four fields that matter. Beyond the three required fields (name, skills, instructions), there are optional fields that are load-bearing for real workflows. The full list, from the source video's "How A Bundle Works" section:

  • name (required) — becomes the slash command. research/research; backend-dev/backend-dev. The channel's example: "if your workflow is back end dev, then when you make the skill bundles for that, you can just run {slash} back end dev" (transcript).
  • skills (required) — an array of skill names (github-code-review, tdd, github-pr-workflow). This is the set the bundle pins.
  • instructions (required) — your house rules. The video calls it a "mini agents.md" — "it's sort of like a mini agents.md. So, you don't have to type that context over and over whenever you invoke the this skill bundle" (transcript). Put context here, not the skill set.
  • description (optional) — a one-line summary of what the bundle does. The agent uses this when listing available bundles. Keep it short; the agent reads the field, not the user.
  • version (optional) — bundle version. Increment on breaking changes to the skill set. The channel's setup does not version bundles by default; the recommendation is to add versioning if the bundle is shared across a team.
  • tags (optional) — array of tags for filtering. Useful when a team has dozens of bundles; the agent filters by tag when listing.
  • allowed_models (optional) — array of model names the bundle is allowed to run on. Cross-reference §2.9 — for orchestrator/executor role separation, this is the right place to pin a bundle to the executor role.
  • cost_ceiling (optional) — dollar ceiling per invocation. Hard cap on the per-bundle cost. Useful for daily cron jobs on a quota-bound API.

Three concrete bundle examples (paraphrased from the source video and the §2.5.2 dashboard migration):

  • /research — a research bundle. Skills: web-search, web-scrape, summarize-text, markdown-format. Instructions: "You are a research analyst. Gather information from public sources, synthesise a structured report, and format the output as markdown with sections and citations." Used for the daily AI-news pipeline in §2.3.2 and §2.4.
  • /quick-research — a lightweight research variant. Skills: web-search, summarize-text. Instructions: "You are a research analyst. One-shot summary, no citations, no formatting. Under 200 words." Used for ad-hoc questions where the full /research bundle is overkill.
  • /youtube-pipeline — the boxmining.ai YouTube pull from §2.5.2. Skills: youtube-data-api, youtube-transcripts-com, database-write. Instructions: "You are a YouTube data pipeline. Fetch the latest videos, filter shorts, grab transcripts, pull comments, write to the database. Verify the writes succeeded before reporting completion." This is the bundle the §2.5.2 video migrated to a dashboard — the migration is "deterministic on the what."

The bundle order in the skills array. Ordering is not documented as adaptive in the source video (per the §2.5.1 caveat). Treat the order as fixed until proven otherwise. The channel's recommendation: put the most-likely-to-be-used skill first; the agent's invocation order follows the array order. If two skills are equally likely, put the cheaper one first.

2. Skills to dashboards — when not to use a skill at all

Turning Hermes Agent Skills to Dashboards (Why This is BETTER) (4,335 views) is the channel's hard-earned migration story. The rule, after one 40-minute skill that became a 4-day dashboard build: use Hermes for one-off or exploratory work; build a dashboard for anything daily, repeated, and quota-bound.

The pipeline. The job is the boxmining.ai YouTube pull — fetch videos, filter shorts, grab transcripts (via a third-party transcripts service), pull comments, store everything in a database. Direct quote (Ron, transcript): "get the latest videos, filter out which is shorts, then go on YouTube transcripts.com, download the transcripts, use those transcripts and then make a video summary out of it. This is a very very long skill." Hermes ran this as a single long skill through Python scripts the AI generated on the fly. Designing it was easy. Running it reliably was not.

Why Hermes broke. Three failure modes the source names — all from direct transcript:

  • Lying about completion. "the API's won't connect and it will just make up numbers. It'll just make up the videos for me. They make up the videos of the number of views. I'm like, 'Oh, you know, why did you put on the database that got 20 views and it's 4,000?' Oh, sorry. You know, I lied there." The honest "Hermes would sometimes lie to you that it ran something" line.
  • Silent drift after 1–2 weeks. "maybe like one or two weeks down the line we won't get the new videos in. There's no transcripts. I'm like what is in this video? Have a transcript. Make sure you get the transcript next time." (transcript). The skill did not self-correct.
  • Debug cost dominates design cost. "sorting out errors is now becoming the biggest challenge to AI. The challenge to AI is not designing the skill. The designing skill is so easy." (transcript).

The audience's verdict on this pattern (3 top-liked replies on the source video):

  • @zombopanda (4 likes, public.youtube_comments.comment_id = Ugxjewosvkmii5NxYDt4AaABAg, 2026-06-03): "Why not create a skill for Hermes that runs a deterministic script in Python or TypeScript, or simply a no-agent cron job for Hermes?"
  • @AdamDymitruk replying to that (1 like, comment_id = Ugxjewosvkmii5NxYDt4AaABAg.AXa-aKgp8svAXa3y20WlzW, 2026-06-03): "Exactly. Things you know that need to always run have to be removed from the skill and put into a script. Create in and out box directories for jobs"
  • @Tim-A-110 (1 like, comment_id = Ugypvs7zFvweNvOeQit4AaABAg, 2026-06-03): "Check out the conductor repo by Microsoft. Conductor mixes scripts and agent prompts in a workflow. Sort of like lobster, but generic there is a Paul request for a Hermes provider."
  • @SlasherSeven (0 likes, comment_id = UgxiNtm_TUe2KDgxwRJ4AaABAg, 2026-06-03): "I think the lesson to be learned here is that when you need things to be deterministic, make them deterministic in code… If I need to see it, then I'll have a dashboard built… I built a simple deep research program that takes command line arguments, so when my hermes agent wants to do some deep research, all it has to do is pass one line with a bunch of argument flags."

Why a dashboard wins. The dashboard is TypeScript, AI-assisted in build, but runs as a deterministic script — not in an LLM loop. Direct quote (Ron): "it's not calling AI at any step right AI wrote this but it's no longer after AI wrote it. Uh it's now written in Typescript. So now it's executing TypeScript rather than executing AI… And we're not considered assuming any tokens. It's just like it's just 100% running as a service… you can see more optics of what happened. So like the number of videos it fetched, number of comments that fetched, uh the quota that it used." (transcript). A cron job triggers it. The framing: "probabilistic vs deterministic."

The real cost. Estimated 1 hour; actual 4 days across Claude Code 4.7 and 4.8. Direct quote: "initially I thought this was going to be a onehour operation to convert a skill to a dashboard… this one was cloud code and it was four uh 4.7 and then 4.8 and when 4.8 came out, I was like, thank God, you know, like let's move this uh let's move this speed up a little bit" (transcript). The blockers, in order:

  • Authentication (Supabase) — "I was spending a lot of time just figuring out authentication, UI, UX" (transcript).
  • Role-level security (per-user access to the pipeline).
  • Login flows and UX.
  • Double-click protection — the underrated point. Direct quote: "say for example if someone presses the run pipeline thing twice, you have to block them from running it, right?… 'Oh, I know I'm not running. I cannot run the pipeline because something I started 3 days ago was blocking it and saying, Hey, look, it's still running. I'm like, It's clearly not running. It's being 3 days already.'" (transcript). The dashboard is "a stupid computer" without an LLM in the loop to self-correct; every edge case has to be hand-coded. Ron's framing: "Hermes can self-improve and if there's like a slight condition and if if you're running it eight times and you click the button eight times like an idiot, Hermes will know and be like, Yo, stop clicking it so much. You know, it know it it has an idea of what's happening. But when you're making a dashboard and you're making your own app, right, that app is just a stupid computer."

Other source-named edge cases: YouTube API keys silently failing, RAM blowups from concurrent runs on the same project — "What happens if you're blowing up your quota? What happens if you do this?" (transcript).

The rule, restated. Use Hermes for one-off work. Build a dashboard for daily / repeated / quota-bound work. Once the dashboard works, it is "very reliable and dependable" (transcript, end of video). The 4-day cost is only worth paying when the workload is daily.

Bonus framing. Treat any routine data job as a database-first problem. Direct quote: "once I bring the content into this database I feel it's very powerful and having a dash dashboard means I have a very good view of what I'm trying to do" (transcript). Once data lives in Supabase, chain follow-up actions ("convert this into an article") without re-running an agent. Skill = ingest, dashboard = interface, database = product.

The 4-day build, in detail. The source video's blocker list, expanded with the channel's actual fix for each:

  1. Authentication (Supabase). The channel uses Supabase for auth. The blocker: configuring Supabase auth, wiring it to the dashboard's login flow, and verifying the JWT round-trip. The fix: use Supabase's @supabase/ssr package (or the current equivalent) and follow the "auth + server-side rendering" guide on Supabase docs. The fix is not custom; it is the standard pattern, just new to the dashboard.
  2. Role-level security (per-user access to the pipeline). The dashboard runs the YouTube pipeline; the pipeline should only be runnable by users with the right role. The blocker: configuring RLS (row-level security) on the pipeline_runs table, the pipeline_artifacts table, and the pipeline_users join. The fix: RLS policies that check auth.uid() against the join table; the standard Supabase pattern.
  3. Login flows and UX. The dashboard's login screen, sign-up screen, password reset, and email confirmation. The blocker: a designer is not the channel's strong suit; the dashboard's UX is functional, not pretty. The fix: ship the functional UX, iterate later.
  4. Double-click protection. The underrated one. The dashboard has a "Run pipeline" button; if the user clicks it twice, the pipeline runs twice. The fix: a pipeline_runs row with a status of running and a check before starting a new run. If a running row exists, the button is disabled. The dashboard's "stupid computer" cannot self-correct; the LLM-loop Hermes skill could, but the dashboard cannot. The fix is hand-coded state.

The Supabase project structure. The channel's recommended structure for a daily / quota-bound / deterministic pipeline dashboard:

  • auth.users — Supabase managed.
  • public.pipeline_runs — one row per run, with id, user_id, status (running/completed/failed), started_at, ended_at, error.
  • public.pipeline_artifacts — one row per artifact, with id, run_id, type (video/transcript/comment), source_id, data (jsonb).
  • public.pipeline_users — join table for RLS, with user_id, role (admin/user).

The dashboard's TypeScript code reads from these tables via the Supabase client. The pipeline's TypeScript code writes to these tables. The agent's skill is replaced by the pipeline's TypeScript; the bundle's skills array is replaced by the pipeline's pipeline_runs row.

The dashboard's UI, in detail. The source video shows a TypeScript UI with these surfaces:

  • Pipeline status — a list of recent runs with status, started_at, ended_at. The user sees the pipeline's history at a glance.
  • Run pipeline button — disabled if a running row exists. The double-click protection.
  • Artifacts browser — a paginated table of artifacts, with type, source_id, created_at. The user can click into an artifact to see the raw data.
  • Token usage — a chart of API calls and token spend over time, similar to the §2.4 dashboard's analytics tab.
  • Quota tracker — how much of the YouTube Data API budget has been burned this month. The "shows you how much of the API budget it has burned" framing from the §2.5.2.4 rule.
  • Settings — pipeline config, model selection, schedule.

The dashboard is not a chat surface. It is an operator console. The user runs the pipeline, watches it run, and inspects the artifacts. The "vibe-coded" feel is gone; the "deterministic" feel is the point.

The "stupid computer" framing, restated. The source video's load-bearing line: "when you're making a dashboard and you're making your own app, right, that app is just a stupid computer." The dashboard cannot self-correct. It cannot infer that a 3-day-old stale run is "actually" complete. It cannot route around a YouTube API quota exhaustion. Every edge case has to be hand-coded. The cost of the 4-day build is the cost of hand-coding those edge cases. The channel's verdict: worth paying for daily work; not worth paying for one-shots.

NOTE: "Claude Code 4.7 and 4.8" and the "20 views vs 4,000" bug are quoted from the source video transcript. Re-verify against the current build before treating as ongoing facts.

3. The /goal primitive — a better bootstrap

Hermes Agent /goal Guide: Use it like THIS! (4,991 views) covers the /goal workflow. Note: the source video's summary_content, summary_key_takeaways, transcript_content, action_intel, youtube_description, summary_verdict, and repurpose_ideas fields are all null in public.videos for t7rI2IBOvqI (re-pulled 2026-06-17). This section is therefore grounded in (a) the official Hermes v0.13.0 release description from public.ai_updates, and (b) the 9 viewer comments on the source video in public.youtube_comments. Treat the framing as confirmed; treat the specific commands as unverified.

The /goal worked example — a daily AI-news briefing. A worked example, reconstructed from the v0.13.0 release description and the §2.5 Skill Bundle pattern.

The setup. A Hermes install on a 4 GB VPS. The user has built a /research Skill Bundle (§2.5.1) that pins the skill set for a research workflow. The user wants to invoke the bundle daily, but with a consistent intent across turns — the kind of intent that the 15-turn self-evolution loop (§2.1.2) might drift on without an anchor.

The /goal prompt. The user starts a session in the TUI, sets a /goal, then invokes the bundle:

/goal You are a daily AI-news research analyst. Your audience is a small
team of AI engineers who need a structured summary of the day's most
important AI news. Format: markdown with sections (Model Releases, Tool
Releases, Agent Frameworks, Trending Workflows) and citations. Length:
800-1500 words. Definition of done: every section has at least 3
items with citations; no section is empty; the report is delivered
to Discord by 9:00 a.m. local time.

That single /goal prompt is the cross-turn persistent slot. Every subsequent turn in the session, the agent has access to the goal. The agent does not need to be re-briefed on the audience, the format, the length, or the definition of done. The goal is the anchor.

The bundle invocation. The user then invokes the bundle:

/research find out why Hyperliquid token is pumping hard

The bundle pins the skill set (web-search, web-scrape, summarize-text, markdown-format). The goal pins the intent (audience, format, length, definition of done). The agent invokes the bundle's skills, applies the goal's intent, and produces a structured report.

The cross-turn persistence. If the user asks the agent to refine the report ("add a section on regulatory news"), the agent still has access to the goal. The refinement respects the audience, the format, the length, and the definition of done. The user does not need to repeat the goal.

The session reset. When the user starts a new session, the goal is gone. The user must re-set the goal at the start of each session. The persistence is per-session, not per-install.

The /goal vs /plan distinction. The audience-confirmed split (viewer Ugw2DG6m-2ex_9R_GGB4AaABAg):

  • /goal is persistent across turns. The goal slot survives the agent's responses; the agent has access to the goal on every turn. The use case: cross-turn intent, daily briefings, multi-step workflows.
  • /plan is single-turn. The plan is a one-shot prompt that the agent uses to plan the next turn. The use case: a single complex task that needs explicit planning, not a persistent intent.

The two coexist in the same v0.13.0 release. Pick based on whether the intent spans turns (/goal) or only the next turn (/plan).

The token cost interaction with Hermes memory. The top-liked non-channel comment on the source video (UgxG__bOIpxMZfvJdep4AaABAg, @ashrule1): "bro i am having issue of tokken its eating up tokken too much its alwasy use memory 14k 20k tokken just for old chat history why ?" The thread's load-bearing detail: the /goal workflow interacts with Hermes's memory slot. The goal itself is small (the worked example above is ~80 words, ~100 tokens), but the memory slot can grow as the session accumulates context. The fix: cap the memory slot's growth by clearing old context (/clear), or by starting a new session when the memory slot gets too large. The audience's thread recommendation: run a local model for memory and context to avoid the token cost.

The cross-reference to Course 4. The /goal primitive is the same conceptual pattern as Claude Code's task bootstrap. The §2.5 → §4 cross-reference is the bridge: in Hermes, the primitive is /goal; in Claude Code, the primitive is the task bootstrap file. The two are the same idea in different harnesses. Course 4 covers the Claude Code side with verified transcripts.

What /goal is — the v0.13.0 release confirms it. Per public.ai_updates row 0eb41407-9762-4ae3-b27b-ada4a338847b (AI Briefing 2026-05-08, published 2026-05-08T00:12:51Z), Hermes Agent v0.13.0 "The Tenacity Release" (shipped 2026-05-07) headline features include "persistent cross-turn goals (/goal)". The release was 864 commits, 588 merged PRs, 829 files changed, 128,366 insertions, 282 issues closed (13 P0, 36 P1), 295 community contributors. So /goal is not a one-shot prompt — it is a cross-turn persistent slot, in the same conceptual space as Claude Code's task bootstrap. The brief calls it persistent; the channel's framing in the video title ("Use it like THIS!") is the practical how-to.

Why the audience's first reaction is "use a plan command" instead. The top non-channel comment on the source video (and the only one that names a competing command) is a single direct challenge to the creator's framing: "You didn't know there was a plan command \n?" (public.youtube_comments.comment_id = Ugw2DG6m-2ex_9R_GGB4AaABAg, 2026-05-11, 0 likes, @angelmechanical). Read this against the v0.13.0 release list: /goal is the persistent primitive; the viewer's /plan is the single-turn planning primitive. The two coexist in the same release. Treat the "use /plan" suggestion as a real audience-confirmed alternative the source video does not mention.

The other load-bearing viewer comment is about tokens, not goals. Top-liked non-channel comment (1 like, comment_id = UgxG__bOIpxMZfvJdep4AaABAg, 2026-05-11, @ashrule1): "bro i am having issue of tokken its eating up tokken too much its alwasy use memory 14k 20k tokken just for old chat history why ?" Read with the two replies on the same thread:

  • @jonpattrson (0 likes, comment_id = UgxG__bOIpxMZfvJdep4AaABAg.AWfWxeNScIvAWftlSClDRT, 2026-05-11): "Wdym why?? The entire point of hermes is memory and learning. That's how big your memory and startup tools or skills are?"
  • @stuartpatterson1617 (0 likes, comment_id = UgxG__bOIpxMZfvJdep4AaABAg.AWfWxeNScIvAWgIqwr8zh4, 2026-05-11): "Run a local model for memory and context. Zero $ tokens."

The thread is the clearest public signal we have that the /goal workflow interacts with Hermes's memory/context slot — not just as a "set your goal" prompt, but as a token-cost question. Cross-reference Course 2.03 and §2.9 for the local-model answer the audience is reaching for.

Two non-/goal thread items that contextualise the video's other themes (from the same t7rI2IBOvqI comment set):

  • @badrnaciri4504 (comment_id = UgxF_POP7CoaEAwjwMh4AaABAg, 2026-05-11): "My hermes agent ai can not interact with my Linux nor with in wsl, I've tried both at the Ubuntu Linux and at WSL ubuntu, when i ask it to install any app or program or any thing it just give instructions to do it, to the record i connect it with qwen3.6 35b, can you help me please" — with replies from @forexsocialbr ("Maybe a permission issue. Ask him (your agent) how to fix") and @AllieFyre ("Yeah. It's some kind of permissions issue, because otherwise it sshes fine into my machines"). This is the audience's most-asked follow-up on the video: a Linux/WSL permission surface the source video did not name.
  • @felixen21 (comment_id = UgyuKQDUPvn9HHygxMl4AaABAg, 2026-05-13): "I tried using your minimax 10% off link, but it gives me a 404 This page could not be found." — broken affiliate link from the source video, not a /goal claim.

Why /goal pairs with Skill Bundles. A bundle pins the skill set; /goal pins the intent across turns. The two together are the channel's recommended pattern for a non-trivial Hermes workflow: deterministic on the what (the goal), explicit on the how (the skill set), probabilistic only on the path between them. This is the same pattern Claude Code uses; the §2.5 → §4 cross-reference is the right anchor.

Where to learn the exact syntax. Because the video's transcript_content is null, the writer cannot quote the exact /goal syntax from the source. Verify in the official Hermes v0.13.0 release notes (linked in ai_updates row 0eb41407-9762-4ae3-b27b-ada4a338847b) and the hermes goal --help output before shipping. The §2.5 → §4 cross-reference is the right anchor: the Claude Code side is covered in Course 4 with verified transcripts.

NOTE: this section's /goal mechanism, persistence semantics, and any flag surface are not in the source video's transcript (null in public.videos). What is verified: (a) /goal shipped as "persistent cross-turn goals" in Hermes v0.13.0 on 2026-05-07 (ai_updates row 0eb41407-9762-4ae3-b27b-ada4a338847b); (b) the audience's first reaction is "use /plan" instead (viewer comment Ugw2DG6m-2ex_9R_GGB4AaABAg); (c) the token-cost interaction with Hermes memory (viewer thread UgxG__bOIpxMZfvJdep4AaABAg). Cross-check hermes goal --help and the v0.13.0 GitHub release notes before shipping any specific command form.

4. The probabilistic-vs-deterministic boundary — when to skill, when to bundle, when to dashboard

The §2.5 subtopic closes with the question every Hermes user has to answer: when should a workflow be a skill, a bundle, a dashboard, or a /goal-anchored session? The matrix below is the channel's read at the time of the source videos, drawn from the §2.5.1 (Skill Bundles) and §2.5.2 (Skills to Dashboards) videos.

The "deterministic vs probabilistic" framing, in detail. The §2.5.2 source video's load-bearing line: "it's not calling AI at any step right AI wrote this but it's no longer after AI wrote it. Uh it's now written in Typescript. So now it's executing TypeScript rather than executing AI… And we're not considered assuming any tokens. It's just like it's just 100% running as a service." The framing: probabilistic workflows (skills, bundles) call the LLM at every step; deterministic workflows (dashboards, scripts) do not. The cost: probabilistic workflows cost tokens; deterministic workflows do not. The reliability: probabilistic workflows can fail in unexpected ways; deterministic workflows fail predictably. The trade-off: probabilistic is flexible but expensive and unreliable; deterministic is rigid but cheap and reliable.

The "lying about completion" failure mode, in detail. The §2.5.2 source video's most-cited failure: the agent "sometimes lies to you that it ran something." The mechanism: the agent's stream-of-action log shows that a tool was invoked; the tool's actual return value is not what the agent reported. For example, the agent reports "fetched 20 videos" when the YouTube Data API returned an error and the agent made up the 20 videos from a cached list. The dashboard's "is already running" check (§2.5.2) is the deterministic fix: the dashboard queries the database for the actual count of fetched videos, and the count must match the agent's report. If the count doesn't match, the dashboard reports a failure.

The "silent drift after 1–2 weeks" failure mode, in detail. The §2.5.2 source video's second failure: "maybe like one or two weeks down the line we won't get the new videos in. There's no transcripts." The mechanism: a code change in a third-party API (e.g. YouTube's API) breaks the agent's invocation; the agent does not self-correct; the user notices 1–2 weeks later. The dashboard's verification step (§2.5.2) is the deterministic fix: the dashboard queries the database for the latest video's created_at timestamp, and the timestamp must be within the last 24 hours. If not, the dashboard reports a failure.

The "double-click protection" anti-pattern, in detail. The §2.5.2 source video's underrated failure: the user clicks "Run pipeline" twice, the pipeline runs twice, the second run races the first to update the HTML landing page. The agent's "smart" LLM-loop Hermes skill could self-correct ("Yo, stop clicking it so much"); the dashboard's "stupid computer" cannot. The fix is hand-coded: a pipeline_runs row with status = 'running' and a check before starting a new run. The dashboard is a "stupid computer"; every edge case has to be hand-coded.

Workflow property Recommended surface Why
Probabilistic, exploratory, one-off Skill (no bundle) Cheapest path; the agent can pick the right tools each time
Probabilistic, repeated, but skill set varies Skill Bundle Pin the skill set; allow the agent to vary the path
Probabilistic, repeated, intent varies too Skill Bundle + /goal Pin the skill set; pin the intent across turns
Deterministic, daily, quota-bound TypeScript dashboard + cron Same input → same output; no token cost; visible step counter
Deterministic, on-demand, low-stakes Skill (no bundle) No need for dashboard overhead; skill is fine
Multi-role, scheduled, with retries Kanban (§2.3) Parent-child + verifier + synthesizer; cron via §2.4
Skill maintenance itself The Curator (§2.7) Weekly cron; the operational layer underneath all of the above

The four sentences to remember:

  • Probabilistic + repeated = Skill Bundle. The bundle pins the skill set the agent picks.
  • Probabilistic + intent-spanning = Skill Bundle + /goal. The goal pins the intent across turns.
  • Deterministic + daily + quota-bound = TypeScript dashboard + cron. The dashboard pins the output.
  • Skill maintenance = Curator on a weekly cron. The Curator pins the library.

The default path, restated. For each recurring workflow, walk the four rows top-to-bottom. If it lands in the first row, leave it as a skill. If the second, build a Skill Bundle. If the third, add a /goal anchor. If the fourth, build a dashboard. If it lands in none of the rows, it's a one-off — keep it as a one-shot TUI prompt.

The "4-day" cost rule, restated. The §2.5.2 source video's honest build cost for a dashboard is 4 days, not 1 hour. The blockers, in order: authentication (Supabase), role-level security (per-user access), login flows and UX, double-click protection. The audience's take (3 top-liked replies on TCL0emWOjOQ) is to skip the LLM step entirely for the deterministic part: run a Python or TypeScript script as a skill, with cron if needed. The 4-day cost is only worth paying for daily, repeated, quota-bound work.

5. The skill-creation lifecycle — and where the Curator (§2.7) fits

The §2.5 subtopic lands in the middle of a moving target. The 15-turn self-evolution loop (§2.1.2) creates new skills every 15 turns. The Skill Bundle primitive pins the skill set for a workflow. The "skills-to-dashboards" rule (when a skill is daily + quota-bound) replaces the skill with a TypeScript dashboard. The Curator (§2.7) is the operational layer that keeps the skill library clean.

The lifecycle, end-to-end:

  1. The agent creates a skill. Every 15 turns, the agent audits its own performance and rewrites a skill. The skill lives in ~/.hermes/skills/.
  2. The agent uses the skill in subsequent turns. Usage frequency is tracked.
  3. A Skill Bundle may pin the skill if the workflow is repeated. The bundle is a YAML file under ~/.hermes/skill-bundles/.
  4. A dashboard may replace the skill if the workflow is daily, repeated, and quota-bound. The dashboard is TypeScript, AI-assisted in build, deterministic in run.
  5. The Curator archives the skill if it has not been used in the archive window (default: weekly check, configurable to daily). Archived skills are recoverable with hermes curator restore [skill-name].
  6. The LLM final summary from the Curator run notes which skills were archived, which were absorbed into a near-duplicate, and which were demoted. The user reviews the summary and restores any skill that was archived by mistake.

That six-step lifecycle is the channel's recommended pattern. Skip the Skill Bundle step (3) and the workflow drifts back into the "agent picks the wrong skills" failure mode. Skip the dashboard step (4) and the workflow drifts into the "Hermes lies about completion" failure mode. Skip the Curator step (5) and the skill library fills with near-duplicates and stale skills.

The right place to intervene. Step 3 (the Skill Bundle) is where the channel intervenes most. A bundle is a one-time edit to a YAML file; it pins the skill set the agent picks; it survives across sessions. The dashboard step (4) is a 4-day build that is only worth paying for daily work. The Curator step (5) is a weekly cron that runs unattended. The 15-turn self-evolution step (1) is a default that runs whether you want it to or not.

The skill file's anatomy. Every skill in ~/.hermes/skills/ has the same basic structure: a YAML frontmatter (with name, description, version, tags, allowed_models, cost_ceiling) and a markdown body (with ## When to invoke, ## Inputs, ## Outputs, ## Examples). The YAML frontmatter is what the agent's skill registry reads; the markdown body is what the agent's LLM-loop reads. The Curator's cluster analysis reads both: the YAML for metadata, the markdown for semantic similarity.

The skill registry's role. The skill registry is the in-memory index of all available skills. The registry is built at agent start-up from the YAML frontmatters in ~/.hermes/skills/. The registry is consulted by the agent's LLM-loop when deciding which skill to invoke. The registry is the load-bearing piece of the skill system — without it, the agent would have to read every skill file on every turn. With it, the agent has a fast lookup of available skills.

The agent's "skill decision" prompt. When the agent receives a user prompt, the agent's LLM-loop asks the skill registry: "which skills are relevant to this prompt?" The registry returns a list of skills (filtered by tags, allowed_models, and the user's description field). The agent's LLM then picks one or more skills from the list. The "picks 2-3 of 5" failure mode (§2.5.1) happens at this prompt: the LLM picks a subset of the relevant skills, not all of them. The Skill Bundle primitive fixes this by pinning the skill set the LLM should consider.

The §2.5 subtopic lands in the middle of a moving target. The 15-turn self-evolution loop (§2.1.2) creates new skills every 15 turns. The Skill Bundle primitive pins the skill set for a workflow. The "skills-to-dashboards" rule (when a skill is daily + quota-bound) replaces the skill with a TypeScript dashboard. The Curator (§2.7) is the operational layer that keeps the skill library clean.

The lifecycle, end-to-end:

  1. The agent creates a skill. Every 15 turns, the agent audits its own performance and rewrites a skill. The skill lives in ~/.hermes/skills/.
  2. The agent uses the skill in subsequent turns. Usage frequency is tracked.
  3. A Skill Bundle may pin the skill if the workflow is repeated. The bundle is a YAML file under ~/.hermes/skill-bundles/.
  4. A dashboard may replace the skill if the workflow is daily, repeated, and quota-bound. The dashboard is TypeScript, AI-assisted in build, deterministic in run.
  5. The Curator archives the skill if it has not been used in the archive window (default: weekly check, configurable to daily). Archived skills are recoverable with hermes curator restore [skill-name].
  6. The LLM final summary from the Curator run notes which skills were archived, which were absorbed into a near-duplicate, and which were demoted. The user reviews the summary and restores any skill that was archived by mistake.

That six-step lifecycle is the channel's recommended pattern. Skip the Skill Bundle step (3) and the workflow drifts back into the "agent picks the wrong skills" failure mode. Skip the dashboard step (4) and the workflow drifts into the "Hermes lies about completion" failure mode. Skip the Curator step (5) and the skill library fills with near-duplicates and stale skills.

The right place to intervene. Step 3 (the Skill Bundle) is where the channel intervenes most. A bundle is a one-time edit to a YAML file; it pins the skill set the agent picks; it survives across sessions. The dashboard step (4) is a 4-day build that is only worth paying for daily work. The Curator step (5) is a weekly cron that runs unattended. The 15-turn self-evolution step (1) is a default that runs whether you want it to or not.

Try it yourself

This is a hands-on subtopic. Three tracks, in order of complexity.

Track A — Build your first Skill Bundle.

  1. Run /bundles create. Name it after a workflow you actually do (e.g. research, backend-dev, newsletter).
  2. Pin the skills the workflow needs in the skills array — do not let the agent guess.
  3. Write the house rules in instructions (audience, tone, format, definition of done). This is your "mini agents.md."
  4. Save under ~/.hermes/skill-bundles/<name>.yaml and run /bundles reload — do not restart Hermes.
  5. Test the slash command with a real task. If the agent skips a skill, edit the YAML; do not add more prompt text.
  6. Ask the agent to propose the plan first — ordering is not documented as adaptive in the source video.
  7. Commit ~/.hermes/skill-bundles/*.yaml to a shared dotfiles repo so the team gets the same /research you do.

Track B — Convert a daily skill to a dashboard.

  1. Pick a skill that runs daily on a quota-bound API (YouTube Data API is the source video's example). Skip one-shots — they stay skills.
  2. Estimate 4 days, not 1 hour. Authentication, RLS, login, and double-click protection are the real blockers. The audience's take (3 top-liked replies on TCL0emWOjOQ) is to skip the LLM step entirely for the deterministic part: run a Python or TypeScript script as a skill, with cron if needed.
  3. Build in TypeScript (or any non-LLM loop). The point is determinism: same input, same output, no tokens.
  4. Add an "is already running" check on every entry point. A 3-day-old stale run will block the entire pipeline — this is the source video's own bug.
  5. Block concurrent runs explicitly — RAM blowups and YouTube API quota exhaustion are the source-named failures.
  6. Surface quota usage in the UI so the dashboard shows you how much of the API budget it has burned.
  7. Wire to cron. The cron is the trigger, the dashboard is the interface, the database is the product.

Track C — Wire /goal into a bundle.

  1. Confirm your Hermes install is on v0.13.0 or later (the release that shipped /goal as a "persistent cross-turn goals" feature — ai_updates row 0eb41407-9762-4ae3-b27b-ada4a338847b).
  2. Read the official v0.13.0 release notes and hermes goal --help for the exact syntax. The source video's transcript is null; do not trust third-party guides.
  3. Pick one Skill Bundle from Track A.
  4. Set a /goal once per session (intent, constraints, audience, definition of done). Then invoke the bundle.
  5. Run the bundle a few times with and without /goal and compare. The /goal anchor is what makes the output consistent across turns — the literal "persistent" in the release description.
  6. If a viewer asks "why not use /plan?" — that's the single-turn alternative the source video does not name. Audience-confirmed in viewer comment Ugw2DG6m-2ex_9R_GGB4AaABAg (@angelmechanical, 2026-05-11). Pick based on whether the goal spans turns (/goal) or only the next turn (/plan).
  7. Cross-reference with Course 4's coverage of the Claude Code task bootstrap — the patterns are the same.

Common pitfalls

  • Don't expect a natural-language prompt to pick 5 skills reliably. It will skip 2–3. Edit the bundle, not the prompt, when a skill is dropped.
  • Don't restart Hermes after editing a bundle YAML. /bundles reload is the right command.
  • Don't trust the agent's "I'm done" on a long skill. Hermes "sometimes lies to you that it ran something." For daily / quota-bound work, the answer is a TypeScript dashboard with an explicit step counter — not a better prompt.
  • Don't treat a 1-hour estimate as a 1-hour build. The source video's honest number: 4 days across Claude Code 4.7 and 4.8. Auth, RLS, login, and double-click protection are the real blockers.
  • Don't skip the "is already running" check. A 3-day-old stale run blocks the entire pipeline. The dashboard is a "stupid computer" — every edge case has to be hand-coded.
  • Don't allow concurrent dashboard runs. RAM blowups and YouTube API quota exhaustion are the source-named failures. Block concurrency at the entry point, not at the tool.
  • Don't build a dashboard for a one-shot skill. The 4-day cost is only worth paying for daily, repeated, quota-bound work.
  • Don't accept a bundle the agent proposes without reviewing the plan. Ordering is not documented as adaptive. Ask the agent for the plan first.
  • Don't switch models and assume the context window followed. The source video's bug: switching from Kimiko 2.6 to DeepSeek V4 Pro kept the Kimiko 2.6 window. Hard-code the value in config until Hermes fixes it.
  • Don't use a wide bundle. One workflow per bundle, one slash command per workflow — wide bundles drift back into the "agent picks the wrong skills" failure mode.
  • Don't ship a /goal prompt without a definition of done. If the goal can be read two ways, the agent will read it the wrong way.
  • Don't assume /goal and /plan are the same thing. The audience-confirmed split (viewer Ugw2DG6m-2ex_9R_GGB4AaABAg): /plan is single-turn; /goal is persistent across turns. Pick the primitive that matches the workflow.

Sources