Wie Sie einen Skill über mehrere Repositories hinweg pflegen

Angenommen, Sie schreiben einen Skill für die Überprüfung von API-Änderungen. Er fordert Ihren Coding-Assistenten auf, Berechtigungen zu prüfen, Kompatibilität zu wahren und abgelehnte Anfragen zu testen. Er funktioniert so gut, dass Sie ihn aus Ihrem Billing-Repository in Ihren Accounts-Service und Ihre öffentliche API kopieren.

Dann findet ein Reviewer eine fehlende Prüfung. Der Assistent hat geprüft, ob ein Benutzer angemeldet war, aber übersehen, ob dieser Benutzer der Eigentümer des Datensatzes war. Sie verbessern den Skill in Billing. Die anderen beiden Kopien enthalten noch die alten Anweisungen.

Sie könnten die Korrektur erneut kopieren. Aber jemand hat bereits die öffentliche API-Version geändert, um einen älteren Client zu unterstützen. Das Ersetzen dieser Datei würde seine Änderung löschen. Sie unverändert zu lassen würde die fehlende Prüfung bestehen lassen.

Hier wird aus dem Teilen eines Skills dessen Pflege. Sie müssen wissen, welche Anweisungen geteilt werden, welche Unterschiede beabsichtigt sind und wie eine Verbesserung die Nutzer erreicht.

Entscheiden Sie, wann eine Aktualisierung ein Repository erreichen soll

Ein gemeinsamer Speicherort beantwortet, wo der Skill liegt. Er beantwortet nicht, wann jemand mit der Nutzung einer Änderung beginnen sollte.

Bei einem Schreib-Skill möchten Sie vielleicht, dass alle bei ihrer nächsten Aufgabe klarere Anweisungen erhalten. Bei einem Release-Skill möchten Sie vielleicht, dass jedes Repository ein neues Verfahren prüft, bevor es es verwendet. Keine der beiden Richtlinien ist für jeden Skill richtig.

Es gibt mehrere Möglichkeiten, diese Wahl zu treffen.

Die Skills einer Person über Projekte hinweg

Wenn Sie der einzige Nutzer sind, kann ein persönliches Skills-Verzeichnis ausreichen. Claude Code unterstützt beispielsweise persönliche Skills über Projekte hinweg auf einem Rechner. Es unterstützt auch Skill-Verzeichnisse, die mit einem anderen Speicherort auf der Festplatte verknüpft sind. Dies sind dokumentierte Funktionen, sodass das Kopieren eines Skills in jedes Repository in diesem Fall unnötig ist. Siehe Skill-Speicherorte von Claude Code.

Eine Verknüpfung kann mehrere Projekte auf eine lokale Kopie verweisen. Sie kann den Rechner eines Teammitglieds nicht aktuell halten. Sobald eine andere Person den Skill benötigt, entscheiden Sie, wie sie diese Kopie und ihre Aktualisierungen erhält.

Ein gemeinsames Git-Repository mit geprüften Aktualisierungen

Bewahren Sie Skills in einem separaten Repository auf, wenn Sie ihre Historie und ihren Prüfprozess in Git wünschen. Jedes nutzende Projekt kann eine gewählte Revision über ein Submodul einbinden. Git zeichnet für dieses Submodul einen bestimmten Commit auf; es folgt nicht stillschweigend jeder Änderung am gemeinsamen Repository. Siehe Submodul-Dokumentation von Git.

Das gibt einem Repository-Eigentümer eine klare Entscheidung: die aktuellen Anweisungen behalten oder eine neuere Revision übernehmen. Es fügt außerdem jedem nutzenden Projekt eine Aktualisierungsaufgabe hinzu. Ihr Setup muss den Skill dort ablegen, wo das Coding-Tool ihn entdecken kann, und neue Checkouts müssen den Inhalt des Submoduls abrufen.

Wählen Sie diesen Ansatz, wenn es wichtiger ist, die genauen Anweisungen identifizieren und wiederherstellen zu können, als jede Verbesserung sofort zu erhalten. Das Pinning der Anweisungen macht die Modellausgabe nicht identisch, aber es entfernt eine Änderungsquelle.

Gemeinsame Anweisungen bei Bedarf abrufen

Ein anderer Ansatz besteht darin, das Coding-Tool den Skill von einem gemeinsamen Dienst anfordern zu lassen. MCP bietet eine Verbindung, über die ein Tool diese Anweisungen abrufen kann. Bei einem Dienst, der die aktuelle Version zurückgibt, kann eine Aktualisierung die nächste Anfrage erreichen, ohne jedes Repository zu ändern.

Dies tauscht lokale Aktualisierungsarbeit gegen die Abhängigkeit vom Dienst. Entscheiden Sie, was passiert, wenn eine Anfrage fehlschlägt. Wenn Sie eine Fallback-Kopie behalten, halten Sie fest, woher sie stammt und wann sie zuletzt aktualisiert wurde. Andernfalls haben Sie das Problem der vergessenen Kopie unter einem anderen Namen neu geschaffen.

