Unsere Agent Skills und was darin steckt

Wir bauen eine öffentliche Bibliothek von Agent Skills auf: github.com/timerise-ai/skills. Sieben sind bisher draußen. Jeder ist ein eigenes Repository, das einem Coding-Agenten beibringt, ein einzelnes Modul zu bauen: ein Hilfecenter, einen mehrsprachigen Blog, Bildschirme vor Ort, einen Selbstbedienungs-Kiosk, einen Notfallserver vor Ort, Marktplatz-Zahlungen, die polnische E-Rechnung. Agent Skills ist ein offenes Format, derselbe Ordner läuft also in Claude Code, Codex CLI, Gemini CLI und den anderen Agenten, die Skills lesen.

Dieser Beitrag beschreibt, was wirklich darin steckt, woher die Regeln darin kommen und wo ihre Grenzen liegen. Wenn Sie nur einen installieren wollen, stehen die Befehle unten.

Was ein Skill ist

Ein Skill ist ein Ordner mit Markdown-Dateien, den ein Agent liest, bevor er Code schreibt. Der Agent lädt ihn, wenn eine Aufgabe zu seiner Beschreibung passt, und Sie können ihn auch direkt aufrufen. Nichts darin hängt an einem Anbieter. SKILL.md deklariert einen Namen und eine Beschreibung, alles darunter ist einfaches Markdown über Next.js, Postgres, Firestore oder die API eines Anbieters, und keine Datei ruft ein Modell auf.

Es ist kein Paket. Nichts wird in Ihre Anwendung installiert, es gibt keine Abhängigkeit zu verfolgen oder zu lizenzieren. Der Agent liest den Skill und schreibt das Modul in Ihr Repository: in Ihrem Stack, mit Ihrer Authentifizierung, Ihrer Benennung und Ihrem Designsystem.

Der Unterschied ist schmal, aber real. Ohne den Skill schreibt ein Agent ein Hilfecenter, das richtig aussieht. Mit dem Skill schreibt er das, welches unsere Entwickler bauen, samt der Teile, die erst Sinn ergeben, wenn man weiß, was beim ersten Mal schiefging.

Was darin steckt

Alle haben denselben Aufbau, ein Agent, der einen gelesen hat, weiß also, wie er den nächsten liest.

Vorab gelesen wird nur SKILL.md. Die Referenzen laden bei Bedarf, eine Aufgabe zur Gerätekopplung zieht also nicht das Abrechnungskapitel in den Kontext.

Jeder Skill hat seine eigene Versionslinie und einen gemeinsamen Release-Standard: ein vX.Y.Z Tag, ein Changelog-Eintrag und ein GitHub-Release dazu. Der Index beschreibt diesen Standard in STANDARD.md, samt Aufbau und Schreibregeln, die jeder neue Skill erfüllen muss.

Die Skills bisher

Woher sie kommen

Ein Skill beginnt nicht als leeres Dokument, das jemand mit Best Practices füllt. Er beginnt bei einem Entwickler im Team, der dasselbe Modul mehrfach gebaut hat und weiß, wie es sich verhalten muss.

Das Aufschreiben ist ein eigener Durchgang. Die Person geht die frühere Umsetzung noch einmal durch, schreibt das Modul so, wie sie es heute bauen würde, und formuliert jede Eigenschaft, die es halten muss, als etwas, das die Vorlagen und die Tests prüfen. Was dieser Durchgang geändert hat, was bewusst blieb und was neu ist, landet in provenance.md.

Nichts davon ist synthetisch. Kein Skill entstand aus einem Prompt an ein Modell, und keiner trägt Code aus einem Kundenprojekt.

Deshalb wirken manche Regeln seltsam konkret. Hashe das Gerätetoken vor dem Speichern. Schicke eine Zusammenfassung der Suche an den Browser, nie den ganzen Korpus. Binde die Verkäufer-NIP einer Rechnung an den authentifizierten Steuerpflichtigen. Keine davon ist eine Stilfrage. Jede stammt aus einem echten Betrieb, und der Eintrag sagt, aus welchem.

Jeder Skill benennt außerdem eine kurze Liste nicht verhandelbarer Punkte: Regeln, die mit dem Modul in jedes Projekt mitgehen. Alles andere ist anpassbar, und der Skill sagt, was wozu gehört.

Was sie bringen

Eine Erkenntnis wird einmal aufgeschrieben. Was uns ein Projekt beibringt, wird zur Regel im Skill statt zu einem Commit in einem einzelnen Repository. Alles, was danach entsteht, beginnt an dieser Stelle. Ohne diese Rückkopplung wird derselbe Weg in jedem Projekt neu gegangen.

Das Modul ist dokumentiert, bevor es geschrieben wird. Der Skill ist die Dokumentation. Bei der Übergabe bekommen die übernehmenden Entwickler die Begründungen hinter dem Code, nicht nur den Code.

Weniger an einer Schätzung ist geraten. Ein großer Teil eines Buchungssystems ist Arbeit, die wir bereits erledigt haben, in einer Form, die der Agent reproduzieren kann. Zu schätzen bleibt die Logik, die sich zwischen Projekten wirklich unterscheidet, und dort sitzt auch die interessante Technik.

