Arbeiten

aiusage-skills: fremde Agent-Skills ohne Überraschungen

Ein Agent-Skill ist eine Anleitung für einen Agenten, der Ihre Dateien bereits lesen kann. Wie nutzt man Skills anderer Autoren, ohne dass sich diese Anleitungen unbemerkt ändern?

Wie Skills von Dritten ins Plugin kommen Skills aus einem Upstream-Repository werden nach vendor/ kopiert und auf einen Upstream-Commit fixiert. Übernommen wurden nur 35 von 145, und ihre Skripte bleiben in Quarantäne, bis ein schriftlicher Entscheid sie freigibt. Das Plugin wird aus vendor/ ausgeliefert. Daneben laufen zwei Prüfungen: Die CI vergleicht den ganzen vendor/-Baum mit einer SHA-256-Baseline, und ein nächtlicher Job vergleicht vendor/ mit Upstream und führt pro Quelle genau ein Issue. Upstream Skill-Repository vendor/ fixiert, 35 von 145 Skripte in Quarantäne Plugin was ausgeliefert wird Nächtlicher Drift-Job ein Issue pro Quelle SHA-256-Baseline CI scheitert bei Änderung fixierte Kopie vergleicht
Wie Skills von Dritten ins Plugin kommen. Blau: der Entscheid · gestrichelt: Prüfungen.
Status
Open Source. Die hier beschriebenen Entscheide sind umgesetzt; die Lücken stehen am Schluss.
Meine Rolle
Autor. aiusage-skills ist mein eigenes Projekt.
Umfang
Wie Skills von Dritten ins Plugin kommen und wie Änderungen im Original auffallen
Zuletzt geprüft
29. September 2026

aiusage-skills ist ein Claude-Code-Plugin mit zwölf eigenen Skills für Planung, testgetriebene Entwicklung und die Prüfung von Änderungen, dazu eine Auswahl an Skills anderer Autoren. Es gehört zu aiusage.guide: Der Leitfaden beschreibt die Arbeitsweisen, das Plugin bringt sie in den Agenten, und beide speisen sich gegenseitig.

Der Ausgangspunkt

Ein Skill aus einem Marktplatz ist keine Bibliothek. Er ist eine Anleitung für einen Agenten, der bereits Zugriff auf Ihre Dateien und Zugangsdaten hat. Wer ihn aus einem Marktplatz installiert, überlässt dem Autor die Entscheidung, wann sich diese Anleitung ändert, und die Änderung kommt an, ohne dass jemand sie gelesen hat.

Entscheide

Kopieren und fixieren statt installieren. Skills von Dritten werden nach vendor/ kopiert, auf einen Upstream-Commit fixiert und mit ihrer Lizenz abgelegt. Übernommen wurde nur, was dem Plugin fehlte: 35 von 145 Skills. Verworfen wurde die Installation aus einem Marktplatz, die sich selbst aktualisiert. Der Architekturentscheid sagt, was das kostet:

Updates become a ritual (NOTICE.md) instead of an event. That is the point. The tree is 35 skills, not 145; absence is a decision.

Aus ADR-0001, „Vendor third-party skills instead of installing from marketplaces“, angenommen. Zuletzt geändert am 9. September 2026. Im englischen Original.

Skripte laufen erst, wenn jemand sie gelesen hat. Skripte landen ohne Ausführungsrecht in scripts.quarantine/. Freigegeben wird ein Skript nur durch einen schriftlichen Entscheid. ADR-0019 hat 54 geprüfte Skripte freigegeben und vier in Quarantäne gelassen, darunter eines, das beim Scannen zwölf fremde Regel-Repositories ohne Fixierung klont. Beim Lesen zeigte sich auch, dass mehrere Skills nach einigen Schritten an einem Pfadfehler scheiterten, obwohl ihre Beschreibung behauptete, sie würden absichtlich anhalten.

Den ganzen vendor-Baum einfrieren. Die übernommenen Skills an meinen eigenen Regeln zu messen, würde jeden einzelnen durchfallen lassen und die echten Befunde verdecken. Deshalb vergleicht die CI den gesamten vendor/-Baum mit einer SHA-256-Baseline. Jede Änderung lässt den Build scheitern, bis jemand sie nach dem Lesen mit einem bewussten --write-baseline-Commit annimmt.

Änderungen im Original melden, nie übernehmen. Ein nächtlicher Job vergleicht vendor/ mit jeder Quelle und führt pro Quelle, die sich weiterentwickelt hat, genau ein Issue. Am Tag, an dem die erste vollständige Durchsicht abgeschlossen war, waren drei der vier Quellen bereits weiter.

It does not copy anything into vendor/, does not open merge requests, and does not read upstream file contents — --name-status needs trees, not blobs. Fetched content is diffed, never executed. Copying and reading stay with the human, per ADR-0001; the job only says that there is something to read.

Aus ADR-0018, „A nightly job compares vendor/ with upstream and keeps one issue per source“, angenommen. Zuletzt geändert am 9. September 2026. Im englischen Original.

Nachweis

Vier CI-Jobs setzen das durch:

  • validate:skills prüft meine eigenen Skills gegen die Regeln: erlaubte Werkzeuge, kein Nachladen oder Installieren zur Laufzeit, eine Längengrenze.
  • validate:self-test lässt den Validator gegen Beispiele laufen, die scheitern müssen, etwa ein Skill, der curl ausführt (runs-curl) oder den Agenten im Fliesstext etwas herunterladen lässt (prose-fetch), und gegen eines, das bestehen muss, weil es curl nur erwähnt (mentions-curl).
  • validate:vendor prüft Quarantäne, Manifeste und die SHA-256-Baseline von vendor/.
  • vendor:drift ist der nächtliche Vergleich mit dem Original.

Noch offen

  • Die CI-Images sind über einen Tag referenziert, nicht über einen Digest. ADR-0014 nennt das „the one unpinned input in a repository whose argument is pinning“.
  • Der Validator folgt Skills nicht, die andere Skills aufrufen.
  • Die Prüfungen arbeiten mit Mustern. Semantische Angriffe, die die Muster nicht erkennen, und Prompt Injection in Inhalten, auf die ein Agent angesetzt wird, deckt das nicht ab. Das Bedrohungsmodell sagt das ausdrücklich.
  • Das Skript, das Regel-Repositories ohne Fixierung klont, bleibt in Quarantäne, bis darüber entschieden ist.

Technik: Python (nur Standardbibliothek), GitLab CI.