Cursor Agent Skills installieren: mattpocock/skills 2026

Am 13.08.2026 zeigt die Projektseite von skills.sh für mattpocock/skills 51 Skills und 15,3 Millionen Installationen. Diese dynamische Zahl ist kein Qualitätsbeweis, aber sie erklärt die aktuelle Nachfrage. Für Cursor Agent Skills installieren gilt daher: Führen Sie npx skills@latest add mattpocock/skills im Stammverzeichnis Ihres Projekts aus, wählen Sie eine begrenzte Skill-Auswahl und starten Sie danach einmal setup-matt-pocock-skills. Verwenden Sie projektbezogene Dateien für Teamregeln. Skills übernehmen dynamische Abläufe, Cursor Rules dauerhafte Vorgaben. Mit Claude Code wählen Sie zwischen Plugin und editierbaren Dateien. Installieren Sie nicht beides.

Für wen diese Anleitung gedacht ist: Für Entwickler, die in Cursor TDD, Fehlerdiagnose und Code-Reviews kontrolliert einsetzen möchten. Für technische Verantwortliche, die Agent-Verhalten über Git versionieren wollen. Und für verteilte Teams, die lokale und entfernte Mac-Arbeitsplätze reproduzierbar einrichten müssen.

Letzte Aktualisierung: 13.08.2026. Die Installationsschritte wurden gegen das aktuelle README von mattpocock/skills, die skills.sh-CLI-Dokumentation und die Cursor-Dokumentation zu Rules und Agent Skills geprüft.

Die richtige Installationsgrenze entscheidet über spätere Wartbarkeit

Der häufigste Fehler passiert vor dem ersten Befehl: Die Installation wird aus dem falschen Verzeichnis gestartet oder ohne klare Zuständigkeit zwischen Projekt- und Benutzerkonfiguration durchgeführt.

Cursor unterscheidet zwischen projektbezogenen und benutzerspezifischen Einstellungen. Skills können in projektbezogenen Verzeichnissen wie .cursor/skills oder .agents/skills liegen und damit zusammen mit dem Repository verwaltet werden. Benutzerweite Verzeichnisse sind dagegen für persönliche Arbeitsweisen geeignet, die nicht automatisch Bestandteil jedes Teamprojekts sein sollen.

Für ein Teamprojekt ist die Entscheidung normalerweise eindeutig:

• Projektinstallation: Skill-Dateien werden mit Git geprüft, reviewt und bei Bedarf zurückgerollt.
• Benutzerinstallation: Persönliche Präferenzen bleiben außerhalb des Repositorys.
• Gemischte Installation: Nur dann sinnvoll, wenn Sie persönliche Hilfen bewusst von Teamprozessen trennen.

Die versteckten Kosten einer unklaren Grenze sind erheblich:

1. Ein neues Teammitglied sieht andere Skills als die übrigen Entwickler.
2. Ein Agent führt einen Ablauf aus, der im Repository nicht dokumentiert ist.
3. Ein Update überschreibt lokale Anpassungen oder erzeugt doppelte Skill-Namen.
4. Ein Remote-Mac-Arbeitsplatz startet ohne dieselben Projektdateien.
5. Sicherheitsprüfungen werden erschwert, weil nicht klar ist, welche Dateien tatsächlich geladen werden.

Cursor unterstützt Agent Skills seit Version 2.4 vom 22.01.2026 im Editor und in der CLI. Die Veröffentlichung beschreibt SKILL.md-Dateien als Träger für Anweisungen, Skripte und benutzerdefinierte Befehle. Gleichzeitig grenzt Cursor Skills von dauerhaft geladenen Rules ab. Details im offiziellen Cursor-Changelog.

Projektordner oder globaler Ordner?

Prüfen Sie vor dem Start:

• Befinden Sie sich im Stammverzeichnis des richtigen Git-Repositorys?
• Ist git status sauber oder sind vorhandene Änderungen dokumentiert?
• Haben Sie Schreibrechte auf das Repository?
• Sind Node.js, npx und Git verfügbar?
• Arbeiten Sie für den Erstversuch auf einem separaten Branch?
• Ist geklärt, ob die Dateien unter .cursor/skills oder .agents/skills landen sollen?

