Agentenfähigkeiten schreiben und veröffentlichen, die richtig auslösen und die Prüfung bestehen

## Die Beschreibung auf Zweck und Einsatzfall beschränken Behandle die Beschreibung als Metadaten für die Weiterleitung und nicht als verkürzte Vorgehensweise. Agenten können eine Fähigkeit anhand ihrer Beschreibung auswählen, bevor sie den vollständigen Haupttext lesen. Daher können dort eingebettete Arbeitsschritte den ausführlichen Arbeitsablauf außer Kraft setzen oder umgehen. Formuliere Beschreibungen als kurze Aussage zur Fähigkeit, gefolgt von den Auslösebedingungen: was die Fähigkeit leistet und wann sie eingesetzt werden soll. Halte die Beschreibung innerhalb der Grenze des geltenden Schemas, einschließlich einer Obergrenze von 1.024 Zeichen, sofern diese gilt. Nimm niemals geordnete Schritte, Umsetzungsabläufe oder Verfahren zur Fehlerbehebung in die Beschreibung auf; alle praktischen Anleitungen gehören in den Haupttext der Fähigkeit. Prüfe Beschreibungen mit realistischen Eingaben, um sicherzustellen, dass sie bei den vorgesehenen Anfragen auslösen, bei sachfremden Aufgaben inaktiv bleiben und den Agenten zu den vollständigen Anweisungen führen. ## Nur Kopffelder aus der Spezifikation und gültige Verweise auf andere Fähigkeiten nutzen Befolge die geltende Spezifikation für Fähigkeiten, statt Felder aus einem benachbarten Projektarchiv zu kopieren. Behalte auf der obersten Ebene nur die von der Spezifikation festgelegten Felder, darunter `name` und `description`; verwende `license` und `allowed-tools` nur gemäß dem Vertrag des Projektarchivs. Falls `allowed-tools` vorhanden ist, muss es eine durch Leerzeichen getrennte Liste sein. Lege projektspezifische Felder unter `metadata` ab. Beschränke Namen auf Buchstaben, Zahlen und Bindestriche. Prüfe Beschreibungen auf Länge und Formulierung der Auslöser. Halte strukturierte Metadaten wie Urheber, semantische Version, Bereich, Auslöser, Rolle, Geltungsbereich, Ausgabeformat und zugehörige Fähigkeiten innerhalb der vom Projektarchiv festgelegten Aufzählungswerte und Formate. Jeder Eintrag für eine zugehörige Fähigkeit muss sich in ein vorhandenes Fähigkeitsverzeichnis auflösen lassen. Verwende den vom Projektarchiv genehmigten Lizenzwert durchgängig; legt das Projektarchiv MIT als Lizenz fest, schreibe exakt `license: MIT`. Akzeptiere unbekannte Aufzählungswerte, fehlerhafte Verweise oder eigene Felder der obersten Ebene nicht bloß deshalb, weil die YAML-Auswertung sie akzeptiert. ## Die Hauptdatei kurz halten und Details in Referenzdateien auslagern Halte die Hauptdatei der Fähigkeit so kompakt, dass sie als Weiterleitungs- und Arbeitskontext geladen werden kann. Eine zweckmäßige erste Ebene umfasst ungefähr 80 bis 100 Zeilen mit der Rolle, Hinweisen zur Auslösung, einem fünfstufigen Kernarbeitsablauf, verpflichtendem und verbotenem Verhalten sowie einer Weiterleitungstabelle zu ausführlicheren Referenzen. Lege ausführliches technisches Material in gezielten Referenzdateien der zweiten Ebene ab, die üblicherweise jeweils 100 bis 600 Zeilen umfassen. Jede Referenz sollte genau ein Thema behandeln, vollständige lauffähige Beispiele mit den maßgeblichen Typen enthalten, Grenzfälle und Gegenmuster erläutern und angeben, wann die Hinweise verwendet werden sollen und wann nicht. Lade nur die Referenzen, die für die aktuelle Aufgabe erforderlich sind. Verknüpfe verwandte Fähigkeiten bei Bedarf über Querverweise, aber verdopple nicht deren vollständigen Inhalt. Betrachte eine geringere Kontextnutzung als Gestaltungsergebnis; eine gut weitergeleitete zweistufige Struktur kann eine Verringerung um etwa 50% anstreben, ohne notwendige Anweisungen auszulassen. ## In Beispielen die eingebauten Mechanismen des jeweiligen Frameworks nutzen Rahmenwerkspezifische Anleitungen müssen die bewährten Mechanismen des jeweiligen Rahmenwerks nutzen. Wenn das Rahmenwerk eine globale Fehlerbehandlung, eine Vermittlungsschicht, Abhängigkeitsinjektion, Lebenszyklus-Einbindungen oder eine andere eingebaute Abstraktion bereitstellt, sollten Beispiele diesen Mechanismus verwenden, statt ihn von Hand nachzubilden. Erzwinge nicht eine einzige allgemeine Architektur für voneinander unabhängige Rahmenwerke, nur um im gesamten Projektarchiv eine optische Einheitlichkeit zu erreichen. Die Gepflogenheiten des Rahmenwerks für Fehlerbehandlung, Gliederung, Prüfung und Einbindung haben Vorrang. Halte Referenzbeispiele vollständig und ausführbar und nimm Typen auf, wenn die Sprache sie unterstützt. Prüfe Beispiele anhand der Rahmenwerksversion im Geltungsbereich und lehne Muster ab, die eingebautes Verhalten doppelt umsetzen oder rahmenwerkspezifische Einschränkungen verbergen. ## Jede Fähigkeitsdatei mit genau einem Link zur Dokumentation beenden Jede Fähigkeitsdatei muss in ihrer letzten Zeile mit genau einem kanonischen Rückverweis auf die Dokumentation enden. Verwende die Markdown-Verweisschreibweise mit der Beschriftung `Documentation` und der kanonischen URL statt einer bloßen URL, damit strenge Darstellungsprogramme einen echten Verweis erzeugen. Leite den kanonischen Pfad aus stabilen Metadaten wie `metadata.domain` und dem Namen des Fähigkeitsverzeichnisses ab. Wende den dokumentierten Ausweichbereich an, wenn Metadaten fehlen. Wenn du eine Fähigkeit hinzufügst oder umbenennst, aktualisiere Verzeichnis, Bereich und Rückverweis gemeinsam; andernfalls kann der veröffentlichte Verweis zu einer nicht vorhandenen Seite führen. Berücksichtige mehrere Veröffentlichungsflächen ausdrücklich. Sammler unbearbeiteter Dateien benötigen den Rückverweis möglicherweise für die Auffindbarkeit, während die Dokumentationserstellung denselben Selbstverweis aus erzeugten Seiten, Spiegeln und Verzeichnissen für Sprachmodelle ausnehmen kann. Bewahre beide Verhaltensweisen im Synchronisierungsschritt und prüfe das dargestellte Ziel. ## Beim Erstellen oder Ändern einer Fähigkeit Überschneidungen prüfen und Verweise anpassen Für eine neue Fähigkeit: 1. Prüfe vorhandene Fähigkeiten auf sich überschneidende Zuständigkeiten. 2. Verfasse die Hauptfähigkeit mit Metadaten zu Leistung und Auslösung und belasse die Arbeitsschritte im Haupttext. 3. Ergänze gezielte Referenzen für vertiefende Inhalte. 4. Füge eine Weiterleitungstabelle von Themen zu Referenzen hinzu. 5. Hänge den einzigen kanonischen Dokumentationsrückverweis als letzte Zeile an. 6. Prüfe auslösende und nicht auslösende Eingaben. 7. Aktualisiere den Leitfaden für Fähigkeiten und die Bereichsverzeichnisse, wenn sich die Ordnungssystematik ändert. Lies vor der Änderung einer Fähigkeit ihren vollständigen aktuellen Haupttext und die von der Änderung betroffenen Referenzen. Bewahre die aus Leistung und Auslöser bestehende Form der Beschreibung sowie die Architektur der schrittweisen Offenlegung. Aktualisiere Weiterleitungstabellen, Verweise auf zugehörige Fähigkeiten, Dokumentationsverzeichnisse und Auslöseprüfungen, sobald sich Namen, Geltungsbereich, Auslöser oder Abhängigkeiten ändern. ## Zählwerte und Änderungsprotokoll mit einer einzigen Versionsdatei abgleichen Verwende ein einziges Versionsmanifest als maßgebliche Quelle für die Veröffentlichungsversion und berechnete Anzahlen wie Fähigkeiten, Arbeitsabläufe und Referenzdateien. Führe das Aktualisierungswerkzeug des Projektarchivs aus, um die Anzahlen aus dem Dateisystem neu zu berechnen und die erzeugte Dokumentation zu synchronisieren. Unterstütze Prüf- und Probelaufmodi, damit CI und Prüfende Abweichungen erkennen können, ohne etwas zu schreiben. Füge die neue Veröffentlichung mit einer beständigen Gliederung aus Added, Changed und Fixed am Anfang des Änderungsprotokolls ein und pflege den Verweis zum Versionsvergleich. Aktualisiere Leitfäden, Entscheidungsbäume, Befehlstabellen und Querverweise für neue oder geänderte Inhalte, bevor du die zusammengefasste Dokumentation neu erzeugst. Erzeuge soziale Medieninhalte mit eingebetteten Anzahlen nur dann neu, wenn sich diese Anzahlen ändern; eine Korrektur, die nur die Version ändert, erfordert keinen neuen Inhalt. Prüfe die erzeugten Unterschiede, damit die Automatisierung keine sachfremden Änderungen verdeckt. ## Vor der Veröffentlichung die Prüfwerkzeuge für Fähigkeiten und Markdown ausführen Führe vor der Veröffentlichung den Integritätsprüfer für Fähigkeiten aus. Er muss die YAML-Auswertung, Pflichtfelder, das Namensformat, die Länge der Beschreibung und den erforderlichen Auslösesatz `Use when`, das Vorhandensein des Referenzverzeichnisses, die Referenzstruktur und die Übereinstimmung der Anzahlen prüfen. Stelle eingegrenzte Prüfungen für eine einzelne Fähigkeit oder eine Prüffamilie sowie maschinenlesbare Ausgaben für CI bereit. Führe einen Markdown-Prüfer getrennt aus. Prüfe auf HTML-Kommentare, die Tabellen beschädigen, nicht geschlossene Codeblöcke, fehlende Trennzeilen in Tabellen und uneinheitliche Spaltenanzahlen. Prüfe nach der gezielten Untersuchung das gesamte Projektarchiv. Behandle Beendigungscode 0 als Erfolg und Beendigungscode 1 als fehlgeschlagene Prüfung und begutachte Warnungen ausdrücklich. Veröffentliche niemals eine Version mit ungelösten Prüffehlern, nur weil eine enger begrenzte Prüfung bestanden wurde. ## Befehle und Ergebnisse festhalten, bevor die Veröffentlichung als bereit gemeldet wird Suche nach der Synchronisierung und Prüfung nach veralteten Versionsverweisen und nimm bewusst beibehaltene Verläufe des Änderungsprotokolls aus. Bestätige von Hand, dass Beschreibungen, Auslöseprüfungen, Weiterleitungstabellen, Verweise auf zugehörige Fähigkeiten, kanonische Rückverweise, erzeugte Anzahlen und bedingte Inhalte mit der Veröffentlichung übereinstimmen. Bewahre Namensnennungen Dritter, Lizenzhinweise und Forschungsreferenzen, wenn Verhaltensmuster oder Verfahrensdisziplin aus anderen Arbeiten übernommen wurden. Verliere beim Aufräumen keine Herkunftsnachweise. Halte die genauen Aktualisierungs- und Prüfbefehle, ihre Ergebnisse, begutachtete Warnungen und jeden absichtlich ausgelassenen bedingten Schritt fest. Melde die Veröffentlichungsbereitschaft erst, nachdem alle erforderlichen Prüfer erfolgreich waren und die abschließenden Unterschiede keine unerklärten Änderungen enthalten.