Lokale Skill-Dateiverwaltung

Was macht Lokale Skill-Dateiverwaltung?

Zweck

Verwalten Sie die persönlichen lokalen Skill-Dateien des Benutzers als leichtgewichtiges, selbstverbesserndes Gedächtnissystem. Das Standardziel ist nicht die Erstellung von marktreifen generischen Skills; es geht darum, wiederverwendbares Verhalten zu bewahren, das diesem Benutzer, diesem Team oder diesem Arbeitsbereich in zukünftigen Sitzungen hilft. Ein guter Kandidat kann persönliche Arbeitsablaufpräferenzen, Projektkonventionen, Stilverträge, Tool-Auswahlen oder Überprüfungsgates kodieren, die für andere Benutzer nicht nützlich wären, solange sie für den vorgesehenen Eigentümer wiederverwendbar und genehmigt sind.

Dieser Skill ist nicht von projektspezifischem Code, Servern, Vektor-Datenbanken oder Speicherlayouts abhängig. Er arbeitet nur mit gewöhnlichen lokalen Skill-Ordnern:

<skill-root>/
  <skill-name>/
    SKILL.md
    agents/openai.yaml   (optional)
    scripts/             (optional)
    references/          (optional)
    assets/              (optional)

Verwenden Sie diesen Skill, um zu entscheiden, wann eine Sitzung wiederverwendbares Skill-Material enthält, ob ein ähnlicher Skill bereits existiert, und dann einen lokalen Skill zu verwerfen, zu verbessern, zusammenzuführen oder zu erstellen. Das Modell sollte diese Prüfung initiieren, wenn Signale auftreten; es sollte nicht warten, bis der Benutzer danach fragt. Die Prüfung muss leichtgewichtig und nicht blockierend bleiben, es sei denn, der Benutzer bittet explizit darum, sich auf die Skill-Wartung zu konzentrieren.

Koordination mit verwandten Skills

Dieser Skill besitzt den Lebenszyklus-Entscheid: wann extrahiert werden soll, ob verworfen werden soll, ob verbessert oder zusammengeführt werden soll und wohin geschrieben werden soll. Koordinieren Sie sich mit nahegelegenen Skills, wenn diese installiert sind:

• Verwenden Sie skill-creator für neue Skill-Struktur, -Benennung, -Ressourcenplatzierung, agents/openai.yaml und -Validierung.
• Verwenden Sie skill-improvement oder eine gleichwertige Verbesserungsanleitung für die Iteration bestehender Skills, Test-Prompts, Fehleranalyse, Trigger-Beschreibungsanpassung und Vorher/Nachher-Vergleich.
• Verwenden Sie skill-finder, find-skills oder gleichwertige Entdeckungswerkzeuge, um lokale oder externe Skill-Ökosysteme zu durchsuchen, bevor Sie ein Duplikat erstellen.
• Übernehmen Sie Selbstverbesserungsmuster nur als Entscheidungsheuristiken: Ereignis-Triage, Deduplizierung, Wiederholung, Priorität, Wertprüfungen und Förderungsgates. Übernehmen Sie keine Speicherpfade, Daemon-Annahmen oder Codestruktur eines anderen Skills, es sei denn, der Benutzer fordert dies an.
• Wenn diese Hilfsskills nicht verfügbar sind, wenden Sie die unten aufgeführten integrierten Verfahren an. Blockieren Sie nicht das Fehlen von Hilfsskills.
• Lassen Sie nicht zu, dass Hilfsskills die Extraktionsgrenze schwächen: Es sollten nur wiederverwendbare, benutzerbelegte Fähigkeitsänderungen gespeichert werden.

Sicherheit und Zustimmung

Lokale Skills können das zukünftige Agentenverhalten beeinflussen und ausführbare Skripte enthalten. Behandeln Sie Skill-Bearbeitungen als dauerhafte Verhaltensänderungen.