Die skills.sh-CLI wird über npx gestartet und muss nicht als globale Anwendung installiert werden. Die offizielle CLI-Dokumentation verwendet dafür das Muster npx skills add <skill-name>. CLI-Referenz von skills.sh.

Erstinstallation: mattpocock/skills kontrolliert in Cursor einführen

Führen Sie den Befehl nicht in einem beliebigen Terminalfenster aus. Öffnen Sie zuerst das Ziel-Repository und wechseln Sie dann in dessen Root-Verzeichnis:

cd /pfad/zu/Ihrem-repository
git status
git switch -c chore/install-agent-skills
npx skills@latest add mattpocock/skills

Der Installer führt Sie durch zwei Entscheidungen:

1. Welche Skills sollen installiert werden?
2. Für welchen Agent sollen sie verfügbar sein?

Wählen Sie nicht automatisch den gesamten Bestand. Für einen ersten Teamtest reichen beispielsweise:

• setup-matt-pocock-skills
• tdd
• diagnosing-bugs oder diagnose
• code-review
• triage

Die konkreten Namen müssen Sie am Installationstag aus dem aktuellen Auswahlfenster und dem aktuellen Repository prüfen. Veraltete Blogbeiträge können Skill-Namen enthalten, die inzwischen geändert oder entfernt wurden.

setup-matt-pocock-skills gehört in die erste Auswahl. Ohne diesen Skill können die Dateien zwar vorhanden sein, aber die projektspezifische Einrichtung des Workflows fehlt. Das README beschreibt, dass der Setup-Ablauf unter anderem nach Issue-Tracker, Triage-Labels und dem Speicherort erzeugter Dokumente fragt. Aktuelles Repository-README von mattpocock/skills.

Nach dem Installationsdialog prüfen Sie die Dateistruktur:

find .cursor .agents -maxdepth 3 -type f -name 'SKILL.md' 2>/dev/null
git status --short
git diff --stat

Achten Sie dabei auf vier Punkte:

• Jede ausgewählte Skill-Definition besitzt eine erwartete SKILL.md.
• Die Dateien liegen im Ziel-Repository und nicht nur im Benutzerverzeichnis.
• Nur bewusst ausgewählte Skills erscheinen im Git-Diff.
• Keine bestehende Teamregel wurde unabsichtlich verändert.

Wenn der Installer in Ihrem Umfeld zusätzliche Optionen für Scope, Agent oder Zielpfad anbietet, dokumentieren Sie die Auswahl im Pull Request. Das verhindert später die Diskussion, ob eine Datei absichtlich projektweit oder nur lokal installiert wurde.

Setup im Repository: manuell starten, automatisch entdecken lassen

Öffnen Sie das Repository jetzt in Cursor. Starten Sie im Agent-Modus:

/setup-matt-pocock-skills

Führen Sie den Setup-Skill einmal pro Repository aus. Der Ablauf sollte mindestens diese Entscheidungen festhalten:

• Welcher Issue-Tracker ist verbindlich?
• Welche Labels verwendet Ihr Team bei der Triage?
• Wo speichert der Agent erzeugte Dokumente, Spezifikationen oder Entscheidungsnotizen?
• Welche Pfade dürfen von Skripten gelesen oder verändert werden?
• Welche Dateien dürfen niemals automatisch bearbeitet werden?

Die manuelle Schrägstrich-Aufrufweise und die automatische Entdeckung sind nicht dasselbe:

• Manueller Aufruf: Sie verlangen ausdrücklich einen bestimmten Skill.
• Automatische Entdeckung: Cursor entscheidet anhand der Beschreibung und des Aufgabenkontexts, ob ein Skill relevant ist.
• Dauerhafte Projektregel: Eine Rule wird als Kontext geladen oder anhand ihrer Konfiguration angehängt.

Damit ein Skill automatisch gefunden wird, muss Cursor die Datei im gültigen Suchpfad sehen. Prüfen Sie deshalb zuerst die Verzeichnisstufe und anschließend die SKILL.md. Besonders wichtig sind Name, Beschreibung und Frontmatter. Eine formal vorhandene Datei mit fehlerhaften Metadaten kann unsichtbar bleiben.

Cursor beschreibt Skills als dynamisch ladbare Fähigkeiten, während Rules als persistente Anweisungen dienen. Die Unterscheidung ist für die Fehlersuche entscheidend: Wenn eine Anweisung immer gelten soll, gehört sie nicht ausschließlich in einen Skill. Cursor-Leitfaden zu Agent-Workflows.

