GitHub CLI gh skill auf Projektebene oder Benutzerebene installieren? Sicherheitsvergleich 2026

Dieser Leitfaden richtet sich an Entwickler, Plattformteams und Verantwortliche für die Prüfung von Skills in GitHub-Repositories. Er vergleicht Projekt- und Benutzerinstallation, zeigt Prüf- und Update-Schritte und hilft, den passenden Umfang für den jeweiligen Arbeitsablauf festzulegen.

Ein Skill soll in mehreren Repositories funktionieren, aber nicht ungeprüft in jedem Projekt verfügbar sein.

Geeignet: Für gemeinsam geprüfte Skills wählen Sie die Projektinstallation; für bewusst persönliche, repositoryübergreifende Nutzung kommt die Benutzerinstallation infrage. Prüfen Sie in beiden Fällen zuerst Inhalt, Herkunft, Version und Änderungen.

Dieser Artikel ist für Entwickler gedacht, die gh skill in einem einzelnen Repository einsetzen möchten. Plattformteams finden hier Kriterien, um Skills für mehrere Mitglieder nachvollziehbar bereitzustellen. Sicherheits- und Toolchain-Verantwortliche erhalten einen Ablauf zur Prüfung von Dateien, Skripten und Updates.

Zuletzt geprüft am 8. Oktober 2026. Grundlage sind die GitHub-Dokumentation zu Agent Skills und die offiziellen GitHub-CLI-Handbücher zu Installation, Vorschau, Auflistung und Aktualisierung. Der öffentliche Vorschau- und Funktionsumfang kann sich ändern. Prüfen Sie deshalb vor der Einführung die aktuelle Dokumentation und die Hilfe Ihrer installierten CLI-Version.

Was entscheidet der Installationsumfang tatsächlich?

Der Installationsumfang beantwortet eine praktische Frage: Soll der Skill in einem bestimmten Projektkontext verfügbar sein oder für die persönliche Arbeit über mehrere Projekte hinweg? Er ist keine Sicherheitsbewertung. Ein Skill wird nicht vertrauenswürdig, nur weil er benutzerweit installiert wurde; eine Projektinstallation macht seinen Inhalt nicht automatisch für das Team sicher.

Die GitHub-Dokumentation beschreibt gh skill zum Entdecken, Installieren, Aktualisieren und Veröffentlichen von Skills. Sie weist zugleich darauf hin, dass Skills nicht von GitHub verifiziert werden und schädliche Anweisungen oder Skripte enthalten können. Vor einer Installation sollen Sie den Inhalt prüfen. Das ist eine wichtige Grenze: Die Funktion zum Installieren ersetzt weder eine Codeprüfung noch die Freigabe durch die Verantwortlichen des Projekts. GitHub erläutert Funktionen und Sicherheitshinweise für Agent Skills.

Für die Entscheidung zählen daher nicht nur Bequemlichkeit und Wiederverwendung. Berücksichtigen Sie auch, wer Änderungen bemerkt, wer eine Version freigibt und in welchen Projekten ein Skill Wirkung entfalten kann. Eine Installation auf Benutzerebene spart wiederholtes Einrichten, vergrößert aber den möglichen Einsatzbereich. Eine Installation auf Projektebene bindet den Skill enger an den jeweiligen Arbeitskontext, verlangt dafür klare Abläufe für Prüfung, Aktualisierung und Übergabe.

Was unterscheidet eine projektweite von einer benutzerweiten Installation? Bei der Projektinstallation wird der Skill einem Projektkontext zugeordnet. Das passt, wenn seine Nutzung mit dem Repository, den dortigen Arbeitsabläufen und einer gemeinsamen Prüfung verbunden sein soll. Eine Benutzerinstallation richtet sich an die persönliche Wiederverwendung. Sie ist praktisch, wenn dieselbe Person einen Skill in mehreren eigenen Projekten einsetzen möchte. Welche Agent-Hosts und Installationsumfänge die aktuelle CLI anbietet, entnehmen Sie der Installationsreferenz von gh skill; verwenden Sie die dort dokumentierten Optionen, statt Parameter aus älteren Anleitungen zu übernehmen.

Im persönlichen Mehr-Repository-Alltag bewusst begrenzen