• Installieren, importieren oder aktivieren Sie keine Drittanbieter-Skills ohne Benutzerzustimmung.
• Fügen Sie keine überraschenden Fähigkeiten, versteckten Netzwerkzugriff, Anmeldedatenverarbeitung, Datenexfiltration oder destruktive Befehle hinzu.
• Wenn ein Skill Skripte oder Tool-Integrationen hinzufügt, machen Sie deren Zweck in SKILL.md sichtbar.
• Bewahren Sie bei der Bearbeitung eines Skills, der möglicherweise mit einem Team geteilt wird, die Organisationsrichtlinien und fragen Sie, bevor Sie sicherheitsrelevantes Verhalten ändern.
• Behandeln Sie jeden Kandidaten standardmäßig als persönlich; markieren Sie ihn nur als team oder öffentlich, wenn die Beweise dieses breitere Publikum unterstützen.
• Veröffentlichen Sie keinen benutzerspezifischen Skill, empfehlen Sie ihn nicht als breit wiederverwendbar oder entfernen Sie den persönlichen Umfang ohne explizite Benutzerfreigabe.
• Teilen Sie dem Benutzer vor der ersten persistenten Lernnotiz oder dem ersten Skill-Schreiben in einer neuen lokalen Konvention mit, welcher Pfad geschrieben würde, und bitten Sie um Freigabe.
• Ändern Sie diesen autoskill-Manager selbst während der routinemäßigen Wartung nicht stillschweigend. Verbessern Sie ihn nur, wenn der Benutzer explizit darum bittet, diesen Skill zu verbessern.

Skill-Wurzeln

Identifizieren Sie vor dem Schreiben, wo lokale Skills leben.

• Verwenden Sie zuerst einen expliziten, vom Benutzer bereitgestellten Pfad.
• Andernfalls überprüfen Sie gängige Wurzeln wie ${CODEX_HOME}/skills, ~/.codex/skills, ./skills, .agents/skills und jedes aktuelle Arbeitsbereichs-Skill-Verzeichnis, das */SKILL.md enthält.
• Wenn genau eine plausible Wurzel existiert, verwenden Sie diese.
• Wenn mehrere plausible Wurzeln existieren und das Ziel mehrdeutig ist, fragen Sie den Benutzer, welche Wurzel verwaltet werden soll.
• Reorganisieren Sie niemals nicht verwandte Skill-Wurzeln oder bearbeiten Sie Skills außerhalb der gewählten Wurzel.

Trigger-Richtlinie

Verwenden Sie eine dreistufige Trigger-Richtlinie:

1. Stiller Scan: Fragen Sie nach jeder inhaltlichen Benutzereingabe kurz, ob die Eingabe eine wiederverwendbare persönliche Präferenz, Regel, Korrektur, einen Arbeitsablauf, einen Fehler oder ein Skill-Qualitätsproblem enthält.
2. Extraktionsprüfung: Wenn einer der folgenden Trigger ausgelöst wird, klassifizieren Sie die Erfahrung, weisen Sie Beweise und Wert zu, suchen Sie nach ähnlichen Skills und testen Sie sie gegen die Extraktionsgrenze.
3. Schreiben/Aktualisieren: Bearbeiten Sie lokale Skill-Dateien nur, nachdem der Kandidat die Grenze passiert hat, die Ziel-Skill-Wurzel klar ist und der Benutzer die genaue Änderung genehmigt hat.

Das Modell sollte Scans und Extraktionsprüfungen proaktiv initiieren. Fragen Sie den Benutzer nicht „Soll ich nach einem Skill suchen?“. Fragen Sie nur, wenn die Zielwurzel mehrdeutig ist, die Bearbeitung unsicheres Verhalten überschreiben würde oder der Benutzer eine externe Installation oder ein sensitives Skript genehmigen muss.

Kandidaten-Lebenszyklus

Halten Sie den Lebenszyklus von jedem bestimmten Speichersystem getrennt: Beobachten Sie ein Signal, bitten Sie den Benutzer optional, einen Kandidatentitel/ein Thema zu wählen, entwerfen Sie den Kandidaten, deduplizieren Sie nach Muster, entscheiden Sie verwerfen/notiz_behalten/verbessern/zusammenführen/erstellen, zeigen Sie den vollständigen vorgeschlagenen Skill oder Diff an, wenden Sie dann die kleinste genehmigte Änderung an und validieren Sie.

Deduplizieren Sie nach Aufgabenfamilie, Trigger, Tools, Fehlermodus, Ausgabevertrag und Ziel-Skill, nicht nach genauer Formulierung. Erstellen Sie keine private Datenbank, keinen Daemon, keinen Zeitplaner oder versteckten Hintergrundspeicher als Teil dieses Skills.

Titelauswahl-Gate