Wenn der Skill nicht in Cursor erscheint

Arbeiten Sie die Ursachen in dieser Reihenfolge ab:

1. Falsches Repository geöffnet: Der Terminalpfad und der in Cursor geöffnete Workspace stimmen nicht überein.
2. Falscher Scope: Die Datei liegt im Benutzerbereich, obwohl Sie eine Projektinstallation erwarten.
3. Fehlerhafte Struktur: Der Skill-Ordner enthält keine korrekt benannte SKILL.md.
4. Unvollständige Metadaten: Beschreibung oder erforderliches Frontmatter fehlen.
5. Alte Sitzung: Cursor wurde nach der Installation nicht neu geladen.
6. Doppelte Quelle: Derselbe Skill liegt in mehreren Suchpfaden und erzeugt unklare Treffer.
7. Agent-Auswahl: Der Installer hat den Skill nicht für den tatsächlich verwendeten Agent eingerichtet.

Laden Sie das Fenster erst nach der Dateiprüfung neu. Ein Neustart kann helfen, ersetzt aber keine Kontrolle von Pfad und Inhalt. Nutzen Sie anschließend die Skills- oder Agent-Ansicht und suchen Sie nach setup-matt-pocock-skills.

Für Cursor Rules gilt eine andere Struktur: Projektregeln liegen in .cursor/rules, sind versionierbar und können mit description, globs oder alwaysApply gesteuert werden. Globale User Rules gelten dagegen für Ihre gesamte Cursor-Umgebung. Offizielle Dokumentation zu Cursor Rules.

Skills und Cursor Rules: dynamischer Ablauf gegen dauerhafte Vorgabe

Die Frage „Cursor Skills und Rules – was gehört wohin?“ lässt sich mit einem einfachen Test beantworten:

Muss diese Anweisung bei fast jeder Aufgabe gelten, oder wird sie nur bei einem bestimmten Arbeitsschritt gebraucht?

Ein Skill ist ein Werkzeugkasten für einen konkreten Vorgang. Er kann Skripte, Referenzdateien und Entscheidungslogik enthalten. Ein Rule-Set ist die dauerhafte Leitplanke. Es beschreibt, wie der Agent im Projekt grundsätzlich arbeiten soll.

Ein belastbares Beispiel:

• tdd erklärt, wie eine Funktion testgetrieben in kleinen Schritten umgesetzt wird.
• Eine Rule schreibt vor, welchen Testbefehl das Projekt verwendet.
• diagnosing-bugs beschreibt den Diagnoseablauf.
• Eine Rule verbietet Änderungen an Produktionsdatenbanken ohne Freigabe.
• code-review strukturiert die Prüfung.
• Eine Rule definiert, welche Sicherheits- und Datenschutzanforderungen immer gelten.

Vermeiden Sie, denselben Satz in fünf Skills und drei Rules zu kopieren. Doppelte Vorgaben erhöhen die Wahrscheinlichkeit, dass der Agent widersprüchliche Prioritäten erhält. Schreiben Sie die dauerhafte Grenze einmal in die Rule und verweisen Sie im Skill nur auf den relevanten Projektpfad oder Befehl.

Der erste reale Auftrag: kleiner Test statt Vollbetrieb

Installieren Sie nicht sofort alle Skills und geben Sie dem Agent keinen großen Refactoring-Auftrag. Verwenden Sie einen kleinen, bereits bekannten Vorgang. Ein guter Test besitzt:

• eine klar abgegrenzte Datei oder Funktion,
• einen reproduzierbaren Fehler oder eine kleine Erweiterung,
• einen vorhandenen Testbefehl,
• einen erwarteten Git-Diff,
• eine Person, die das Ergebnis fachlich prüfen kann.

Ein möglicher Ablauf:

1. Starten Sie mit einer kurzen Anforderung und bitten Sie den Agent, offene Fragen zu sammeln.
2. Rufen Sie den TDD-Skill manuell auf.
3. Lassen Sie nur einen kleinen Testfall ergänzen.
4. Prüfen Sie, ob der Agent den im Repository definierten Testbefehl verwendet.
5. Lassen Sie anschließend den Diagnose- oder Review-Skill auf den Diff anwenden.
6. Vergleichen Sie das Ergebnis mit Ihrer erwarteten Prozessabfolge.

