Du folgst einem Tutorial von vor ein paar Monaten, um deinem Agenten Notion beizubringen: hermes skills search notion — und die integrierten Einträge sind weg, nur Repo-Quellen bleiben übrig. Du fragst dich, ob du deine Installation kaputt gemacht hast. Hast du nicht. Hermes hat sieben integrierte optionale Skills außer Dienst gestellt, weil die Probleme, die sie lösten, inzwischen bessere Besitzer haben.

Das ist kein Feature, das gestrichen wird, sondern eine Neuverteilung der Frage „woher kommen Skills“. Wer das versteht, spart sich zwei Sorten Ärger: etwas installieren, das es nicht mehr gibt, und etwas installieren, das dann unter einer veralteten Policy läuft.

Die sieben ausgemusterten Skills und wer übernommen hat

Diese integrierten optionalen Skills wurden entfernt, weil offizielle Vendor-MCPs, Catalog-Plugins, mitgelieferte Such-Backends oder die Skill-Repos der Hersteller sie besser abdecken:

Ausgemusterte integrierte Skill	Jetzt abgedeckt durch
notion	Offizielles Notion-MCP im MCP-Katalog (OAuth, kein Portal nötig) + gehosteter Connector + makenotion/skills
airtable	Offizielles Airtable-MCP + gehosteter Connector + Airtable/skills
shopify	Gehosteter Connector + die vom Hersteller gepflegte Skill in Shopify/Shopify-AI-Toolkit
duckduckgo-search	Mitgeliefertes ddgs-Web-Search-Backend (web_search funktioniert ohne Key)
searxng-search	Mitgeliefertes searxng-Backend über SEARXNG_URL
honcho	Das honcho-Catalog-Plugin, das die hermes honcho-Befehle besitzt, die diese Skill dokumentierte
mpp-agent	Die verifizierten pay / pay-cli-Catalog-Plugins (HTTP 402 / x402 / MPP)

Ein Nebeneffekt ist wissenswert: AIRTABLE_API_KEY ist aus der Liste der optionalen Umgebungsvariablen verschwunden, weil diese Skill der einzige Nutzer war. NOTION_API_KEY bleibt, denn die Notion-Senke der Teams-Meeting-Pipeline liest sie weiterhin.

Wenn du also die integrierte Skill für Airtable genutzt hast, führt der Weg über das offizielle MCP oder das Skill-Repo des Herstellers. Die Fähigkeit ist nicht verschwunden, sie ist zu der Stelle umgezogen, die API-Änderungen mitverfolgt.

Taps: wo Skills tatsächlich gefunden werden

Die Skill-Suche durchsucht nicht nur dein lokales Verzeichnis. Sie schaut über eine Menge von Quellen, die Taps heißen. Die Standard-Taps sind eine fest verdrahtete Menge von Repositories — openai/skills, anthropics/skills, huggingface/skills, NVIDIA/skills und andere — und diese Änderung hat drei Vendor-Repos hinzugefügt:

• makenotion/skills (Pfad skills/)
• Airtable/skills (Pfad plugins/airtable/skills/)
• Shopify/Shopify-AI-Toolkit (Pfad skills/)

Der Unterschied zwischen einem Vendor-Repo und einem allgemeinen Community-Repo ist nicht die Qualität, sondern die klare Zuständigkeit. Das Repository gehört dem Hersteller, die Lizenz ist explizit — deshalb kann es in die Standard-Trusted-Liste aufgenommen werden, statt bei jeder Installation als Community-Inhalt behandelt zu werden.

Taps kannst du selbst hinzufügen — der billigste Weg, Skills im Team zu verteilen:

hermes skills tap list            # konfigurierte Quellen
hermes skills tap add <owner>/<repo>
hermes skills browse --source github
hermes skills inspect notion-cli  # lies es, bevor du installierst
hermes skills install notion-cli

Verwechsle hermes skills tap nicht mit hermes skills trust. Das erste verwaltet, wo Skills gefunden werden; das zweite entscheidet, ob repo-lokale Skills wie ./.hermes/skills überhaupt geladen werden dürfen. Ähnliche Namen, völlig verschiedene Aufgaben.