Vor der vollständigen Extraktion, wenn das wiederverwendbare Thema mehrdeutig ist oder mehrere plausible Skills vorhanden sind, zeigen Sie 2-5 prägnante Titel für wiederverwendbare Fähigkeiten mit einzeiligen Beweisgründen sowie keiner davon und benutzerdefiniertes Thema an. Wenn der Benutzer einen Titel wählt oder ein Thema eingibt, behandeln Sie dies nur als Richtung: Führen Sie die Extraktionsgrenze und die Suche nach ähnlichen Skills für diese Richtung erneut aus, verwerfen Sie sie, wenn sie fehlschlägt, oder zeigen Sie den vollständigen vorgeschlagenen SKILL.md/Diff zur endgültigen Freigabe an, wenn er erfolgreich ist. Wenn der Benutzer keiner davon wählt, verwerfen Sie es oder behalten Sie eine nicht-persistente Notiz; schreiben Sie keine Dateien.

Sprachkonsistenz

Für neue Skills schreiben Sie Kandidatentitel, vorgeschlagene SKILL.md, agents/openai.yaml und kleine Ressourcen in der dominanten Sprache der Benutzerbeweise; chinesische Eingabe erzeugt chinesische Skills, englische Eingabe erzeugt englische Skills. Für Aktualisierungen oder Zusammenführungen behalten Sie die dominante Sprache des Ziel-Skills bei, es sei denn, der Benutzer bittet explizit um eine Übersetzung; wenn gemischte Beweise die Sprache mehrdeutig machen, fragen Sie vor dem Entwurf. Standardisieren Sie extrahierte Skill-Inhalte nicht standardmäßig auf Englisch.

Hintergrundausführung

Skill-Extraktion und -Wartung dürfen die Hauptaufgabe des Benutzers nicht blockieren.

• Behandeln Sie Extraktionsprüfungen, Suche nach ähnlichen Skills, Kandidatenentwurf und Trigger-Evaluierungsvorbereitung wann immer möglich als Hintergrundwartungsarbeit.
• Hintergrundarbeit kann Kandidaten vorbereiten, ähnliche Skills finden und Diffs entwerfen, darf aber keine Skills ohne Benutzerbestätigung schreiben, aktualisieren, löschen, installieren oder aktivieren.
• Fahren Sie zuerst mit der primären Benutzeranfrage fort; lassen Sie den Benutzer nicht auf die Skill-Extraktion warten, es sei denn, der Benutzer hat explizit darum gebeten, sich auf die Skill-Wartung zu konzentrieren.
• Zeigen Sie Hintergrundergebnisse nur an, wenn es eine umsetzbare Kandidatenentscheidung, einen vorgeschlagenen Datei-Diff oder eine Klärungs-/Zustimmungsfrage gibt.
• Führen Sie höchstens einen Hintergrund-Skill-Wartungsjob pro aktiver Konversation aus, es sei denn, der Benutzer bittet um einen Batch; stellen Sie zusätzliche Signale in die Warteschlange oder fassen Sie sie zusammen.
• Starten Sie keine teuren Suchvorgänge, breiten Evaluierungen oder großen Umschreibungen im Vordergrund. Verwenden Sie zuerst leichtgewichtige Prüfungen und verschieben Sie eine tiefere Validierung auf eine natürliche Pause oder einen expliziten Wartungsdurchgang.
• Wenn die Laufzeitumgebung keine Hintergrundarbeit ausführen kann, emulieren Sie diese, indem Sie die Wartungsprüfung verschieben, bis die aktuelle Antwort abgeschlossen ist oder die nächste natürliche Pause eintritt.
• Blockieren Sie niemals die Auslieferung der vom Benutzer angeforderten Arbeit, nur um die Kandidatenextraktion abzuschließen, es sei denn, die angeforderte Arbeit ist die Skill-Wartung selbst.

Bestätigungs-Gate

Eine Benutzerbestätigung ist erforderlich, bevor eine Skill-Datei erstellt, aktualisiert, gelöscht, importiert, installiert, aktiviert oder wesentlich umgeschrieben wird. Entwerfen Sie zuerst, fragen Sie danach: Stellen Sie nach jeder Titel-/Themenauswahl niemals „Soll ich einen Skill hinzufügen/aktualisieren?“, bis der vorgeschlagene Inhalt oder die Änderung bereits zur Überprüfung ausgeschrieben ist.