Meine Empfehlung ist, die Aktualisierungsrichtlinie vor dem Verteilungsinstrument zu wählen. Verwenden Sie geprüfte Revisionen für Verfahren, die eine kontrollierte Übernahme erfordern. Rufen Sie aktuelle Anweisungen ab, wenn das Team eine gemeinsame, aktuelle Version wünscht. Ein Team kann beides für verschiedene Skills verwenden.

Trennen Sie die Regel vom Repository-Detail

Selbst eine perfekte Verteilung kann eine billing-spezifische Anweisung nicht überall nützlich machen.

Betrachten Sie diese Anweisung:

Führen Sie die Billing-API-Tests aus und prüfen Sie dann, dass Benutzer nicht die Rechnungen eines anderen Kunden lesen können.

Sie enthält eine wiederverwendbare Prüfung und lokale Details. Teilen Sie diese Ideen auf:

Prüfen Sie für jeden geänderten Endpunkt, der auf einen benutzereigenen Datensatz zugreift, sowohl Eigentümerschaft als auch Authentifizierung. Finden Sie den dokumentierten Testbefehl des Repositorys und testen Sie die abgelehnte Anfrage über den Endpunkt.

Der gemeinsame Skill beschreibt nun, was geprüft werden soll. Das Repository liefert seinen Testbefehl und Domänenbeispiele.

Das bedeutet nicht, jede Anweisung vage zu machen. „Befolgen Sie Best Practices“ gibt einem Assistenten wenig zu tun. „Prüfen Sie, ob ein authentifizierter Benutzer auf den Datensatz eines anderen Benutzers zugreifen kann“ benennt einen konkreten Fehler und bleibt dennoch über Services hinweg nützlich.

Ein nützlicher Bearbeitungstest ist die Frage, ob ein Satz im zweiten Repository noch Sinn ergeben würde. Wenn er ein lokales Skript, Verzeichnis oder Deployment-Ziel nennt, legen Sie dieses Detail neben das Projekt, dem es gehört. Sagen Sie dem gemeinsamen Skill, wo er danach suchen soll und was zu tun ist, wenn es fehlt.

Prüfen Sie außerdem, was Sie teilen. Die Agent Skills-Spezifikation definiert einen Skill als Verzeichnis, das neben SKILL.mdSkripte, Referenzen und Assets enthalten kann. Ein Dokument, das auf scripts/check-api.py verweist, ist ohne dieses Skript unvollständig. Das alleinige Verschieben des Markdown verschiebt nicht seine Abhängigkeiten.

Behandeln Sie eine Überschreibung als separate Version zur Pflege

Manchmal braucht die öffentliche API wirklich andere Anweisungen. Vielleicht hängen ihre alten Clients von einem Antwortfeld ab, das interne Services nicht mehr verwenden.

Halten Sie diese Ausnahme eng. Halten Sie fest, warum sie existiert, wer sie besitzt und was es Ihnen ermöglichen würde, sie zu entfernen. Wenn möglich, behalten Sie das gemeinsame Verfahren bei und liefern Sie die lokale Einschränkung separat.

Wenn Ihr Tool den gesamten Skill ersetzt, sobald es eine Repository-Überschreibung findet, wird die Überschreibung zu einer weiteren zu pflegenden Version. Eine Korrektur am gemeinsamen Skill erreicht sie nicht unbedingt.

Für die Eigentümerschaftsprüfung in unserem Beispiel sollte der Maintainer beide Versionen prüfen. Die Kompatibilitätsregel der öffentlichen API erklärt nicht, warum sie eine Eigentümerschaftsprüfung verpassen sollte. Das sind unabhängige Belange.

Dies ist auch ein Grund, das Überschreiben einer gesamten Skill zu vermeiden, nur um einen Testbefehl zu ändern. Eine kleine lokale Abweichung sollte Sie nicht dazu zwingen, eine zweite Kopie jeder gemeinsamen Regel zu pflegen.

Testen Sie eine Verbesserung, bevor Sie sie teilen

Eine klarer wirkende Anweisung kann dennoch eine schlechtere Überprüfung erzeugen. Behalten Sie einige echte Aufgaben aus Repositories, die die Skill verwenden, zusammen mit dem erwarteten Ergebnis.

Der Agent Skills Evaluierungsleitfaden empfiehlt, Läufe mit einer Skill gegen eine Baseline zu vergleichen, die die vorherige Version sein kann. Verwenden Sie frische Sitzungen, damit frühere Diskussionen nicht Anweisungen liefern, die der Skill selbst nicht enthält. Beurteilen Sie beobachtbare Ergebnisse, nicht ob die Antwort gründlich klingt.

Wählen Sie für die API-Review-Skill tatsächliche frühere Änderungen aus, die diese Fälle abdecken:

Frühere Änderung zur Auswahl	Worauf in der Überprüfung zu achten ist
Ein bekannter Ownership-Fehler	Identifiziert den Zugriffsfehler und verweist auf den relevanten Code
Eine Korrektur, die Ownership bereits erzwingt	Erkennt den Schutz, anstatt den alten Befund zu wiederholen
Eine Änderung, die das Legacy-Antwortfeld betrifft	Respektiert die dokumentierte Kompatibilitätsbeschränkung der öffentlichen API
Eine Änderung außerhalb des API-Verhaltens	Vermeidet es, API-Befunde zu erfinden, um die Checkliste zu erfüllen

Führen Sie die alte und die überarbeitete Skill gegen dieselben Änderungen aus. Halten Sie Eingaben, Anweisungen und Ausgaben zusammen. Wenn ein Ergebnis Sie überrascht, wiederholen Sie den Vergleich, bevor Sie entscheiden, dass die Änderung geholfen hat.

Der zweite Fall ist genauso wichtig wie der erste. Eine Anweisung, die einen Assistenten dazu bringt, jedem Endpunkt fehlende Zugriffsprüfungen vorzuwerfen, hat das Rauschen erhöht, selbst wenn sie den ursprünglichen Fehler erkennt.

Übertragen Sie einer Person oder einem Team die Verantwortung für die Annahme gemeinsamer Änderungen. Teammitglieder sollten Verbesserungen beitragen können, aber jemand muss entscheiden, ob die Beweise dafür ausreichen, sie zum Standard zu machen.

Wo SourceAnt passt

SourceAnt unterstützt den Shared-Service-Ansatz. Eine Workspace-Skill ist über seine Repositories hinweg verfügbar. Verbundene Coding-Tools können nach einer Skill suchen, sie lesen oder sie über einen MCP-Prompt anfordern. Das Aktualisieren der Workspace-Skill ändert, was eine nachfolgende Anfrage abruft, es sei denn, dieses Repository hat eine Überschreibung. Der Skills-Leitfaden deckt Einrichtung und Verwendung ab.

Das macht es überflüssig, in jedem Checkout eine separate Anweisungsdatei aktuell zu halten. Es macht es nicht überflüssig, Änderungen zu testen oder Ausnahmen zu pflegen. SourceAnts Repository-Überschreibungen ersetzen die Workspace-Version; sie führen spätere Bearbeitungen nicht darin zusammen. Anweisungen, die bereits in eine Konversation eingelesen wurden, müssen nach einer Aktualisierung erneut angefordert werden.

SourceAnt über MCP

Verwenden Sie eine gemeinsame Skill aus Ihrem Coding-Tool

1. Finden Sie die SkillGeben Sie das Präfix ein. Jede Workspace-Skill ist mit ihrem Zweck aufgelistet.

   > /sourceant:skill

   • /sourceant:skill:test-cultureBeschreiben Sie das Test-Framework, das Layout und die sichtbaren Grenzen, ohne Abdeckung oder Qualität anzunehmen.
   • /sourceant:skill:contract-consistencyPrüfen Sie, ob geänderte Eingaben, Ausgaben, Fehler oder Zugriffsregeln bestehende Konsumenten brechen.
   • /sourceant:skill:duplicate-implementationPrüfen Sie, ob neu hinzugefügter Code bestehendes Verhalten dupliziert und ein konkretes Problem einführt.
2. Geben Sie ihm eine AufgabeFügen Sie hinzu, woran gearbeitet werden soll. Nennen Sie ein Repository, um dessen eigene Version der Skill zu verwenden, falls vorhanden.

   > /sourceant:skill:contract-consistency

   task

   Überprüfen Sie die Änderung am Rechnungsendpunkt

   repository

   billing

3. Arbeiten Sie mit der aktuellen VersionSourceAnt sendet die neuesten Anweisungen mit Ihrer Aufgabe in die Konversation.

   An den Assistenten gesendet

   Wenden Sie die Skill zur Überprüfung der Vertragskonsistenz auf die angeforderte Aufgabe an.

   Verfolgen Sie jeden geänderten Vertrag vom Code, der einen Wert erzeugt, bis zum Code, der ihn verwendet.

   1. Lesen Sie beide Seiten. Vergleichen Sie akzeptierte Eingaben, zurückgegebene Felder, Fehlerbehandlung und Zugriffsprüfungen.

   Repository: billing

   Angeforderte Aufgabe:
   Überprüfen Sie die Änderung am Rechnungsendpunkt

Beginnen Sie mit einer Skill, die Sie bereits in zwei Repositories verwenden. Vergleichen Sie die Kopien. Verschieben Sie die wirklich gemeinsamen Anweisungen in eine gepflegte Version und notieren Sie, warum die verbleibenden Unterschiede bestehen. Bevor Sie die nächste Bearbeitung verteilen, testen Sie sie an einer echten Aufgabe aus jedem Repository. Das gibt Ihnen eine nützliche Antwort auf die Frage, die das Kopieren allein nicht klären kann: Hat die Änderung beiden Projekten genutzt?