Du verbringst einen Nachmittag damit, das Deploy-Runbook zu schreiben, das dein Team wirklich braucht: erst Backup, dann Traffic umschalten, ein Rollback-Fenster von fünf Minuten, und eine Liste, welche Tabellen zuletzt migriert werden müssen. Es funktioniert. Bei jedem Release folgt der Agent ihm.

Dann „verbessert“ es sich irgendwann selbst. Der curator entscheidet, das skill sei zu ausführlich, und fasst ein paar Schritte zusammen; der Self-Improvement-Review fügt eine „effizientere Reihenfolge“ hinzu. Als du es merkst, ist der Backup-Schritt hinter den Cutover gerutscht — und dieses Release ist schon raus.

Das Problem ist nicht, dass der Agent keine Regeln befolgen kann. Es ist, dass skills, die du geschrieben hast, und skills, die der Agent geschrieben hat, im selben Pool mit denselben Rechten liegen. Hermes hatte schon immer pin, aber pin verhindert nur Löschen und automatisches Archivieren — Edits und Patches gehen weiter durch. v0.22.6 fügt das eigentliche Lock hinzu.

pin vs. lock, je in einer Zeile

• pin: der curator erklärt es nicht für veraltet und archiviert es nicht, und der Agent kann es nicht löschen; es lässt sich weiter bearbeiten.
• lock: der Agent kann es überhaupt nicht ändern, während das skill lesbar bleibt, im skill-Index gelistet, auto-loadbar und genau wie vorher nutzbar.

Pin heißt „wirf es nicht weg“. Lock heißt „fass es nicht an“.

Wie man lockt

hermes curator lock <skill>      # locken
hermes curator unlock <skill>    # Lock aufheben
hermes curator status            # zeigen, was gelockt ist

In der Desktop-App brauchst du die CLI nicht: öffne Capabilities → Skills, wähle das skill und nutze seinen Lock-Schalter.

Der Record liegt in der skills/.usage.json des aktiven Profils — demselben Sidecar wie pinned — als "locked": true. Das macht ihn pro Profil:

hermes -p work curator lock deploy-runbook    # nur die Kopie im work-Profil

Fast alles Sperrbare ist sperrbar: handgeschrieben, vom Agent erzeugt, gebündelt oder aus dem Hub installiert, solange der Name in diesem Profil auflöst. Umgekehrt lehnt lock einen Namen ab, den es nicht auflösen kann, ein Tippfehler kann also keinen Record fälschen.

Was das Lock tatsächlich blockiert

Für ein gelocktes skill wird jeder Schreibpfad des Agent abgelehnt — weiter, als die meisten erwarten:

• jede mutierende Action von skill_manage (create, edit, patch, delete);
• write_file / patch auf jeden Pfad innerhalb des skill-Verzeichnisses;
• jeder terminal-Befehl, der dort schreiben würde — Redirections, tee, cp/mv/rm, In-Place-Editoren wie sed -i, git-Mutationen im skill-Baum, ein vorheriges cd hinein, und Inline-Interpreter-Code, der den Pfad nennt.

Diese Grenzen gelten auch unter --yolo, und über normale Turns, cron-Jobs, Subagents, den Hintergrund-Self-Improvement-Review und den curator-Lauf selbst hinweg. Der curator archiviert ein gelocktes skill ebenfalls nicht.

Ein Detail verdient einen eigenen Satz: der Agent kann es nicht entsperren. Sein Versuch, hermes curator unlock auszuführen, wird auf der Terminal-Ebene abgelehnt, und solange irgendein skill gelockt ist, ist die Lock-Record-Datei genauso geschützt. Die Ablehnung sagt ihm, es soll die gewünschte Änderung beschreiben, damit du entscheiden kannst.

Deine eigenen Edits sind überhaupt nicht gegated: dein Editor, der Desktop-skill-Editor und die CLI funktionieren weiter. Das Lock beschränkt den Agent, nicht dich.

Was ein Lock nicht ist

Drei Grenzen, die die Doku klar benennt:

1. Es beschränkt nur den Agent — erwarte nicht, dass es dich vor deinen eigenen Fehlern schützt.
2. Es ist eine Policy-Prüfung, keine Sandbox. Der Terminal-Guard liest die Schreibziele eines Befehls (Redirections, tee, cp/mv/rm, sed -i, git im skill-Baum, cd, Inline-Code, der den Pfad nennt). Ein Script, das über seine eigene Logik dorthin schreibt, wird nicht gesehen. Echte Isolation heißt weiterhin Container oder ein eingeschränktes Terminal-Backend.
3. Eine kaputte .usage.json schlägt auf den Hintergrundpfaden closed, nicht überall: die Läufe, die skills ändern würden (Self-Improvement-Review, curator), werden abgelehnt, während normale Turns weiter funktionieren, eine kaputte Datei friert also nicht jeden skill-Edit ein. Repariere die Datei, oder führe hermes curator unlock <skill> aus, um sie neu zu schreiben.

Wann es sich lohnt

• Produktions-Runbooks, Compliance-Verfahren, Incident-Playbooks — alles, wo ein falscher Schritt teuer wird.
• Eine Team-skill-Bibliothek, die du pflegst: du willst, dass der Agent sie nutzt, und nicht, dass er sie „hilfreich optimiert“.
• Ein skill von Drittanbietern, das du gerade reviewt hast: lass es eine Weile laufen und entscheide dann, ob du das Lock lockerst.

Wenn du willst, dass der Agent an einem skill iteriert, lass es ungelockt und nutze pin, damit es nicht archiviert wird.

Für das größere Vertrauensbild passen zwei weitere Beiträge gut dazu: die blinden Flecken im skill-Guard behandeln, was der Checker selbst übersieht, und skill-Integrität und Supply-Chain-Rug-Pulls behandeln, wie ein installiertes skill dir unter den Händen ausgetauscht werden kann. Ein Lock beantwortet die dritte Frage: wenn es erst installiert ist, wer darf es dann ändern?

Die Fähigkeit ist im Tag v0.22.6 enthalten — upgraden, und sie ist da; hermes curator status listet jedes gelockte skill mit Namen.