Für erstellen zeigen Sie vor dem Schreiben:

• vorgeschlagener Skill-Name und Zielpfad
• beabsichtigte Zielgruppe: persönlich, team oder öffentlich, plus Portabilitätsgrenzen
• warum der Kandidat die Grenze des wiederverwendbaren Skills bestanden hat
• Beweisebene, Wiederholungssignal, Priorität und Wertsignal
• überprüfte ähnliche Skills und warum dies kein Duplikat ist
• vollständiger vorgeschlagener SKILL.md-Inhalt
• vollständiges vorgeschlagenes agents/openai.yaml und jeder vorgeschlagene Skript-, Referenz- oder Asset-Text, wenn solche Dateien klein genug sind, um inline überprüft zu werden; für große Assets zeigen Sie die genaue Dateiliste, den Zweck, die Herkunft und den generierten Diff oder das Manifest

Für verbessern oder zusammenführen zeigen Sie vor dem Schreiben:

• genauen Ziel-Skill-Pfad
• Entscheidungstyp: verbessern oder zusammenführen
• warum die Änderung in diesen bestehenden Skill gehört
• Beweisebene, Wiederholungssignal, Priorität und Wertsignal
• einen vollständigen Unified Diff oder vollständigen Vorher/Nachher-Text für jeden geänderten Abschnitt, wenn kein Unified Diff verfügbar ist
• jede Datei, die hinzugefügt, geändert, gelöscht oder unberührt gelassen würde
• Validierungsplan oder Befehl, der nach der Freigabe ausgeführt werden soll

Bitten Sie um eine eindeutige Ja/Nein-Freigabe, erst nachdem Sie das vollständige vorgeschlagene Artefakt oder den Diff gezeigt haben. Wenn der Benutzer nicht zustimmt, bearbeiten Sie den Skill nicht; melden Sie den Kandidaten als zurückgestellt oder verworfen.

Sofortige Auslöser

Führen Sie eine Extraktionsprüfung sofort oder bei der nächsten natürlichen Pause durch, wenn der Benutzer auf die Hauptaufgabe wartet, wenn eines dieser Ereignisse eintritt:

• Der Benutzer korrigiert, lehnt ab oder verfeinert den Ansatz des Modells auf eine Weise, die zukünftige ähnliche Aufgaben beeinflussen sollte.
• Der Benutzer gibt eine dauerhafte Präferenz, einen Ausgabevertrag, einen Arbeitsablauf, eine Namensregel, eine Tool-Regel oder ein Qualitätsgate an.
• Ein Befehl, Skript, eine Integration oder ein Arbeitsablauf schlägt fehl und die Sitzung entdeckt eine wiederverwendbare Lösung.
• Der Agent wiederholt nicht-triviale Einrichtungs-, Skript-, Transformations- oder Validierungsarbeit, die zu einer wiederverwendbaren Ressource werden sollte.
• Ein ähnlicher lokaler Skill wurde zu wenig, zu viel ausgelöst oder lieferte unvollständige Anleitungen.
• Die Sitzung offenbart eine fehlende Referenz, Vorlage, ein fehlendes Skript oder eine fehlende Checkliste, die zukünftige wiederholte Arbeit verhindern würde.
• Der Benutzer verwendet zukunftsorientierte Sprache wie „merke dir das als Skill“, „speichere diesen Arbeitsablauf“, „aktualisiere den lokalen Skill“, „mach es nächstes Mal so“, „das ist mein Standardprozess“ oder „erstelle einen Skill aus dieser Konversation“.

Behandeln Sie die Extraktion dennoch als Prüfung, nicht als Anforderung: Oft ist keine Skill-Änderung das richtige Ergebnis.

Extrahieren Sie nicht, wenn der Benutzer sagt, die Regel sei vorübergehend, bittet, sie sich nicht zu merken, oder nur eine einmalige Antwort wünscht.

Geplante Prüfungen

Verwenden Sie geplante Prüfungen, um inkrementelles Lernen zu erfassen, das keine einzelne Eingabe offensichtlich macht:

• Konversationslängenprüfung: nach etwa 6 inhaltlichen Benutzernachrichten, 12 gesamten Wendungen oder 2-3 verschiedenen Aufgabenversuchen seit der letzten Prüfung.
• Token-/Volumenprüfung: nach einem langen Stück neuen Kontexts, besonders wenn die Konversation bald zusammengefasst oder komprimiert werden könnte.
• Aufgabenübergangsprüfung: wenn ein Arbeitsergebnis abgeschlossen ist, eine Debugging-Schleife endet, ein Plan angenommen wird oder der Benutzer zu einer neuen Aufgabe wechselt.
• Sitzungsendeprüfung: vor der letzten Antwort einer substanziellen Sitzung prüfen, ob etwas verworfen, verbessert, zusammengeführt, erstellt oder notiert werden sollte.

Halten Sie geplante Prüfungen leichtgewichtig. Sie sollten normalerweise stillschweigend ablaufen und dem Benutzer nur angezeigt werden, wenn eine umsetzbare Entscheidung oder eine erforderliche Klärung vorliegt.

Entprellung und Bündelung

Verhindern Sie laute wiederholte Extraktion:

• Prüfen Sie dasselbe Signal nicht wiederholt in einer Sitzung.
• Bündeln Sie mehrere schwache Signale bis zu einer Aufgabenübergangs- oder geplanten Prüfung.
• Erstellen oder aktualisieren Sie höchstens einen Skill pro Prüfung, es sei denn, der Benutzer bittet explizit um einen Batch.
• Bevorzugen Sie notiz_behalten oder verwerfen für grenzwertige Signale, bis Wiederholung die Beweise stärkt.
• Wenn ein Kandidat nahe, aber noch nicht wiederverwendbar genug ist, merken Sie sich die Begründung in der Abschlussnotiz, anstatt einen Skill zu erstellen.
• Fassen Sie gleichzeitige Trigger in einem Hintergrundwartungsdurchlauf zusammen.
• Wenn mehrere Kandidaten konkurrieren, bearbeiten Sie zuerst den Fehler mit der höchsten Priorität wiederholt oder die vom Benutzer bestätigte Präferenz.

Erfahrungs-Triage

Klassifizieren Sie vor dem Ändern von Skills die Sitzungserfahrung. Dauerhafte Kategorien sind fehler, korrektur, beste_praxis, wissenslücke und präferenz. einmaliges_ergebnis bedeutet, dass die Sitzung nützliche Arbeit produzierte, aber keine dauerhafte Prozessänderung.

Nur dauerhafte Kategorien können zu Skill-Änderungen werden, und nur nach Bestehen der Extraktionsgrenze. Einmalige Ergebnisse sollten nicht befördert werden.

Wert- und Prioritäts-Gate

• Priorität P0: verhindert unsicheres, destruktives, datenschutzsensitives oder wiederholt fehlschlagendes Verhalten.
• Priorität P1: verhindert einen signifikanten wiederkehrenden Fehler, verpassten Trigger, schlechte Zusammenführung oder teuren wiederholten Arbeitsablauf.
• Priorität P2: verbessert Qualität, Geschwindigkeit oder Klarheit für eine wiederkehrende Aufgabenfamilie.
• Priorität P3: Komfort- oder Stilverbesserung mit begrenzten Beweisen.

Befördern Sie nach dauerhaftem Wert, nicht nach Neuheit. Der Wert muss als Zuverlässigkeit, Sicherheit, Geschwindigkeit, Qualität, Konsistenz oder reduzierte wiederholte Arbeit erklärbar sein. Wenn keine Wertebene klar ist, verwerfen Sie es oder behalten Sie eine nicht-persistente Notiz.

Ändern Sie jeweils einen Verhaltenshebel, wenn Sie einen bestehenden Skill verbessern: Trigger-Formulierung, Arbeitsschritt, Validierungsgate, Ressourcenplatzierung oder Sicherheitseinschränkung.

Beförderungsregeln

Machen Sie nicht jede Erfahrung zu einer Skill-Bearbeitung. Befördern Sie Erfahrungen bewusst:

• Befördern Sie sofort, wenn der Benutzer explizit sagt, dass die Regel nächstes Mal gelten soll.
• Befördern Sie sofort, wenn eine Korrektur einen ernsthaften wiederholten Fehler, eine unsichere Aktion oder einen destruktiven Arbeitsablauf verhindert.
• Befördern Sie nach Wiederholung, wenn derselbe Fehler, dieselbe Korrektur oder dieselbe beste Praxis bei mehreren ähnlichen Aufgaben auftritt.

(abgeschnitten...)