Skills für AI-Agenten sind eher Arbeitsanweisungen als Plug-ins. Sie legen fest, was ein Agent bei einer bestimmten Aufgabe zuerst prüft, welche Schritte er nicht überspringen darf und wann er eine Entscheidung an einen Menschen zurückgibt. Eine lange Werkzeugliste wirkt beeindruckend. Eine einzige gute Regel kann jedoch wertvoller sein, wenn sie denselben teuren Fehler zuverlässig verhindert.
Um zu sehen, welche Sammlungen tatsächlich Aufmerksamkeit bekommen, habe ich am 12. August 2026 die GitHub-Sterne verglichen. Das ist weder eine Download-Rangliste noch ein Qualitätssiegel. Manche Repositories enthalten wenige Dateien, andere eine komplette Arbeitsumgebung. Die Sterne dienen hier nur als Spur dafür, womit sich viele Entwickler beschäftigen.
1. obra/superpowers: erst nachdenken, dann programmieren
Superpowers ist die meinungsstärkste Sammlung in dieser Auswahl. Der Ablauf führt über Klärung, Entwurf, Aufgabenzerlegung, Implementierung, Tests und Review. Entscheidend ist nicht die Zahl der Skills. Eine Bootstrap-Regel wählt den passenden Skill und macht ihn bei einem Treffer verbindlich.
Das hilft, wenn ein Agent aus einer vagen Anfrage sofort Code macht. Für eine kleine Textkorrektur ist der Ablauf dagegen zu schwer. Ich würde ihn dort einsetzen, wo eine falsche Annahme später teuer wird.
2. affaan-m/ECC: eine komplette Arbeitsumgebung
Everything Claude Code, kurz ECC, ist mehr Distribution als Skill-Paket. Es bündelt Agenten, Befehle, Regeln, Hooks und Skills für Planung, Entwicklung, Review, Tests, Recherche und Sicherheit. Ein Team bekommt damit einen fertigen Ablauf, statt ihn selbst zusammensetzen zu müssen.
Der Preis ist dauerhaft belegter Kontext. Wer alles installiert, lässt den Agenten in jeder Sitzung viele Regeln prüfen. Sinnvoller ist, mit ein oder zwei Befehlen zu beginnen und erst nach einem sichtbaren Nutzen weitere Teile zu übernehmen.
3. mattpocock/skills: bessere Fragen vor der ersten Antwort
Matt Pococks Sammlung ist kleiner und gut lesbar. Das bekannte Muster grill-me führt ein Interview: Der Agent stellt jeweils eine Frage, hält Entscheidungen fest und fragt weiter, bis der Plan umsetzbar ist.
Der Nutzen liegt im Verhalten, nicht in einer hübscheren Ausgabeschablone. Allerdings sind Skill-Datei und aufrufender Befehl teilweise getrennt. Wer nur einen Ordner kopiert, kann eine Anleitung installieren, die nie ausgelöst wird. Der Einstiegspunkt gehört deshalb zur Prüfung.
4. multica-ai/andrej-karpathy-skills: bekannte Prinzipien in kurzer Form
Das Repository fasst bekannte Ratschläge zusammen, die mit Andrej Karpathy verbunden werden: vor dem Programmieren denken, einfach bleiben, Ursachen statt Symptome beheben und überprüfbare Ergebnisse liefern. Die Datei ist kurz und lässt sich ohne zweites Framework in ein bestehendes Projekt legen.
Der Name braucht eine Einordnung. Karpathy ist weder Eigentümer noch Contributor des Repositories. Es handelt sich um eine redaktionelle Zusammenfassung öffentlicher Aussagen, nicht um ein offizielles Produkt oder eine Empfehlung von ihm.
5. anthropics/skills: die offizielle Referenz
Anthropics offizielles Repository enthält produktionsnahe Beispiele für Dokumente, Tabellen, Präsentationen, PDFs, Frontend-Arbeit und das Erstellen eigener Skills. Auch für andere Agenten ist die Struktur interessant: Neben Anweisungen liegen Skripte, Beispiele und Prüfschritte.
Vor einer Übernahme würde ich die Lizenz jedes Ordners prüfen. Offene Komponenten und source-available Dokument-Skills stehen nebeneinander. Eine Veröffentlichung auf GitHub bedeutet nicht automatisch, dass alles unter denselben Bedingungen weitergegeben oder kommerziell genutzt werden darf.
Die Gemeinsamkeit ist Kontrolle, nicht mehr Funktion
Die fünf Projekte geben Agenten nicht einfach mehr Werkzeuge. Sie bremsen sie. Superpowers verhindert den Sprung in die Implementierung, ECC vereinheitlicht Abläufe, grill-me klärt offene Entscheidungen, die Karpathy-Zusammenfassung benennt typische Denkfehler und Anthropics Beispiele verbinden Anweisungen mit Tests und Artefakten.
Gerade deshalb würde ich nicht alle Pakete installieren. Überlappende Regeln verbrauchen Kontext, können sich widersprechen und verschleiern, was ein Ergebnis verbessert hat. Mein Einstieg wäre ein wiederkehrender Fehler, ein kleiner Skill und eine Aufgabe, die sich vor und nach der Installation wiederholen lässt. Sinkt der Review-Aufwand, bleibt der Skill. Werden nur die Antworten länger, fliegt er wieder raus.
Quellen
Was ich vor der Installation prüfen würde
GitHub-Sterne zeigen, welche Projekte Aufmerksamkeit bekommen. Ob ein Skill im eigenen Arbeitsalltag hilft, lässt sich daraus nicht ableiten. Ein Repository kann wegen seines Namens, seines Umfangs oder einer aktiven Community schnell wachsen und trotzdem mehr Abstimmung verursachen, als es einspart.
Ich würde deshalb zunächst genau einen Skill in einem Wegwerfprojekt testen. Dabei schaue ich nicht nur auf das Ergebnis, sondern auf den Weg dorthin: Welche Dateien liest der Agent? Welche Befehle möchte er ausführen? Wo legt er Änderungen ab? Fragt er vor einem nicht rückgängig zu machenden Schritt nach? Diese Punkte sagen meist mehr aus als eine lange Funktionsliste im README.
Für einen fairen Vergleich braucht es eine Ausgangsbasis. Dieselbe Aufgabe wird einmal ohne und einmal mit Skill bearbeitet. Danach notiere ich, wie viele Rückfragen nötig waren, wie viele Korrekturen nach dem ersten Review übrig blieben und wie lange die abschließende Prüfung dauerte. Auch der Tokenverbrauch gehört dazu. Ein umfangreicher Startkontext kann sich bei einem mehrtägigen Projekt lohnen, bei einer kleinen Änderung aber nur Fokus und Zeit kosten.
Bei Skills mit Shell-Zugriff, Browsersteuerung oder externen APIs prüfe ich die Berechtigungen getrennt. Installationsskripte sollten lesbar sein, Abhängigkeiten nachvollziehbar und Aktualisierungen kontrollierbar. Im Team würde ich die ausgewählten Dateien versionieren, statt auf jedem Rechner ungeprüft den neuesten Stand eines beweglichen Branches zu installieren.
Schließlich ist ein öffentliches Repository nicht automatisch für jede kommerzielle Nutzung freigegeben. Vorlagen, eingebundene Inhalte oder verbundene Dienste können andere Bedingungen haben als der eigentliche Quellcode. Die Rangliste ist daher ein guter Ausgangspunkt für Kandidaten. Behalten würde ich nur, was einen wiederkehrenden Fehler verhindert, die Prüfung verkürzt oder eine wichtige Entscheidung zuverlässig bewahrt.
Quellen und Berichte
- obra/superpowersGitHub
- affaan-m/ECCGitHub
- mattpocock/skillsGitHub
- multica-ai/andrej-karpathy-skillsGitHub
- anthropics/skillsGitHub
