Eine Fähigkeitssammlung aufbauen und pflegen, die mit jeder KI funktioniert

## Ordner so anlegen, dass Details einer Fähigkeit erst bei Gebrauch geladen werden Geben Sie jeder Fähigkeit ein eigenes Verzeichnis mit einer primären Anweisungsdatei, den erforderlichen Metadaten sowie optionalen Referenz- und Skriptverzeichnissen. Bewahren Sie vollständige Beispiele, Forschungsmaterial, maßgebliche Vorlagen und sammlungsweite Dokumentation an klar getrennten Stellen auf. Pflegen Sie im Stammverzeichnis eine Fähigkeitsübersicht, damit Nutzer oder Agenten die Sammlung erkunden können, ohne jeden Fähigkeitstext zu laden. Behandeln Sie Namen und Beschreibungen als Startindex. Laden Sie ausführliche Anweisungen, Referenzen und Skripte erst, wenn eine Fähigkeit aktiviert wird. Diese Struktur hält die Aufmerksamkeit bei der aktuellen Aufgabe und stellt tiefergehendes Material bei Bedarf weiterhin bereit. ## Die Hauptdatei jeder Fähigkeit kurz und mit jedem Werkzeug nutzbar halten Halten Sie die primäre Anweisungsdatei einer Fähigkeit unter 500 Zeilen und verlagern Sie ausführliches Material in Referenzen. Verlangen Sie YAML-Metadaten mit einem Namen und einer Beschreibung in der dritten Person, verwenden Sie kleingeschriebene, durch Bindestriche getrennte Verzeichnisnamen und prüfen Sie jeden Absatz auf seinen Informationswert. Setzen Sie ein fortgeschrittenes Publikum voraus, sofern die Fähigkeit nicht ausdrücklich Grundlagen vermittelt. Verfassen Sie plattformunabhängige Anleitungen. Abstrahieren Sie herstellerspezifische Werkzeuge, sofern eine Plattformvorgabe nicht unverzichtbar ist, und gestalten Sie Beispiele portabel, statt konzeptionellen Pseudocode als produktionsreifen Code darzustellen. ## Aufschreiben, wann eine Fähigkeit genutzt wird und wann nicht Nehmen Sie Abschnitte zu Aktivierungsbedingungen, Kernkonzepten, praktischen Hinweisen, Beispielen, Richtlinien, Stolpersteinen, Einbindung und Referenzen auf. Jeder Aktivierungsabschnitt muss positive Auslöser und eine Ausschlussgrenze nennen, die angrenzende Aufgaben an die richtige Fähigkeit weiterleitet. Gewichten Sie erfahrungsbasierte Stolpersteine besonders stark, weil sie Fehlermuster festhalten, die allgemeine Anleitungen häufig übersehen. Verweisen Sie in Hinweisen zur Einbindung mit stabilen Namen im Klartext auf andere Fähigkeiten, wenn Verknüpfungen bei abweichenden Installationsstrukturen ungültig würden. ## Bei jeder Änderung die Listen und die Quellen der Zahlen mit anpassen Aktualisieren Sie beim Hinzufügen oder Ändern einer Fähigkeit gleichzeitig die Sammlungsübersicht, die Verteilungsmanifeste und den Korpusindex. Ordnen Sie die Fähigkeit ihren Aktivierungsszenarien, wiederverwendbaren Verhaltensmechanismen und stützenden Aussagen zu, damit Auffindbarkeit, Paketierung und Bewertung dasselbe Artefakt beschreiben. Dokumentieren Sie die Herkunft numerischer, benchmarkbezogener, veränderlicher oder herstellerleistungsbezogener Aussagen. Aktualisieren Sie Mechanismen- und Aussagenregister, sobald eine Fähigkeit eine wiederverwendbare Verhaltensänderung oder eine beweissensible Behauptung einführt; lassen Sie diese Beziehungen nicht nur implizit im Fließtext stehen. ## Automatische Prüfungen laufen lassen, bevor eine KI urteilt Führen Sie vor der Annahme einer Änderung die im Repository festgelegten Prüfungen für Metadatenanalyse, strenge Schema- und Korpusstruktur, plattformverträgliche Installationsstrukturen, Integrität des Fähigkeitstexts, Aktivierungsgrenzen und adversariale Vergleichstests aus. Behandeln Sie sie als Begutachtungsbedingungen und nicht als optionale Diagnosen. Prüfen Sie zuerst Struktur, Manifestsynchronisierung, Berechnung des Bewertungsrasters, Abrufzustand und Registerform deterministisch. Verwenden Sie modellgestützte Urteile erst nach Bestehen dieser Prüfungen und nutzen Sie kein Modell, um einen reproduzierbaren Strukturfehler zu entschuldigen. ## Für jedes Beispielprojekt dessen eigene Setup- und Testbefehle nutzen Erfinden Sie kein übergeordnetes Erstellungssystem, wenn das Repository keines besitzt. Ermitteln Sie die von jedem Beispiel oder Teilprojekt deklarierte Laufzeitumgebung und Paketverwaltung und verwenden Sie anschließend dessen eigene Einrichtungs-, Erstellungs-, Test-, Codeprüfungs-, Formatierungs- und Typprüfungsbefehle. Begrenzen Sie Umgebungen und Abhängigkeiten auf das jeweilige Teilprojekt. Führen Sie während der schrittweisen Bearbeitung den kleinsten einschlägigen Befehl aus und schließen Sie vor der Begutachtung den dokumentierten Prüfungssatz des Teilprojekts ab. Unterscheiden Sie Kompilierung, Komponententests, asynchrone Tests, Codeprüfung, Formatierung und statische Typprüfung, statt einen erfolgreichen Befehl als Beleg für das Bestehen aller Prüfungen zu behandeln. ## Jeden Forschungslauf mit dem vorgesehenen Werkzeug in festen Stufen voranbringen Initialisieren Sie jeden Forschungslauf mit dem bereitgestellten Lebenszykluswerkzeug, damit Zustandsdatei, Warteschlangeneintrag, Protokoll des Arbeitsstrangs, Gerüst zur Quellenbewertung und Vorlage für Mechanismusvorschläge einheitlich angelegt werden. Durchlaufen Sie Abruf, Bewertung, Vorschlag, Neuheitsprüfung, Laufvalidierung, Begutachtungsbereitschaft und Abschluss ausschließlich über unterstützte Übergänge; bearbeiten Sie den Laufzustand niemals von Hand. Validieren Sie aktive Läufe unabhängig von repositoryweiten Prüfungen. Übernehmen Sie einen vorgeschlagenen Mechanismus erst, wenn der Lauf bereit ist, die erforderliche begutachtende Person erfasst wurde und die Bereitschaftsprüfung bestanden ist. Ergänzen Sie Herkunftsnachweise, bevor eine numerische, benchmarkbezogene oder veränderliche Aussage in eine Fähigkeit gelangt. ## Bei automatischer Forschung keine bezahlte KI nutzen, bis ein Budget feststeht Stellen Sie deterministische Befehle für Ermittlung, Fortschritt um einen Schritt, tägliche Verarbeitung und Zustandsberichte bereit, unabhängig davon, ob die Schleife manuell oder durch einen plattformspezifischen Zeitplaner gestartet wird. Halten Sie den Abruf ohne kostenpflichtige Modellaufrufe nutzbar und rufen Sie in unbeaufsichtigten Schleifen keine kostenpflichtigen Modelle auf, solange keine ausdrückliche Budgetprüfung besteht. Behandeln Sie Warteschlangen, Laufzeitprotokolle, Momentaufnahmen, Zustandsberichte, zurückgestellte Begutachtungen, Ereignisströme, Fehler und gewöhnliche Laufverzeichnisse als Betriebszustand und nicht als Quellmaterial. Übernehmen Sie sie niemals in die Versionsverwaltung, außer bei einem bewusst dafür vorgesehenen Ausgangslauf. ## Verwandte Fähigkeiten als ein Paket verteilen statt als Kopien Wenn eine Laufzeitumgebung jede Erweiterungsquelle getrennt zwischenspeichert, verteilen Sie eine zusammengehörige Fähigkeitssammlung in einem einzigen Paket, statt mehrere Pakete auf denselben Quellbaum zu verweisen. Dadurch werden doppelte Zwischenspeicher vermieden, während eine einheitliche Versions- und Manifestgrenze erhalten bleibt. Stellen Sie beim Start nur die zur Auffindbarkeit nötigen Metadaten bereit. Laden Sie vollständige Fähigkeitstexte und unterstützende Ressourcen erst nach der Aktivierung, damit der Umfang des Pakets nicht zu einer dauerhaften Kontextbelastung wird. ## Der KI weniger Material geben und vor dem Übertragen von Änderungen ins gemeinsame Repository (Push) die Zustimmung eines Menschen einholen Bevorzugen Sie Kontextqualität gegenüber Kontextmenge: Begrenzte Aufmerksamkeit und Informationsverlust in mittleren Positionen bedeuten, dass mehr Material die Leistung verringern kann. Verwenden Sie Unteragenten, um die Aufmerksamkeit für klar begrenzte Arbeit zu isolieren, und nicht bloß, um Organisationsrollen nachzuahmen. Halten Sie konzeptionelle Beispiele portabel, etwa durch sprachneutralen oder allgemein verständlichen Pseudocode. Lassen Sie deterministische Belege einem Modellurteil vorausgehen und behalten Sie Veröffentlichungen in entfernten Systemen unter menschlicher Kontrolle. Agenten dürfen Änderungen vorbereiten und alle lokalen Prüfungen bestehen, müssen jedoch vor dem Übertragen oder Zusammenführen eine ausdrückliche menschliche Genehmigung einholen.