Bewerten Sie nicht nur den erzeugten Code. Prüfen Sie auch den Kontext:

• Wurde der richtige Skill verwendet?
• Wurde ein nicht ausgewählter Skill behauptet?
• Wurden Skripte aus dem Skill-Verzeichnis ausgeführt?
• Hat der Agent Dateien außerhalb des Workspace angesprochen?
• Wurde eine Rule korrekt berücksichtigt?
• Ist der Git-Diff für eine menschliche Prüfung verständlich?

Ein häufiger Fehler in Dokumentationen ist die Verwendung historischer Skill-Namen. Schreiben Sie im Teamhandbuch deshalb nur Namen, die im aktuell installierten Repository wirklich vorhanden sind. Wenn diagnosing-bugs in Ihrer Version anders heißt, übernehmen Sie nicht blind die ältere Bezeichnung.

Team-Governance: Updates nicht direkt auf den Hauptbranch anwenden

Die editierbare Installation über skills.sh ist für Teams attraktiv, weil die Dateien wie normaler Projektcode behandelt werden können. Genau daraus entsteht aber eine Verantwortung: Ein Skill kann Anweisungen, Skripte und Referenzdateien enthalten. Installationszahlen oder Popularität ersetzen keine Sicherheitsprüfung. Die Dokumentation von skills.sh weist ausdrücklich darauf hin, dass die Qualität und Sicherheit jedes einzelnen Skills nicht garantiert werden kann. Sicherheitshinweise in der skills.sh-Dokumentation.

Legen Sie deshalb einen kleinen Update-Prozess fest:

1. Prüfen Sie regelmäßig das Upstream-Repository.
2. Lesen Sie das Änderungsprotokoll und den README-Abschnitt vor dem Update.
3. Erstellen Sie einen separaten Update-Branch.
4. Führen Sie npx skills update nicht direkt auf dem Hauptbranch aus.
5. Vergleichen Sie geänderte SKILL.md-Dateien, Skripte und Referenzen.
6. Prüfen Sie neue Shell-Befehle, Dateioperationen und Netzwerkzugriffe.
7. Führen Sie den kleinen Referenzauftrag erneut aus.
8. Lassen Sie mindestens eine zweite Person den Diff prüfen.
9. Mergen Sie erst nach erfolgreicher Teamfreigabe.
10. Halten Sie einen Rollback auf den vorherigen Commit bereit.

Das README beschreibt für die editierbare Variante ausdrücklich, dass Änderungen nicht automatisch im Hintergrund einfließen und mit npx skills update bewusst eingespielt werden. Installations- und Update-Hinweise im Repository.

Was gehört ins Repository?

Versionieren sollten Sie:

• ausgewählte SKILL.md-Dateien,
• zugehörige Skripte und Referenzdokumente,
• .cursor/rules mit Teamvorgaben,
• eine kurze Installations- und Update-Anleitung,
• die dokumentierte Auswahl des Ziel-Agents,
• den Testauftrag für die Abnahme.

Nicht automatisch versionieren sollten Sie:

• persönliche Antwortstile,
• private Zugangsdaten,
• lokale Pfade,
• individuelle Shell-Aliase,
• personenbezogene Agent-Verläufe,
• Zugangstoken oder API-Schlüssel.

Setzen Sie zusätzlich Dateirechte und Arbeitsbereichsgrenzen. Ein Skill, der Shell-Befehle ausführt, sollte nicht stillschweigend Zugriff auf .env-Dateien, SSH-Schlüssel oder Produktionsdaten erhalten. Cursor bietet für die CLI projektbezogene und globale Berechtigungskonfigurationen. Dokumentation zu Cursor-Berechtigungen.

Abnahmecheckliste für den ersten Teamdurchlauf

Verwenden Sie diese Liste im Pull Request oder im internen Übergabeprotokoll:

• [ ] Der Befehl wurde im Stammverzeichnis des richtigen Repositorys ausgeführt.
• [ ] Der Installations-Branch ist dokumentiert.
• [ ] Node.js, npx und Git funktionieren im Zielsystem.
• [ ] setup-matt-pocock-skills wurde ausgewählt.
• [ ] Nur die benötigten Skills wurden installiert.
• [ ] Die Skill-Dateien liegen im vorgesehenen Projektpfad.
• [ ] Jede Skill-Datei enthält eine prüfbare SKILL.md.
• [ ] Der Git-Diff enthält keine unbeabsichtigten Änderungen.
• [ ] Das Repository wurde nach der Installation in Cursor neu geladen.
• [ ] Der Skill erscheint in der Skills- oder Agent-Ansicht.
• [ ] Der Setup-Ablauf wurde einmal manuell gestartet.
• [ ] Issue-Tracker, Triage-Labels und Dokumentationspfad sind festgehalten.
• [ ] Die Zuständigkeit zwischen Skills und Cursor Rules ist dokumentiert.
• [ ] Ein kleiner TDD-, Diagnose- oder Review-Auftrag wurde ausgeführt.
• [ ] Agent-Aktionen außerhalb des Workspace wurden geprüft.
• [ ] Skripte und Referenzdateien wurden einer Sicherheitsprüfung unterzogen.
• [ ] Der Update-Prozess verwendet einen separaten Branch.
• [ ] Ein Rollback auf die vorherige Skill-Version ist möglich.
• [ ] Ein zweites Teammitglied hat die Änderungen abgenommen.

Bewerten Sie das Ergebnis mit drei möglichen Statuswerten:

• Freigegeben: Skill-Erkennung, Setup und Referenzauftrag funktionieren reproduzierbar.
• Anpassung erforderlich: Der Ablauf funktioniert, aber Pfade, Rules oder Berechtigungen müssen korrigiert werden.
• Vorläufig zurückgestellt: Skills werden nicht zuverlässig erkannt, Skripte sind unklar oder die Teammitglieder erhalten unterschiedliche Ergebnisse.

Claude-Code-Plugin oder skills.sh: eine Entscheidung, keine Doppelinstallation

Für Claude Code beschreibt das Repository zwei unterschiedliche Modelle:

• Das Plugin ist ein verwaltetes, nicht direkt bearbeitbares Paket.
• skills.sh kopiert editierbare Dateien in Ihr Projekt.
• Das Plugin kann automatisch aktualisiert werden.
• Bei der editierbaren Variante entscheiden Sie selbst, wann Änderungen übernommen werden.
• Beide Varianten parallel zu installieren kann dieselben Skills doppelt bereitstellen.

Wenn Ihr Team in Cursor arbeitet und die Dateien über Git kontrollieren möchte, ist die projektbezogene Installation mit skills.sh die passendere Wahl. Wenn ein Mitglied ausschließlich das verwaltete Claude-Code-Modell benötigt, sollte diese Person nicht zusätzlich dieselbe Skill-Sammlung in denselben Arbeitsbereich kopieren.

Dokumentieren Sie die Entscheidung pro Teamprojekt. Sonst entstehen lokale Unterschiede, die später fälschlich als Cursor- oder Mac-Problem interpretiert werden.

Lokale Einrichtung gegen entfernte Mac-Arbeitsplätze prüfen

Eine vollständige Abnahme braucht zwei identische Durchläufe: einmal auf dem lokalen Rechner und einmal in der vorgesehenen entfernten Mac-Umgebung. Vergleichen Sie dabei nicht nur, ob ein Befehl erfolgreich endet. Prüfen Sie die tatsächlich erzeugten Dateien, die Cursor-Erkennung, den Setup-Dialog und den Git-Diff.

Für die Übergabe eignet sich dieses Protokoll:

Für die entfernte Umgebung sollten Sie zusätzlich festhalten:

• Wie wird das Repository bereitgestellt?
• Wer besitzt Schreibrechte?
• Muss Cursor neu gestartet oder nur neu geladen werden?
• Welche Shell und welcher Node-Pfad werden verwendet?
• Wo landen temporäre Dateien?
• Wie wird ein fehlgeschlagener Skill-Update zurückgerollt?
• Welche Dateien dürfen nicht auf dem entfernten Arbeitsplatz verbleiben?

Für Fragen zu Zugriff, Einrichtung und Wiederherstellung können Sie die MacHTML-Hilfe heranziehen. Wenn Sie den Zustand des Arbeitsbereichs vor dem Test kontrollieren möchten, nutzen Sie zusätzlich die MacHTML-Konsole, um die vorbereitete Umgebung und ihre Zugriffsbedingungen zu prüfen.

