Unsere Claude Code Skills und was darin steckt

Wir haben fünf Claude Code Skills unter github.com/timerise-ai/skills veröffentlicht. Jeder ist ein eigenes Repository, das einem Coding-Agenten beibringt, ein einzelnes Modul zu bauen: ein Hilfecenter, einen mehrsprachigen Blog, Bildschirme vor Ort, Marktplatz-Zahlungen, die polnische E-Rechnung.

Dieser Beitrag beschreibt, was wirklich darin steckt, woher die Skills 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. Claude Code lädt ihn, wenn eine Aufgabe zu seiner Beschreibung passt, und Sie können ihn auch direkt per Slash-Befehl aufrufen.

Es ist keine Bibliothek. 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 bei uns in Produktion läuft, samt der Teile, die erst Sinn ergeben, wenn man weiß, was beim ersten Mal schiefging.

Was darin steckt

Alle fünf 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.

Die fünf Skills

Woher sie kommen

Ein Skill beginnt nicht als leeres Dokument, das jemand mit Best Practices füllt. Er beginnt als Modul in einem System, das bereits bei einem Kunden läuft.

Das Herauslösen ist ein Audit. Wir lesen den ursprünglichen Code, finden, was daran falsch ist, und schreiben die korrigierte Fassung in den Skill. Jeder Defekt, den dieses Audit findet, landet in provenance.md, direkt neben der Regel, die ihn künftig verhindert.

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 ist ein Fehler, für den jemand bezahlt hat, und der Eintrag sagt, welcher.

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

Ein Fehler wird einmal behoben. Trifft ein Projekt auf einen Defekt, wird die Korrektur zur Regel im Skill statt zu einem Commit in einem einzelnen Repository. Das nächste Projekt hat diesen Fehler nie. Ohne diese Rückkopplung baut ein Team dieselben Fehler still für jeden Kunden neu.

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 korrigierte Fassung. Kein plausibel wirkendes, neu geschriebenes Modul, sondern das, welches die Produktion überstanden hat, mit bereits ausgebauten Defekten.

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.

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

Klonen Sie einen Skill 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.

Warum sie öffentlich sind

Wir verkaufen die Skills nicht, 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 sich Module in Produktion stabilisiert haben. Jeder wird am Tag seiner Veröffentlichung im Index gelistet, beobachten Sie also das Repository, wenn Sie sie ankommen sehen wollen.