Für Einzelpersonen ist die benutzerweite Installation oft bequem: Ein Skill muss nicht für jedes Arbeitsverzeichnis erneut bereitgestellt werden. Das kann den Einrichtungsaufwand verringern. Es bedeutet aber auch, dass Sie stärker darauf achten müssen, wo der Skill verfügbar wird und ob sein Inhalt für alle betroffenen Projekte passt.

Das ist besonders relevant, wenn ein persönlicher Arbeitsbereich vertrauliche Repositories, externe Beiträge oder Automatisierung enthält. Eine Anleitung, die für ein privates Testprojekt sinnvoll ist, muss nicht für ein Repository mit strengeren Prüf- oder Datenschutzanforderungen geeignet sein. Bei einem benutzerweiten Skill sollten Herkunft und Anwendungsbereich deshalb dokumentiert sein. Bewahren Sie außerdem keine Zugangsdaten oder vertraulichen Projektinformationen in Skill-Dateien auf.

Prüfhinweis: „Einmal installieren, überall nutzen“ beschreibt Komfort, nicht Sicherheit. Je größer der mögliche Einsatzbereich ist, desto wichtiger sind eine eng begrenzte Auswahl und eine nachvollziehbare Update-Prüfung.

Vor der persönlichen Installation lesen Sie die SKILL.md vollständig und kontrollieren die Verzeichnisstruktur. Die Agent-Skills-Spezifikation beschreibt die erwartete Struktur und die Rolle der Skill-Datei. Prüfen Sie zusätzlich alle beigefügten Skripte und Referenzen: Anweisungen können über den sichtbaren Beschreibungstext hinausgehen, und ausführbare Dateien können andere Risiken mitbringen als reine Dokumentation.

Wie prüfen Sie einen Skill vor der Installation? Nutzen Sie die von Ihrer CLI-Version unterstützte Vorschaufunktion und gleichen Sie das Ergebnis mit dem Quellrepository ab. Das Handbuch zu gh skill preview beschreibt die Vorschau. Achten Sie auf den vollständigen Inhalt der SKILL.md, weitere Dateien, Skripte, externe Verweise und den Ursprung des Skills. Eine Vorschau ist eine Hilfe zur Sichtprüfung, aber keine automatische Sicherheitsfreigabe.

Wenn Sie den Skill anschließend benutzerweit einrichten, halten Sie fest, aus welchem Repository er stammt und welche Version Sie ausgewählt haben. Prüfen Sie nach der Installation, ob der erwartete Agent-Host den Skill erkennt. Falls die Quelle oder die Wirkung unklar bleibt, brechen Sie ab und kehren Sie zu einem engeren Umfang zurück. Installieren Sie nicht erst breit und hoffen Sie später, mögliche Seiteneffekte zu entdecken.

Im Team eines einzelnen Repositories gemeinsam prüfen

Für ein Team ist die Projektinstallation häufig die bessere Ausgangslage, wenn alle Beteiligten denselben Skill im Zusammenhang mit demselben Repository verwenden sollen. Der Skill kann dann in die Projektprüfung und die Übergabe eingebunden werden. Das verringert das Risiko, dass Teammitglieder unabhängig voneinander unterschiedliche Quellen oder Versionen verwenden.

Die Projektinstallation allein garantiert jedoch keine einheitliche Teamrichtlinie. Sie müssen weiterhin entscheiden, wer Änderungen prüft, wie die Quelle dokumentiert wird und wie neue Versionen in den Arbeitsablauf gelangen. GitHub dokumentiert Installationsumfänge und Angaben zur Herkunft; daraus folgt nicht, dass eine Organisation automatisch eine bestimmte Freigabe- oder Update-Strategie durchsetzt. Verwechseln Sie die verfügbare Funktion daher nicht mit einer bereits eingerichteten Governance.

Bei der gemeinsamen Prüfung sollte die Änderung des Skills wie eine Änderung an anderem Projektmaterial behandelt werden. Vergleichen Sie den neuen Inhalt mit dem freigegebenen Stand. Halten Sie Quelle, ausgewählte Version und Anlass der Aktualisierung fest. So kann ein anderes Teammitglied später nachvollziehen, ob eine Anpassung beabsichtigt war oder ob ein unerwarteter Befehl hinzugekommen ist.

