CODEZ / Über die Website und die Datenmethodik
Über CODEZ: Skill-Aufnahme, Sterne-Ranking und Datenmethodik
CODEZ.WIN ist ein nachvollziehbares Verzeichnis zur Ermittlung von Agentenfähigkeiten. Es hilft Ihnen, Kandidaten anhand von Aufgaben zu finden und anschließend zum ursprünglichen Repository zurückzukehren, um Beschreibungen, Abhängigkeiten und Lizenzen zu überprüfen. Diese Seite erklärt, wie die Nummern und Tags im Verzeichnis generiert werden und was sie nicht beweisen.
Methodenverifizierung:
Katalog-Snapshot:
Dieser Abschnitt dokumentiert die auf dieser Website verwendeten Regeln zur Datenerfassung und -darstellung. Beschreibungen von Drittanbietern gehören ihren jeweiligen Autoren; Methodenerklärungen und Auswahlvorschläge werden von CODEZ zusammengestellt und bearbeitet. Die Aufnahme in diesen Abschnitt bedeutet nicht, dass das Projekt Praxistests, Sicherheitsprüfungen oder Kompatibilitätszertifizierungen unterzogen wurde.
Welche Quellen werden aktuell berücksichtigt?
Der aktuelle Snapshot enthält 11 Repositories und 611 Skills; die Quellenliste umfasst 11 konfigurierte Repositories. In diesem Durchlauf wurden 0 Repository-Erfassungsfehler protokolliert, und 0 Repositories behalten ältere Daten.
Die folgende Tabelle listet die Daten nach Quelle und nicht nach Beliebtheit auf. „Nicht als abgelaufen markiert“ bedeutet lediglich, dass kein Fehler auf Repository-Ebene vorliegt; es garantiert keine vollständige Dateilesung. Werden nur einige Quellen aktualisiert, können andere Repositories ältere Daten enthalten; daher kann der Zeitpunkt der Momentaufnahme für den gesamten Batch nicht als Erfassungszeitpunkt für jede Quelle verwendet werden.
Ursprüngliche Quell-Repositories und öffentliche Daten dieses Snapshots:
| Quell-Repository | Repository-Sterne | Erfasste Skills | Datenerfassungsstatus |
|---|---|---|---|
| anthropics/skills | 183,533 | 20 | Nicht als abgelaufen gekennzeichnet |
| openai/skills | 28,289 | 44 | Nicht als abgelaufen gekennzeichnet |
| vercel-labs/agent-skills | 32,960 | 9 | Nicht als abgelaufen gekennzeichnet |
| obra/superpowers | 304,663 | 15 | Nicht als abgelaufen gekennzeichnet |
| microsoft/skills | 3,145 | 209 | Nicht als abgelaufen gekennzeichnet |
| vercel-labs/open-agents | 5,862 | 13 | Nicht als abgelaufen gekennzeichnet |
| anthropics/knowledge-work-plugins | 32,664 | 252 | Nicht als abgelaufen gekennzeichnet |
| huggingface/skills | 11,209 | 26 | Nicht als abgelaufen gekennzeichnet |
| cloudflare/skills | 3,166 | 19 | Nicht als abgelaufen gekennzeichnet |
| supabase/agent-skills | 2,923 | 2 | Nicht als abgelaufen gekennzeichnet |
| duixcom/duix-skills | 12 | 2 | Nicht als abgelaufen gekennzeichnet |
Warum fehlen manche Skills im Katalog?
Die Datenerfassung durchsucht ausschließlich öffentliche, nicht deaktivierte Repositories in der Quellenliste und verwendet dabei den Dateibaum des Standard-Branches. Das aktuelle Limit pro Repository liegt bei 300 Kandidaten-SKILL.md-Dateien. Wird dieses Limit überschritten oder der Dateibaum abgeschnitten, meldet die gesamte Repository-Erfassung einen Fehler, und die abgeschnittenen Daten werden nicht als vollständiges Ergebnis veröffentlicht.
Pfade mit diesen Verzeichnisbestandteilen sind derzeit ausgeschlossen: /test/, /tests/, /fixtures/, /node_modules/, /examples/. Dateinamen müssen auf SKILL.md enden, und das YAML-Frontmatter muss nicht leere Zeichenketten in name und description enthalten. Skripte Dritter werden nicht ausgeführt.
Dies ist die Schwelle für auswertbare Einträge auf dieser Website, keine Überprüfung aller Anforderungen der Agentenfähigkeiten-Spezifikation. Einzelne Dateien, die nicht gelesen werden können, denen die erforderlichen Metadaten fehlen oder die nicht analysiert werden können, werden möglicherweise übersprungen; Elemente, die nicht in der Quellenliste enthalten sind, werden nicht automatisch erkannt.
Warum zeigen verschiedene Skills denselben Sternestand?
Sterne gehören zu GitHub-Repositories. Skills innerhalb desselben Repositorys zeigen die Sterne dieses Repositorys an; diese Zahlen geben nicht an, wie oft ein einzelner Skill als Favorit markiert wurde, und sollten auch nicht über verschiedene Skills hinweg addiert werden. GitHub verwendet Sterne, um Wertschätzung und Anerkennung auszudrücken; daher dienen sie auf dieser Website als Orientierungshilfe.
Die Repository-Rangliste der Startseite ist nach absteigender Sternenzahl und bei Gleichstand nach Repository-ID sortiert. Der vollständige Skill-Katalog ist nach dem Sternestand des Repositorys und dann nach Skill-Name und ID stabil sortiert. Die Kartennummer bezeichnet die Katalogposition, keine Leistungsnote. Auf der Startseite lassen sich auch andere Sortierungen wie Name wählen.
| Felder | Tatsächliche Bedeutung | Daraus kann keine Beurteilung vorgenommen werden. |
|---|---|---|
| Repository-Sterne | Die von GitHub während der Datenerfassung zurückgegebene Popularität des Repositorys. | Erfolgsquote oder Sicherheit einer einzelnen Fertigkeit |
| Anzahl erfasster Skills | Anzahl der Einträge, die in diesem Snapshot analysiert und beibehalten werden können. | Alle Fähigkeiten, Qualität oder Kompatibilität des Repositorys |
| Datum der Repositoryaktualisierung | Zeitpunkt des letzten Push im GitHub-Repository | Welche kürzlichen Fehlerbehebungen gab es für die von Ihnen verwendete Fertigkeit? |
Wurde die Einstufung vom Autor angegeben oder von dieser Website festgelegt?
Die Kategorisierung basiert auf der Einzel-Tag-Regel dieser Website. Zuerst werden manuelle Überschreibungen vorgenommen, anschließend werden die Regeln für Cloud-Dienste und Agenten-Workflows in Name und Pfad geprüft. Die verbleibenden Einträge werden anhand der Anzahl der Übereinstimmungen mit Schlüsselwörtern in Name, Beschreibung und Skill-Pfad bestimmt. Einträge ohne Übereinstimmung werden als „Sonstige“ kategorisiert. Bei gleicher Anzahl an Übereinstimmungen wird die Reihenfolge der Regeln angewendet.
Eine Fähigkeit kann Entwicklung, Daten, Forschung und andere Aufgaben umfassen. Das Verzeichnis bietet nur eine Hauptkategorie, was zu Fehlklassifizierungen führen kann. Eine Kategorie beweist nicht die Kompatibilität mit einem bestimmten Client; nach dem Filtern sollten Sie die Datei SKILL.md, die README-Datei und die Abhängigkeitsbeschreibungen lesen. Zur Fehlerbehebung benötigen Sie das spezifische Repository, den Pfad zur Datei SKILL.md und die zugehörige Dokumentation für diese Kategorie.
Die folgende Tabelle dokumentiert unsere manuelle Kategorienprüfung für konkrete Dateien. Die alten Kategorien stammen aus dem öffentlichen Katalog zum Prüfzeitpunkt. Grundlage ist der verlinkte Originaltext bei einem festgelegten Commit. Hier wurden nur Katalogkategorien geändert; die Skills wurden nicht ausgeführt, und die Prüfung belegt nicht ihre Wirkung in allen Clients.
| Skill | Klassifizierung vor der Überprüfung | Aktuelle Kategorie | Grundlage unserer Beurteilung | Datenprüfung |
|---|---|---|---|---|
| obra/superpowers / brainstorming | Design | Agenten-Workflow | Vor der Umsetzung die Klärung von Absicht, Anforderungen und Design organisieren. Zentrale Ergebnisse sind gemeinsam getroffene Entscheidungen und Spezifikationen. | 2026-10-07 |
| obra/superpowers / verification-before-completion | Sonstige | Agenten-Workflow | Verlangt, den Prüfungsbefehl zu bestimmen und die vollständige Ausgabe zu prüfen, bevor der Abschluss behauptet wird. Im Mittelpunkt stehen Abnahme und Übergabe des Agenten. | 2026-10-07 |
| obra/superpowers / writing-skills | Dokumente | Agenten-Workflow | Behandelt das Erstellen und Bearbeiten von Skills sowie die Prüfung des Agentenverhaltens unter Druckszenarien. Im Mittelpunkt steht der Ablauf zum Schreiben und Validieren von Agent Skills. | 2026-10-07 |
| anthropics/skills / pdf | Design | Dokumente | Die Beschreibung behandelt Extraktion, Zusammenführen, Aufteilen und Erstellen von PDFs sowie OCR bei Scans. Die zentralen Ein- und Ausgaben sind Dokumente; Python-Beispiele dienen der Umsetzung. | 2026-10-08 |
| openai/skills / pdf | Entwicklung | Dokumente | Die wichtigsten Ergebnisse im Zusammenhang mit dem Lesen, Erstellen und Darstellen von PDFs vor der Auslieferung sind die Überprüfung des Dokuments und seines Layouts, nicht die Softwareentwicklungsaufgaben. | 2026-10-08 |
| vercel-labs/open-agents / frontend-design | Agenten-Workflow | Design | Leitet die Umsetzung von Frontend-Oberflächen anhand von Typografie, Farben, Layout und Animationen an; die wesentlichen Ergebnisse sind Oberflächendesign und Code. | 2026-10-11 |
| cloudflare/skills / cf-cli | Entwicklung | Cloud-Dienste | Behandelt Vorgänge über die Cloudflare API, Workers-Bereitstellungen sowie die Verwaltung von DNS-, D1-, KV- und R2-Ressourcen; im Mittelpunkt stehen Cloud-Dienste, und die Quelldatei kennzeichnet die CLI als beta. | 2026-10-13 |
| cloudflare/skills / gateway-workers | Entwicklung | Cloud-Dienste | Behandelt die Forward-Aktion in den HTTP-Richtlinien von Cloudflare Gateway, Workers und den GatewayMiddleware-Einstiegspunkt; der Schwerpunkt liegt auf Cloud-Diensten. Es wurde nur der Quelltext des Dokuments geprüft; der Skill wurde nicht ausgeführt. | 2026-10-19 |
CODEZ: Workflow-Skills nach Aufgabenphase auswählen ↗
CODEZ: Quellenvergleich und Abnahmekriterien für zwei PDF-Skills ↗
obra/superpowers / skills/brainstorming/SKILL.md ↗
obra/superpowers / skills/verification-before-completion/SKILL.md ↗
obra/superpowers / skills/writing-skills/SKILL.md ↗
anthropics/skills / skills/pdf/SKILL.md ↗
openai/skills / skills/.curated/pdf/SKILL.md ↗
vercel-labs/open-agents / .agents/skills/frontend-design/SKILL.md ↗
Können alle öffentlichen Repositories direkt in eigenen Projekten verwendet werden?
Die öffentliche Sichtbarkeit eines GitHub-Repositories und seine Lizenz sind unterschiedliche Informationen. CODEZ weist weiterhin auf Unsicherheiten bei der Lizenz hin und leitet eine Nutzungserlaubnis weder aus dem Projektnamen noch aus Werbeaussagen im README oder der Möglichkeit zum Herunterladen ab.
| Label | Quellenbasis der Website | Vor Gebrauch prüfen |
|---|---|---|
| SPDX-Kennungen wie MIT / Apache-2.0 | Ohne eine eigene Lizenzdatei näher am Skill in der Verzeichnisstruktur wird die von GitHub erkannte Repository-Lizenz verwendet. | Originaler Lizenztext, Anwendungsbereich und Lizenz für zusätzliche Inhalte |
| Lizenzdatei: Prüfung ausstehend | Im Verzeichnis „Skill“ oder in dessen übergeordneten Verzeichnissen wurde eine separate Lizenzdatei gefunden, oder die Lizenz im Stammverzeichnis wurde nicht erkannt. | Zugehöriger Dateiinhalt; verwendet nicht automatisch die Repository-Root-Lizenz. |
| Nicht angegeben | Es konnte keine identifizierbare Lizenzgrundlage gefunden werden. | Wenden Sie sich an das ursprüngliche Projekt, um die Autorisierung zu bestätigen, und verwechseln Sie nicht Lesbarkeit mit Genehmigung. |
Woher stammen die chinesischen und englischen Anweisungen?
Oberfläche und eigene Erläuterungen werden in dreizehn Sprachen gepflegt. Für Zusammenfassungen Dritter werden derzeit chinesische und englische README-Dateien neben SKILL.md erkannt; ausdrücklich benannte Sprachdateien haben Vorrang, README.md wird anhand seines Textes eingeordnet. Chinesische und englische Oberflächen bevorzugen die passende kurze Originalzusammenfassung. Andere behalten die ursprüngliche SKILL.md-Beschreibung. Verfügbare chinesische und englische README-Links bleiben erhalten.
Ist die entsprechende Sprache nicht verfügbar oder kann die Zusammenfassung nicht extrahiert werden, wird auf die Originalbeschreibung in der Datei SKILL.md zurückgegriffen. Die allgemeine README-Datei des Repositorys wird nicht als Einführung zu einer einzelnen Fertigkeit interpretiert, und automatisch übersetzte Inhalte werden nicht als Originaltext des Autors ausgegeben. Daher kann der chinesische Originaltext weiterhin in der englischen Benutzeroberfläche erscheinen und umgekehrt.
Wenn die Datenerfassung fehlschlägt, werden die alten Daten dann als heutige Daten behandelt?
Der Server beginnt täglich um 10:37 Uhr Pekinger Zeit mit der Datenerfassung und generiert nach Abschluss statische Seiten aus MySQL. Der Zeitpunkt der Momentaufnahme gibt an, wann dieser Datenstapel generiert wurde; er wird nicht von allen Quellen gleichzeitig gelesen und entspricht auch nicht dem Änderungszeitpunkt der einzelnen Projekte.
Schlägt eine Anfrage an ein Repository fehl, werden die Daten der letzten erfolgreichen Anfrage an dieses Repository wiederverwendet. Die Rangliste und diese Seite werden dann als „Verwendung alter Daten“ gekennzeichnet. Schlägt die Anfrage bei allen Datenquellen fehl, bleibt der ursprüngliche Snapshot erhalten und es wird ein Fehler gemeldet. Fehler auf Repository-Ebene werden im ursprünglichen Verzeichnis-JSON gespeichert. Lesefehler einzelner Dateien können lediglich übersprungen und in das Sammlungsprotokoll geschrieben werden. Das gesamte Repository wird nicht automatisch als abgelaufen markiert. Daher hat die Meldung „Erfolgreich in dieser Runde“ weiterhin Einschränkungen hinsichtlich der Datenabdeckung.
Die Originaldatei-Links verweisen auf den Standardbranch zum Erfassungszeitpunkt; das Quellprojekt kann sich später ändern. Notieren Sie für eine Reproduktion den konkreten Commit und Dateipfad auf GitHub, statt nur die Zahlen unserer Website zu speichern.
Wie können diese Informationen für konkrete Entscheidungen genutzt werden?
Zuerst sollten Sie die Kandidaten anhand der Aufgabe und der Ein-/Ausgabe eingrenzen. Anschließend prüfen Sie die Umgebung, den Betriebsumfang und die Berechtigungen. Führen Sie abschließend einen kleinen Test mit denselben Eingabedaten durch und dokumentieren Sie die Ergebnisse. Repository-Sterne, Verzeichniskategorien und Autorenbeschreibungen können bei der Kandidatensuche hilfreich sein, ersetzen aber nicht die eigentlichen Tests.
Der bestehende Auswahlleitfaden dieser Website bietet wiederverwendbare Verifizierungsmethoden und Beispiele. Bei den Beispielen handelt es sich nicht um tatsächliche Testergebnisse für ein konkretes Projekt; nachfolgende Projektanalysen werden ebenfalls zwischen öffentlich verfügbaren Daten und tatsächlichen Tests unterscheiden.