Jedes Team, das KI-Coding-Agents eingeführt hat, kennt diesen einen Entwickler, dessen Prompts einfach funktionieren. Seine Review-Anfragen kommen genau so strukturiert zurück, wie das Team es möchte. Seine Anweisungen zum Testschreiben liefern schon beim ersten Versuch Tests, die dem Hausstil entsprechen. Fragt man nach, wie er das macht, kommt meist eine Wegwerfdatei, ein Dotfiles-Repo oder ein Absatz, den er jeden Morgen in eine frische Session einfügt. Das Können ist echt. Das Problem ist, wo es steckt.
Prompt-Handwerk, das nur in einem Kopf existiert, lässt sich nicht skalieren, übersteht keinen Urlaub und taucht in den Agent-Runs anderer gar nicht erst auf. Ist dieser Entwickler nicht da, sinkt die Qualität. Wächst das Team von einem auf fünf Agents, sind sich die fünf uneinig darüber, wie die Arbeit erledigt werden soll.
Skills sind Sharklys Antwort auf diese Lücke. Ein Skill bündelt wiederverwendbare Anweisungen und unterstützende Dateien für die Arbeit von Agents – mit einem Eigentümer, einem Scope und expliziten Berechtigungen. Wer zuerst das allgemeine Konzept sucht: Was ein Coding-Agent-Skill ist behandelt die Definition und das breitere Ökosystem. In diesem Beitrag geht es um den Workflow innerhalb von Sharkly selbst.
TL;DR
Ein Skill in Sharkly bündelt wiederverwendbare Anweisungen und unterstützende Dateien für Agent-Arbeit: Review-Regeln, Delivery-Checklisten, Schreibstandards, einen Teamprozess. Du erstellst eines von Grund auf, installierst einen veröffentlichten Skill aus einer unterstützten öffentlichen Quelle, importierst einen, den eine lokale Runtime entdeckt hat, oder lädst eine SKILL.md, eine .skill-Datei oder ein Zip-Paket hoch. Jeder Skill hat genau einen Scope – Organisation, Space oder Agent –, der bei der Erstellung gewählt und dauerhaft festgelegt wird. Agents binden berechtigte Skills über ihre Skill-Einstellungen ein, Änderungen greifen bei späteren Runs, und die Bearbeitungsrechte liegen beim Ersteller, bei Organisationsinhabern und Admins. Das Ergebnis: Prompt-Handwerk lebt nicht mehr in den Dotfiles eines einzelnen Entwicklers, sondern wird geteilte, berechtigungsgesteuerte Team-Infrastruktur.
Was sich ändert, wenn Prompt-Handwerk ein Zuhause bekommt
Der Unterschied zwischen einem guten Prompt und einem Skill liegt nicht im Text. Er liegt in allem, was den Text umgibt.
Ein Prompt in einer Wegwerfdatei hat keinen Eigentümer, keine Zielgruppe und keinen Lebenszyklus. Niemand weiß, dass es ihn gibt, niemand kann sagen, ob die in Slack gefundene Kopie aktuell ist, und niemand ist dafür verantwortlich, ihn zu aktualisieren, wenn sich der Prozess ändert. Ein Skill hat all das. Er gehört einer Organisation. Sein Scope legt genau fest, welche Agents ihn verwenden dürfen. Seine Bearbeitungsberechtigungen legen genau fest, wer ihn ändern darf. Wenn sich der Prozess ändert, aktualisierst du den Skill einmal, und spätere Runs aller gebundenen Agents übernehmen die Änderung.
Das ist die Hebel-These im Kleinen. Team-Hebel entsteht nicht dadurch, dass man mehr KI-Chats öffnet, sondern dadurch, dass man Rollen, Regeln, Kontext und Workflows teilt. Und weil Agents ihre Ergebnisse an die Task zurückgeben, landet das Resultat eines Skill-gesteuerten Runs im gemeinsamen Protokoll, wo das Team es prüfen kann.
Eine Abgrenzung vorab. Ein Skill ist keine Task-Anforderung. Einmalige Anforderungen gehören in die Task-Beschreibung oder in die Kommentare. Wenn nur diese eine Task es braucht, ist es Kontext. Wenn auch die Runs des nächsten Monats es brauchen, ist es Infrastruktur.
Einen Skill von Grund auf erstellen
Ein Skill beginnt mit drei Dingen: einem Namen, einer Beschreibung und Anweisungen. Die Aufteilung ist wichtiger, als sie aussieht.
Die Beschreibung legt fest, wann der Agent den Skill verwenden soll. Sie ist die Auslösebedingung – der Satz, der einem Agent, der seine Fähigkeiten durchgeht, sagt, dass dieser Skill für die gerade anstehende Arbeit gilt. Die Anweisungen definieren den wiederholbaren Prozess und das erwartete Ergebnis: die Schritte, die Prüfungen, das Format, das das Resultat haben soll. Ein guter Test: Kannst du in einem Satz sagen, wann ein Agent zu diesem Skill greifen sollte? Wenn nicht, hast du es wahrscheinlich mit zwei Skills zu tun – oder mit keinem.
Unter der Haube stehen die primären Anweisungen in einer SKILL.md-Datei: oben die YAML-Felder name und description, gefolgt von den Anweisungen. Unterstützende Dateien können mitgeliefert werden, um Vorlagen, Beispiele oder Referenzdaten bereitzustellen. Ein Delivery-Checklist-Skill könnte die Checklisten-Vorlage enthalten; ein Skill zum Schreiben von Migrationen vielleicht zwei kommentierte Beispiele. Halte sie fokussiert. Große oder unzusammenhängende Dateisammlungen fügen Kontext hinzu, ohne die Entscheidungen des Agent zu verbessern.
Das Handwerk importieren, das ihr schon habt
Die meisten Teams starten nicht bei null. Das Prompt-Handwerk existiert bereits – es ist nur verstreut. Sharkly bietet dir drei Importwege.
Aus einer unterstützten öffentlichen Quelle installieren. Sharkly kann einen veröffentlichten Skill abrufen und eine verwaltete Kopie im gewählten Scope anlegen. Die verwaltete Kopie ist entscheidend: Du verlinkst nicht die Datei von jemand anderem, sondern legst einen Snapshot an, den deine Organisation kontrolliert. Prüfe die Quelle und den importierten Inhalt, bevor du ihn an einen Agent bindest. Behandle externe Anweisungen wie Fremdcode, nicht wie vertrauenswürdige Organisationsrichtlinien.
Aus einer lokalen Runtime importieren. Dieser Weg ist genau für das Dotfiles-Problem gemacht. Eine lokale Runtime, die online ist, kann Skills melden, die sie in ihren lokalen Skill-Verzeichnissen entdeckt – so wird das Handwerk, das ein Entwickler still und leise angesammelt hat, für die Organisation sichtbar. Beim Import wird der Skill in die Organisation kopiert; die lokale Originalkopie bleibt davon getrennt, sodass am Setup dieses Entwicklers nichts kaputtgeht. Ein Hinweis hält das ehrlich: Lokale Skills, die der Runtime eines Agent direkt zur Verfügung stehen, müssen im Produkt überhaupt nicht gebunden werden. Importiere einen, wenn daraus ein verwalteter, wiederverwendbarer Skill mit explizitem Scope werden soll – nicht nur, weil er existiert.
Ein Paket hochladen. Wenn der Skill in einem Repo liegt oder von einem Kollegen stammt, lade eine SKILL.md, eine .skill-Datei oder ein Zip-Paket hoch. Sharkly validiert, was hereinkommt: Dateipfade müssen relativ sein und dürfen nicht aus dem Skill herausführen, und Upload und Import lehnen versteckte oder sensible Pfade, nicht unterstützte Binärinhalte, unsichere Archiveinträge, doppelte Pfade und Pakete über den Dienstgrenzen ab. Ein Skill ist eine Anweisung, der ein Agent folgen wird; er verdient dieselbe Prüfung wie eine Dependency.
Scope: Wer einen Skill nutzen darf
Jeder Skill gehört zu einer Organisation und hat genau einen Scope, der bei der Erstellung gewählt wird. Der Scope entscheidet, welche Agents ihn binden können, und lässt sich später nicht mehr ändern.
| Scope | Wer ihn nutzen darf | Wähle ihn, wenn | Bindungsregel |
|---|---|---|---|
| Organisation | Berechtigte Agents in der gesamten Organisation | Die Prozedur wirklich unternehmensweit gilt, etwa ein Review-Standard oder eine Sicherheits-Checkliste | Von jedem Agent in derselben Organisation bindbar |
| Space | Agents, die diesem Space zugeordnet sind | Ein Team oder Produktbereich den Prozess verantwortet | Ein Agent kann ihn nur binden, wenn der Agent zu diesem Space gehört |
| Agent | Nur ein Agent | Die Fähigkeit die Rolle eines einzelnen Spezialisten definiert | Wird beim Erstellen oder Importieren an seinen Ziel-Agent gebunden |
Die Faustregel aus der Doku ist die richtige: Wähle den engsten Scope, der zur beabsichtigten Zielgruppe passt. Der Scope ist zugleich ein Schadensradius. Ein veralteter Skill mit Space-Scope verwirrt die Agents eines Teams; einer mit Organisations-Scope verwirrt alle. Ein Dotfiles-Prompt hat dauerhaft eine Zielgruppe von genau einer Person. Die Zielgruppe eines Skill ist eine bewusste Entscheidung, die im System festgehalten wird.
Skills an Agents binden
Ein Skill tut nichts, solange ihn kein Agent mitführt. In Sharkly ist ein Agent eine gespeicherte Arbeitskonfiguration, und das Binden eines Skill fügt ihm eine Fähigkeit hinzu.
Die Mechanik ist überschaubar. Über die Skill-Einstellungen des Agent kannst du berechtigte Skills hinzufügen oder entfernen, oder du wählst Skills direkt beim Erstellen des Agent aus. Die Berechtigung folgt den Scope-Regeln. Änderungen greifen bei späteren Agent-Runs, sodass eine heute hinzugefügte Bindung die Arbeit von morgen prägt, ohne laufende Vorgänge zu stören.
Die Ermessensfrage ist, wie viele Skills ein Agent mitführen sollte. Die Doku ist deutlich: Vermeide es, viele sich überschneidende Skills zu binden, denn widersprüchliche oder redundante Anweisungen machen die Ausführung weniger vorhersehbar. Zwei präzise Skills schlagen sechs, die sich gegenseitig widersprechen. Wenn die Skill-Liste eines Agent wie eine Schublade voller Krimskrams aussieht, werden seine Runs genauso aussehen.
Es gibt außerdem eine Arbeitsteilung zwischen den eigenen Anweisungen des Agent und seinen Skills. Agent-Anweisungen tragen das stabile Verhalten für diese eine Rolle: Zuständigkeit, wann menschliche Hilfe angefragt wird, Berichtsformat. Eine wiederverwendbare Prozedur, die mehrere Agents teilen können, gehört in einen Skill. Wenn du denselben Absatz in die Anweisungen eines dritten Agent kopierst, will dieser Absatz ein Skill werden.
Das Binden sorgt dafür, dass die übrige Plattform erst ihre volle Wirkung entfaltet. Derselbe Agent, der deinen Review-Skill mitführt, ist derjenige, den deine Automations nach Zeitplan oder bei einer Statusänderung auslösen – so taucht ein einmal festgehaltener Standard in wiederkehrenden Runs auf, die niemand manuell startet. Skills sind auch skriptbar: Die CLI bietet sharkly skill list und sharkly skill view mit JSON-Ausgabe.
Governance: Wer bearbeitet, wer löscht, wer prüft
Geteilte Fähigkeiten brauchen geteilte Kontrolle – und hier unterscheiden sich Skills am stärksten von Prompt-Dateien.
Ein Skill kann von seinem Ersteller oder von einem Organisationsinhaber bzw. Admin bearbeitet oder gelöscht werden. Ein Skill mit Space-Scope erfordert zusätzlich Schreibzugriff auf den jeweiligen Space. Das Erstellen oder Importieren eines Skill mit Agent-Scope und das Ändern der Skill-Bindings eines Agent erfordern die Berechtigung, den Ziel-Agent zu verwalten. Niemand schreibt am Freitagnachmittag heimlich den Review-Standard um.
Die Pflege folgt demselben Prinzip der einen Stelle. Wenn sich ein Prozess ändert, aktualisierst du die Anweisungen und unterstützenden Dateien des Skill, und spätere Runs übernehmen die neue Version. Beim Löschen sollte man besonders langsam machen: Es entfernt den Skill aus jedem Agent, der ihn nutzt – prüfe also zuerst die aktuellen Bindings.
Die Sicherheitsregeln sind kurz und nicht verhandelbar. Speichere niemals Passwörter, Access Tokens, private Schlüssel oder andere Geheimnisse in den Anweisungen oder unterstützenden Dateien eines Skill. Prüfe jeden externen oder lokal importierten Skill, bevor du ihn verwendest. Gestalte Befehle und Beispiele mit minimalen Berechtigungen. Und prüfe die Bindings erneut, nachdem du die Space-Zuordnungen eines Agent oder den Inhalt eines Skill geändert hast, denn die Berechtigung kann sich unter einer Bindung verschieben.
Bei alldem gilt der Vertrag zwischen Mensch und Agent weiter. Agents laden Skills, folgen dem Prozess und geben Ergebnisse an die Task zurück. Menschen entscheiden, welche Skills Team-Verbindlichkeit haben. Ein Skill hebt das Mindestniveau an Konsistenz. Den Reviewer ersetzt er nicht.
Wann man besser keinen Skill erstellt
Skills sind Infrastruktur, und Infrastruktur verursacht Unterhaltskosten. Die ehrliche Entscheidungsregel: Einmalige Anforderungen gehören in die Task-Beschreibung oder in Kommentare; einen Skill erstellst du, wenn dieselbe Fähigkeit über künftige Runs hinweg verfügbar sein soll.
Es gibt noch ein paar Fälle, in denen die richtige Antwort „kein Skill“ lautet. Wenn eine Prozedur im Skill-Verzeichnis einer lokalen Runtime liegt und nur die Runs dieses Computers sie brauchen, lass sie lokal. Wenn sich zwei Kandidaten-Skills für denselben Agent stark überschneiden würden, führe sie zusammen oder schärfe sie, bevor du einen davon bindest. Und wenn du den Beschreibungssatz nicht formulieren kannst, ist der Prozess noch nicht stabil genug, um ihn festzuhalten.
Fang mit einer Prozedur an
Such dir eine Prozedur aus, die dein Team wiederholt und für die es still und leise von einer Person abhängt. Schreibe sie als einen einzigen, eng gefassten Skill: einen Namen, eine Beschreibung, die angibt, wann er gilt, Anweisungen, die den Prozess und das erwartete Ergebnis definieren. Gib ihm den Scope deines Space. Binde ihn an einen Agent, weise diesem Agent eine echte Task zu und lies, was zurückkommt.
Das ist der ganze Kreislauf. Das Handwerk, das in einem Entwicklerkopf lebte, hat jetzt einen Namen, einen Scope, einen Eigentümer und eine einzige Stelle zum Aktualisieren. Wenn du neu auf der Plattform bist: Die Sharkly-Übersicht erklärt, wie Skills neben Tasks, Agents und Computers stehen, und Erste Schritte mit Sharkly führt die erste Verbindung von Anfang bis Ende durch. Die Skills-Dokumentation behandelt jede der oben genannten Regeln ausführlich.
FAQ
Worin unterscheidet sich ein Skill von den Anweisungen eines Agent?
Agent-Anweisungen definieren stabiles Verhalten für eine Rolle: ihre Zuständigkeit, wann um Input gebeten wird, wie berichtet wird. Ein Skill ist eine wiederverwendbare Prozedur, die mehrere Agents teilen können, verpackt mit eigenen unterstützenden Dateien und Berechtigungen. Wenn ein Absatz zwischen Agents hin und her kopiert wird, gehört er in einen Skill.
Kann ich den Scope eines Skill nach der Erstellung ändern?
Nein. Der Scope eines Skill wird bei der Erstellung festgelegt und ist dann fix. Wenn sich die Zielgruppe ändern soll, erstelle einen neuen Skill mit dem passenden Scope und binde die Agents neu, die ihn brauchen. Deshalb empfiehlt die Doku, von Anfang an den engsten Scope zu wählen, der zur beabsichtigten Zielgruppe passt.
Bleiben importierte Skills mit ihrer Quelle synchron?
Nein. Die Installation aus einer unterstützten öffentlichen Quelle erstellt eine verwaltete Kopie im gewählten Scope, und beim Import aus einer lokalen Runtime wird der Skill in die Organisation kopiert, während die lokale Originalkopie getrennt bleibt. Ab dann kontrolliert deine Organisation ihre eigene Kopie.
Wirkt sich das Binden eines neuen Skill auf die aktuell laufenden Tasks eines Agent aus?
Nein. Änderungen an den Skill-Bindings eines Agent greifen bei späteren Agent-Runs. Bereits laufende Arbeit wird mit der Konfiguration abgeschlossen, mit der sie begonnen hat, und der nächste Run übernimmt das aktualisierte Skill-Set.
Sind Skills aus öffentlichen Quellen sicher zu installieren?
Sie können es sein – mit Prüfung. Behandle jeden externen oder lokal importierten Skill wie Fremdcode oder Fremdkonfiguration: Lies die Anweisungen und unterstützenden Dateien, bevor du ihn bindest, halte Befehle mit minimalen Rechten und lass niemals Geheimnisse in einen Skill gelangen. Sharklys Upload-Validierung lehnt unsichere Pfade und Archiveinträge ab, doch die Einschätzung, ob Anweisungen das Vertrauen deines Teams verdienen, bleibt bei den Menschen.