Reviews werden kürzer. Generierten Code prüft es sich leichter, wenn die Regeln, denen er folgen sollte, aufgeschrieben sind. Statt zu diskutieren, ob ein Ansatz tragfähig ist, gleichen Sie ihn mit einer Liste ab.

Sie können die Bausteine lesen, bevor Sie sich festlegen. Der Index ist öffentlich und jeder Skill darin ebenso. Woraus ein Timerise-System besteht, lässt sich vorab prüfen, ohne uns danach fragen zu müssen.

Selbst installiert gibt Ihnen ein Skill die geprüfte Fassung. Kein plausibel wirkendes, neu geschriebenes Modul, sondern so, wie es jemand baut, der es vielfach ausgeliefert hat, mit den Korrekturen bereits darin.

Was sie nicht tun

Gut zu wissen, bevor Sie einen klonen.

Sie setzen Next.js App Router voraus. Datenmodell und Betriebsregeln lassen sich überallhin übertragen. Die Kapitel zu Routing und Rendering nicht. Die Ausnahme ist island-mode-server: er baut eine Node-Box, die neben der Anwendung steht, nicht in ihr.

Es sind Anweisungen, kein Paket. Sobald der Agent das Modul geschrieben hat, gehört der Code Ihnen. Es gibt keine Version in Ihrer Anwendung, die Sie erhöhen, und ein späteres git pull im Skill-Verzeichnis verbessert das Nächste, was Sie bauen, nicht das Bestehende.

Sie prüfen das Ergebnis weiterhin. Ein Skill verengt den Raum falscher Antworten deutlich. Er ersetzt kein Code-Review und macht aus einem Agenten keinen Entwickler.

Das Backend wählen Sie. Die Datenschicht sitzt hinter einer expliziten Nahtstelle, Firestore, Supabase/Postgres und ein eigener Store-Adapter stehen nebeneinander beschrieben. Auswahl und Anpassung liegen bei Ihnen, nicht beim Skill.

ksef fällt aus der Reihe. Er umschließt eine fremde API statt eines UI-Moduls, geht also von der Spezifikation des polnischen Finanzministeriums aus, korrigiert um Rückmeldungen aus einer laufenden Integration, und sein Korrekturprotokoll ist das Changelog statt provenance.md.

Installation

Am kürzesten geht es mit der CLI von skills.sh. Sie liest das GitHub-Repository direkt und schreibt den Skill in die Agenten, die Sie nennen, ohne manuelles Klonen und ohne Pfade pro Agent:

Sie können einen Skill auch selbst klonen. In Ihr Claude-Code-Skills-Verzeichnis:

Um ihn auf ein einzelnes Projekt zu begrenzen, klonen Sie ihn in dessen .claude/skills/ Verzeichnis. Der Skill aktiviert sich selbst, wenn eine Aufgabe passt, oder Sie rufen ihn per Slash-Befehl auf: /help-center-markdown. Aktualisiert wird mit git pull in seinem Verzeichnis, und CHANGELOG.md sagt Ihnen, was sich geändert hat.

Codex CLI, Gemini CLI und andere Agenten

Codex CLI und Gemini CLI lesen denselben Aufbau, samt dem Laden von references/ bei Bedarf, das einen langen Skill bezahlbar hält. Beide finden Skills in ~/.agents/skills:

Ist ein Skill bereits für Claude Code geklont, verlinken Sie ihn per Symlink, statt ihn zweimal zu klonen, dann aktualisiert ein git pull jeden Agenten:

Der Aufruf unterscheidet sich: $ksef in Codex, /skills in Gemini CLI. Zwei Dinge wandern außerdem nicht von selbst mit. Jeder Host gleicht eine Aufgabe auf seine Art mit der Beschreibung ab, rufen Sie einen Skill beim ersten Mal also ausdrücklich auf, statt anzunehmen, er sei angesprungen. Und die nicht verhandelbaren Punkte in references/adaptation.md sind die Stelle, an der die Modelle am stärksten auseinandergehen, prüfen Sie also, ob die für Ihr Modul wichtigen den Build überstanden haben.

Warum sie öffentlich sind

Wir verkaufen die Skills nicht, sie stehen unter der MIT-Lizenz, und keiner enthält etwas Kundenspezifisches.

Unsere Kunden besitzen den Code, den sie erhalten, also schien es richtig, dass die Bausteine daraus lesbar sind, ohne uns fragen zu müssen. Davon abgesehen ist ein Modul geteilt nützlicher als für uns behalten. Jede Verbesserung aus einem Projekt fließt in den Skill zurück, und dasselbe Repository installiert jeder andere ebenso.

Über den Rest unserer Arbeitsweise haben wir in Wie wir bauen geschrieben.

Wie es weitergeht

Weitere Skills, ergänzt sobald unsere Entwickler die Module aufschreiben, die sie ausgeliefert haben. Jeder wird am Tag seiner Veröffentlichung im Index gelistet, beobachten Sie also das Repository, wenn Sie sie ankommen sehen wollen. Die Sammlung wird außerdem auf skills.sh gelistet, dem offenen Verzeichnis für Agent Skills, damit die Skills neben dem Rest des Ökosystems auffindbar sind.