Trust-Level: die Tabelle, die entscheidet, was installiert wird

Nach dem Scan bekommt eine Skill ein Trust-Level, und die Install-Policy ist ein Nachschlagen dieses Levels, gekreuzt mit dem Scan-Verdikt (safe / caution / dangerous):

Trust-Level	safe	caution	dangerous
builtin	erlauben	erlauben	erlauben
trusted (Vendor- / offizielle Repos)	erlauben	erlauben	blockieren
community	erlauben	blockieren	blockieren
agent-created	erlauben	erlauben	an den Agenten übergeben

Diese Tabelle erklärt zwei Dinge, über die Leute stolpern. Erstens, warum dieselbe Skill aus einem Repo installierbar ist und aus einem anderen nicht: Die Quelle setzt das Level, und das Level entscheidet, ob caution-Funde blockiert werden. Zweitens, warum Vendor-Repos es wert sind, explizit gelistet zu werden — trusted lässt caution durch, community nicht. Diese eine Zelle ist der ganze Unterschied.

trusted heißt nicht risikofrei. Dangerous-Funde werden aus jeder Nicht-builtin-Quelle blockiert, ohne Ausnahme.

Der Ein-Zeilen-Cache-Bug, der eine alte Policy am Leben hielt

Skill-Scans werden gecacht, damit Installationen nicht alles neu scannen. Der Cache-Key nutzte den Content-Hash, die Quelle und die Scanner-Version — und ausdrücklich nicht das Trust-Level.

Die Folge ist konkret. Du scannst eine Skill, aktualisierst danach Hermes, nachdem ihr Repository in die Trusted-Liste aufgenommen (oder daraus entfernt) wurde, und Installationen wenden weiterhin das Trust-Level an, das bei diesem früheren Scan festgehalten wurde — bis sich der Inhalt der Skill ändert. Mit anderen Worten: Änderungen an der Trusted-Repos-Liste umgingen den Cache-Key komplett.

Der Fix nimmt das aktuelle Trust-Level in den Cache-Key auf: Ein gecachter Scan wird nur wiederverwendet, wenn das aktuelle Trust-Level der Quelle noch passt, sonst wird die Skill neu gescannt. Eine Zeile, mit Tests in beide Richtungen — ein neu vertrautes Repo wird als trusted neu gescannt, ein entferntes als community, und eine unveränderte Quelle bleibt ein Cache-Hit.

Der Fix ist auf main gemergt, aber nicht im Tag v0.22.7, kommt also mit dem nächsten Release. Bis dahin gilt: Wenn du kürzlich den Trust geändert hast und die Policy falsch aussieht, ist hermes skills audit zum Neu-Scannen installierter Skills der direkte Workaround.

Drei Dinge, die du jetzt tun solltest

1. Inventar: führe hermes skills list aus und finde alles, was noch auf eine ausgemusterte Skill zeigt — besonders Namen, die in Team-Skripten hart kodiert sind.
2. Umleiten: verlege Notion-, Airtable- und Shopify-Automatisierung auf die offiziellen MCPs oder Vendor-Skill-Repos; für Suche nutze die mitgelieferten ddgs / searxng-Backends, statt eine Skill zu installieren.
3. Auditieren: führe nach dem Upgrade einmal hermes skills audit aus, damit nichts unter einem alten Trust-Level weiterläuft.

Weniger integrierte Skills sind meistens eine gute Nachricht. Sieben Implementierungen weniger zu pflegen, Vendor-Repos, die ihre eigenen APIs nachziehen, und offizielle MCPs, die OAuth mitbringen, statt dich einen API-Key kopieren zu lassen — die Wartungslast ist dort gelandet, wo sie hingehört.

Weiterlesen: projektlokale Skills und das Trust-Gate, die drei zuvor ergänzten optionalen Skills, ein geführtes Upgrade, was sonst im v0.22.7-Fenster steckt.