Eine allgemeingültige Aussage über die Leistung oder Erkennungsrate einer konkreten entfernten Umgebung wäre ohne dokumentierten Test nicht seriös. Prüfen Sie deshalb zuerst die tatsächliche Zielumgebung und halten Sie Abweichungen als Fehlerprotokoll fest.

Häufige Fragen zur Installation

Wo sollte der npx-Befehl laufen?

Starten Sie die Installation im Root-Verzeichnis des Repositorys, dessen Skills Sie versionieren möchten. Prüfen Sie den Pfad mit pwd und den Git-Kontext mit git status. Arbeiten Sie zunächst auf einem separaten Branch. Wenn Sie den Befehl aus dem Home-Verzeichnis ausführen, landen Dateien möglicherweise nicht dort, wo Cursor und Ihr Team sie erwarten.

Warum bleibt der Skill unsichtbar?

Kontrollieren Sie zuerst Pfad, Dateiname und Frontmatter. Danach müssen Sie sicherstellen, dass in Cursor wirklich der Workspace geöffnet ist, in den der Installer geschrieben hat. Laden Sie das Fenster neu und prüfen Sie die Skills-Ansicht. Eine zweite Installation in einem anderen Scope kann die Diagnose zusätzlich erschweren.

Wie verteilen Sie Rules und Skills im Team?

Versionieren Sie projektbezogene Skills und .cursor/rules gemeinsam mit dem Code. Nutzen Sie Rules für Architektur, Testbefehle, Datenschutz und dauerhafte Konventionen. Verwenden Sie Skills für TDD, Diagnose, Triage und Review-Abläufe. Persönliche Antwortstile gehören in Benutzerregeln und nicht in die zentrale Teamkonfiguration.

Welche Variante ist für Remote-Mac-Teams sinnvoll?

Für reproduzierbare Übergaben ist eine projektbezogene Installation meist besser als ein globaler Ordner. Der entscheidende Vorteil ist nicht der Mac selbst, sondern der nachvollziehbare Git-Zustand. Erst wenn der gleiche Commit, die gleichen Skill-Dateien und derselbe Setup-Ablauf auf beiden Arbeitsplätzen bestätigt sind, sollte das Team die Konfiguration als Standard ausrollen.

Ist eine Doppelinstallation mit Claude Code sinnvoll?

Nein. Wählen Sie entweder das verwaltete Plugin oder die editierbaren Dateien aus skills.sh. Zwei Quellen können dieselben Skills doppelt anzeigen und unterschiedliche Aktualisierungswege erzeugen. Wenn Sie Änderungen im Repository reviewen und anpassen möchten, verwenden Sie die editierbare Variante und führen Updates kontrolliert über einen Branch ein.

Von der lokalen Prüfung zur passenden Mac-Umgebung

Die lokale Installation ist für einen einzelnen Entwickler oft ausreichend. Für Teams entstehen jedoch zusätzliche Schwachstellen: unterschiedliche Node-Versionen, nicht dokumentierte Benutzerordner, fehlende Git-Rechte und manuelle Cursor-Neustarts. Ein gewöhnlicher Arbeitsplatz lässt sich außerdem nicht immer schnell genug für neue Teammitglieder, externe Mitarbeitende oder kurzfristige Testzweige reproduzieren.

Eine entfernte Mac-Umgebung ist nicht automatisch die bessere Lösung. Bei dauerhaft hoher Auslastung, speziellen physischen Schnittstellen oder langfristig stabiler Nutzung kann ein eigener Rechner wirtschaftlicher und technisch sinnvoller sein. Für zeitlich begrenzte Projekte, parallele Agent-Tests und standardisierte Übergaben ist die lokale Einrichtung dagegen häufig zu individuell.

Wenn Sie nach dem Referenztest eine wiederholbare, zurückrollbare Cursor-Arbeitsumgebung benötigen, prüfen Sie bei MacHTML die verfügbaren Arbeitsoptionen. Entscheidend ist nicht, Skills möglichst schnell zu installieren, sondern denselben Agent-Workflow auf jedem vorgesehenen Arbeitsplatz nachvollziehbar ausliefern zu können.

FAQ