Welche Installationsart passt für gemeinsam genutzte Skills? Wenn der Skill für die Arbeit in einem Repository gedacht ist und gemeinsam geprüft werden soll, beginnen Sie mit der Projektinstallation. Benötigt jedes Teammitglied denselben Skill auch unabhängig von diesem Projekt, ist eine zusätzliche persönliche Installation eine getrennte Entscheidung. Legen Sie nicht aus Bequemlichkeit eine Benutzerinstallation als Ersatz für eine projektbezogene Freigabe fest.

Die folgende Gegenüberstellung bewertet typische Eigenschaften qualitativ. „Hoch“ bedeutet hier, dass der jeweilige Ansatz den genannten Zweck eher unterstützt; es ist keine Sicherheitsnote und keine Garantie.

Diese Einordnung ist absichtlich keine universelle Rangliste. Ein Team, das persönliche Werkzeuge zentral verwaltet, kann andere Abläufe haben als ein einzelner Entwickler mit mehreren privaten Projekten. Entscheidend ist, ob die Installation zu Ihrer tatsächlichen Prüf- und Update-Verantwortung passt.

In regulierten oder sensiblen Projekten zuerst den Inhalt festlegen

In einem sensiblen Repository sollte die Installationsentscheidung erst nach einer inhaltlichen Prüfung fallen. Sehen Sie sich nicht nur die Beschreibung an. Prüfen Sie, welche Aufgaben der Skill anweist, ob er auf externe Quellen verweist und ob Skripte enthalten sind, die beim Arbeitsablauf ausgeführt werden könnten. Besonders bei automatisierten Abläufen muss klar sein, welche Aktionen der Agent ausführen darf und welche weiterhin eine menschliche Prüfung benötigen.

Ein Skill kann Anweisungen enthalten, die nicht zur erwarteten Aufgabe passen. Die GitHub-Dokumentation warnt ausdrücklich vor möglichen Prompt-Injection-Inhalten, versteckten Anweisungen und schädlichen Skripten. Das ist ein dokumentierter Risikohinweis, keine Aussage, dass jeder Skill gefährlich ist. Er ist aber ein ausreichender Grund, Inhalte und Herkunft vor der Nutzung zu prüfen. Bei vertraulichen Daten sollten Sie außerdem Ihre internen Datenschutz- und Zugriffsregeln berücksichtigen; unsere Hinweise zum Datenschutz im Entwicklungsumfeld können die technische Prüfung ergänzen, ersetzen aber keine organisationsinterne Sicherheitsrichtlinie.

Arbeiten Sie mit einem freigegebenen Stand und prüfen Sie Updates gezielt. Das Handbuch zum Aktualisieren von Skills mit gh skill update beschreibt die Update-Funktion und den dafür vorgesehenen Ablauf. Wenn Ihre aktuelle CLI-Version eine Version festsetzen kann, dokumentieren Sie die ausgewählte Version und ändern Sie sie erst nach Prüfung des Unterschieds. Kontrollieren Sie vor einem Update, ob die Quelle weiterhin dieselbe ist und ob zusätzliche Dateien oder geänderte Anweisungen hinzugekommen sind.

Die Auflistung installierter Skills hilft beim Abgleich mit dem geplanten Bestand. Verwenden Sie dafür die von Ihrer Version unterstützte Funktion; das Referenzhandbuch zu gh skill list erläutert die Auflistung. Eine Liste beweist nicht, dass ein Skill sicher ist. Sie hilft Ihnen aber, unbeabsichtigte Installationen oder Abweichungen zwischen erwarteter und tatsächlicher Auswahl zu erkennen.

Mit einem begrenzten Test den Installationsumfang abnehmen

Führen Sie die Einführung zunächst mit einem unkritischen Skill und einem nicht sensiblen Repository durch. Prüfen Sie anschließend diese Schritte, bevor Sie den Ablauf auf weitere Projekte übertragen:

1. CLI-Version und verfügbare Optionen prüfen. Rufen Sie die aktuelle Hilfe für gh skill und die Installationsreferenz auf. Übernehmen Sie keine Syntax aus einer Anleitung, wenn sie nicht zur installierten Version passt.
2. Quelle und Skill-Inhalt erfassen. Notieren Sie das Quellrepository und prüfen Sie SKILL.md, Verzeichnisstruktur, Referenzen und Skripte. Vergleichen Sie die Struktur mit der Agent-Skills-Spezifikation.
3. Vorschau vor der Installation ansehen. Nutzen Sie die dokumentierte Vorschau und vergleichen Sie sie mit den Dateien der Quelle. Ist etwas nicht einsehbar oder nicht nachvollziehbar, installieren Sie den Skill nicht.
4. Den kleinsten passenden Umfang wählen. Für einen gemeinsam genutzten Repository-Workflow beginnen Sie projektbezogen. Für die persönliche Wiederverwendung über mehrere eigene Projekte prüfen Sie, ob die Benutzerinstallation den größeren Einsatzbereich wirklich rechtfertigt.
5. Erkennung und Ablage kontrollieren. Prüfen Sie, ob der vorgesehene Agent-Host den Skill erkennt und ob er an dem von der CLI dokumentierten Ort abgelegt wurde. Erfinden Sie keinen Pfad aus einer fremden Anleitung; maßgeblich sind die aktuelle Dokumentation und das Ergebnis Ihrer Installation.
6. Reproduzierbarkeit und Updates testen. Lassen Sie ein anderes berechtigtes Teammitglied den vorgesehenen Ablauf prüfen. Vergleichen Sie Quelle und Version und klären Sie, wer Updates kontrolliert. Die Update- und Listenfunktionen sind dafür Hilfen, keine Ersatzprüfung.
7. Bei Abweichungen zurückrollen. Wenn der Skill nicht erkannt wird, die Herkunft unklar bleibt oder Dateien vom geprüften Stand abweichen, entfernen Sie ihn nach dem dokumentierten Verfahren oder gehen Sie zu einem engeren Installationsumfang zurück.

Ein erfolgreicher Installationsbefehl ist nur ein technischer Status. Er belegt weder die Sicherheit des Inhalts noch die Zustimmung aller Projektverantwortlichen. Für die Abnahme sollten Sie getrennt festhalten, ob der Skill korrekt installiert wurde, ob der Agent ihn erkennt und ob Herkunft, Umfang und Update-Verantwortung akzeptiert sind.

Wie prüfen Sie später, ob ein Update vertretbar ist? Vergleichen Sie den neuen Stand mit der zuvor geprüften Quelle und Version. Achten Sie auf geänderte Anweisungen, zusätzliche Dateien und neue Skripte. Wenn Sie den Unterschied nicht nachvollziehen können, behalten Sie den freigegebenen Stand bei, sofern Ihre CLI- und Teamrichtlinien das ermöglichen, und klären Sie die Abweichung vor der Aktualisierung.

Die Entscheidung an Verantwortung statt Bequemlichkeit ausrichten

Wählen Sie die Projektebene, wenn ein Skill Bestandteil eines gemeinsamen Repository-Workflows sein soll und Prüfung, Übergabe und Aktualisierung an diesem Projekt hängen. Wählen Sie die Benutzerebene nur dann, wenn die persönliche Wiederverwendung über mehrere Projekte tatsächlich gebraucht wird und Sie den erweiterten Einsatzbereich verantworten können. Bei unklarer Herkunft oder unvollständiger Prüfung ist keine der beiden Installationsarten eine gute Abkürzung: Erst den Inhalt klären, dann installieren.

Wer Skills in mehreren isolierten Entwicklungsumgebungen erprobt, sollte zusätzlich den Zugriff auf Code, Zugangsdaten und Arbeitsbereiche planen. Ein lokaler Rechner kann für langfristige, dauerhaft verfügbare Arbeitsabläufe sinnvoller sein; eine gemietete Mac-Umgebung eignet sich eher für zeitlich begrenzte Tests oder getrennte Entwicklungsplätze. Remote-Umgebungen bringen ihrerseits Zugriffs-, Datenschutz- und Verfügbarkeitsfragen mit sich. Unsere Übersicht zum Mieten eines Mac mini in Japan hilft dabei, diese Alternative für einen konkreten Testarbeitsplatz einzuordnen. Wenn die Skills lediglich dauerhaft in einem festen Repository genutzt werden und dafür bereits passende Hardware vorhanden ist, ist eine zusätzliche Miete nicht nötig.