Selbstverbesserungs-Skill

Was macht Selbstverbesserungs-Skill?

Protokolliere Erkenntnisse und Fehler in Markdown-Dateien für kontinuierliche Verbesserung. Coding-Agenten können diese später in Korrekturen umsetzen, und wichtige Erkenntnisse werden in das Projektgedächtnis übernommen.

Kurzübersicht

Situation	Aktion
Befehl/Operation schlägt fehl	In .learnings/ERRORS.md protokollieren
Benutzer korrigiert dich	In .learnings/LEARNINGS.md mit Kategorie correction protokollieren
Benutzer wünscht fehlende Funktion	In .learnings/FEATURE_REQUESTS.md protokollieren
API/externes Tool schlägt fehl	In .learnings/ERRORS.md mit Integrationsdetails protokollieren
Wissen war veraltet	In .learnings/LEARNINGS.md mit Kategorie knowledge_gap protokollieren
Besserer Ansatz gefunden	In .learnings/LEARNINGS.md mit Kategorie best_practice protokollieren
Ähnlich zu vorhandenem Eintrag	Mit Siehe auch verlinken, Prioritätserhöhung erwägen
Allgemein anwendbare Erkenntnis	In CLAUDE.md, AGENTS.md und/oder .github/copilot-instructions.md übernehmen
Workflow-Verbesserungen	In AGENTS.md übernehmen (OpenClaw-Arbeitsbereich)
Tool-Tücken	In TOOLS.md übernehmen (OpenClaw-Arbeitsbereich)
Verhaltensmuster	In SOUL.md übernehmen (OpenClaw-Arbeitsbereich)

OpenClaw Einrichtung (Empfohlen)

OpenClaw ist die primäre Plattform für diesen Skill. Es verwendet eine Arbeitsbereichs-basierte Prompt-Injektion mit automatischem Skill-Laden.

Installation

Über ClawdHub (empfohlen):

clawdhub install self-improving-agent

Manuell:

git clone https://github.com/peterskoett/self-improving-agent.git ~/.openclaw/skills/self-improving-agent

Arbeitsbereichsstruktur

OpenClaw injiziert diese Dateien in jede Sitzung:

~/.openclaw/workspace/
├── AGENTS.md          # Multi-Agenten-Workflows, Delegationsmuster
├── SOUL.md            # Verhaltensrichtlinien, Persönlichkeit, Prinzipien
├── TOOLS.md           # Tool-Funktionen, Integrations-Tücken
├── MEMORY.md          # Langzeitgedächtnis (nur Hauptsitzung)
├── memory/            # Tägliche Gedächtnisdateien
│   └── YYYY-MM-DD.md
└── .learnings/        # Protokolldateien dieses Skills
    ├── LEARNINGS.md
    ├── ERRORS.md
    └── FEATURE_REQUESTS.md

Lerndateien erstellen

mkdir -p ~/.openclaw/workspace/.learnings

Dann die Protokolldateien erstellen (oder aus assets/ kopieren):

• LEARNINGS.md — Korrekturen, Wissenslücken, Best Practices
• ERRORS.md — Befehlsfehler, Ausnahmen
• FEATURE_REQUESTS.md — vom Benutzer angeforderte Funktionen

Übernahmeziele

Wenn sich Erkenntnisse als allgemein anwendbar erweisen, übernehme sie in die Arbeitsbereichsdateien:

Lerntyp	Übernehmen in	Beispiel
Verhaltensmuster	SOUL.md	„Sei präzise, vermeide Haftungsausschlüsse“
Workflow-Verbesserungen	AGENTS.md	„Erzeuge Unter-Agenten für lange Aufgaben“
Tool-Tücken	TOOLS.md	„Git-Push benötigt zuerst konfigurierte Authentifizierung“

Sitzungsübergreifende Kommunikation

OpenClaw bietet Tools, um Erkenntnisse sitzungsübergreifend zu teilen:

• sessions_list — Aktuelle/laufende Sitzungen anzeigen
• sessions_history — Transkript einer anderen Sitzung lesen
• sessions_send — Eine Erkenntnis an eine andere Sitzung senden
• sessions_spawn — Einen Unter-Agenten für Hintergrundarbeit erzeugen

Optional: Hook aktivieren

Für automatische Erinnerungen beim Sitzungsstart:

# Hook in das OpenClaw-Hooks-Verzeichnis kopieren
cp -r hooks/openclaw ~/.openclaw/hooks/self-improvement

# Aktivieren
openclaw hooks enable self-improvement

Siehe references/openclaw-integration.md für vollständige Details.

---

Generische Einrichtung (Andere Agenten)

Für Claude Code, Codex, Copilot oder andere Agenten, erstelle .learnings/ in deinem Projekt:

mkdir -p .learnings

Kopiere Vorlagen aus assets/ oder erstelle Dateien mit Kopfzeilen.

Protokollformat

Lerneintrag

Anhängen an .learnings/LEARNINGS.md:

## [LRN-YYYYMMDD-XXX] Kategorie

**Protokolliert**: ISO-8601 Zeitstempel
**Priorität**: niedrig | mittel | hoch | kritisch
**Status**: ausstehend
**Bereich**: frontend | backend | infra | tests | docs | config

### Zusammenfassung
Einzeilige Beschreibung dessen, was gelernt wurde

### Details
Vollständiger Kontext: was passiert ist, was falsch war, was richtig ist

### Vorgeschlagene Aktion
Spezifische Korrektur oder Verbesserung

### Metadaten
- Quelle: gespräch | fehler | benutzerfeedback
- Zugehörige Dateien: pfad/zu/datei.ext
- Tags: tag1, tag2
- Siehe auch: LRN-20250110-001 (falls zu vorhandenem Eintrag zugehörig)

---

Fehlereintrag

Anhängen an .learnings/ERRORS.md:

## [ERR-YYYYMMDD-XXX] skill_oder_befehlsname

**Protokolliert**: ISO-8601 Zeitstempel
**Priorität**: hoch
**Status**: ausstehend
**Bereich**: frontend | backend | infra | tests | docs | config

### Zusammenfassung
Kurze Beschreibung, was fehlgeschlagen ist

### Fehler

Tatsächliche Fehlermeldung oder Ausgabe

### Kontext
- Verwendeter Befehl/Vorgang
- Eingaben oder verwendete Parameter
- Umgebungsdetails, falls relevant

### Vorgeschlagener Fix
Falls identifizierbar, was das Problem beheben könnte

### Metadaten
- Reproduzierbar: ja | nein | unbekannt
- Zugehörige Dateien: pfad/zu/datei.ext
- Siehe auch: ERR-20250110-001 (falls wiederkehrend)

---

Funktionsanfrage-Eintrag

Anhängen an .learnings/FEATURE_REQUESTS.md:

## [FEAT-YYYYMMDD-XXX] funktionsname

**Protokolliert**: ISO-8601 Zeitstempel
**Priorität**: mittel
**Status**: ausstehend
**Bereich**: frontend | backend | infra | tests | docs | config

### Angeforderte Funktion
Was der Benutzer tun wollte

### Benutzerkontext
Warum er es brauchte, welches Problem er löst

### Komplexitätseinschätzung
einfach | mittel | komplex

### Vorgeschlagene Implementierung
Wie dies gebaut werden könnte, was es erweitern würde

### Metadaten
- Häufigkeit: erstmalig | wiederkehrend
- Verwandte Funktionen: vorhandener_funktionsname

---

ID-Generierung

Format: TYP-YYYYMMDD-XXX

• TYP: LRN (Lernen), ERR (Fehler), FEAT (Funktion)
• YYYYMMDD: Aktuelles Datum
• XXX: Fortlaufende Nummer oder 3 zufällige Zeichen (z.B. 001, A7B)

Beispiele: LRN-20250115-001, ERR-20250115-A3F, FEAT-20250115-002

Einträge auflösen

Wenn ein Problem behoben ist, aktualisiere den Eintrag:

1. Ändere **Status**: ausstehend → **Status**: gelöst
2. Füge einen Auflösungsblock nach den Metadaten hinzu:

### Auflösung
- **Gelöst**: 2025-01-16T09:00:00Z
- **Commit/PR**: abc123 oder #42
- **Notizen**: Kurze Beschreibung dessen, was getan wurde

Andere Statuswerte:

• in_bearbeitung - Wird aktiv bearbeitet
• wird_nicht_gefixt - Es wurde entschieden, es nicht zu adressieren (Grund in Auflösungsnotizen angeben)
• uebernommen - In CLAUDE.md, AGENTS.md oder .github/copilot-instructions.md hochgestuft

Ins Projektgedächtnis übernehmen

Wenn eine Erkenntnis allgemein anwendbar ist (kein einmaliger Fix), übernehme sie in das dauerhafte Projektgedächtnis.

Wann übernehmen

• Erkenntnis gilt für mehrere Dateien/Funktionen
• Wissen, das jeder Mitwirkende (Mensch oder KI) kennen sollte
• Verhindert wiederkehrende Fehler
• Dokumentiert projektspezifische Konventionen

Übernahmeziele

Ziel	Was gehört dorthin
CLAUDE.md	Projektfakten, Konventionen, Tücken für alle Claude-Interaktionen
AGENTS.md	Agenten-spezifische Workflows, Toolnutzungsmuster, Automatisierungsregeln
.github/copilot-instructions.md	Projektkontext und Konventionen für GitHub Copilot
SOUL.md	Verhaltensrichtlinien, Kommunikationsstil, Prinzipien (OpenClaw-Arbeitsbereich)
TOOLS.md	Tool-Funktionen, Nutzungsmuster, Integrations-Tücken (OpenClaw-Arbeitsbereich)

Wie übernehmen

1. Destilliere die Erkenntnis zu einer prägnanten Regel oder Tatsache
2. Füge sie in den entsprechenden Abschnitt der Zieldatei ein (Datei bei Bedarf erstellen)
3. Aktualisiere den ursprünglichen Eintrag:
   • Ändere **Status**: ausstehend → **Status**: übernommen
   • Füge **Übernommen nach**: CLAUDE.md, AGENTS.md oder .github/copilot-instructions.md hinzu

Beispiele für Übernahmen

Erkenntnis (ausführlich):

Projekt verwendet pnpm-Workspaces. Versuchte npm install, aber es schlug fehl. Sperrdatei ist pnpm-lock.yaml. Muss pnpm install verwenden.

In CLAUDE.md (prägnant):

## Build & Abhängigkeiten
- Paketmanager: pnpm (nicht npm) - verwende `pnpm install`

Erkenntnis (ausführlich):

Beim Ändern von API-Endpunkten muss der TypeScript-Client neu generiert werden. Das Vergessen verursacht zur Laufzeit Typkonflikte.

In AGENTS.md (handlungsorientiert):

## Nach API-Änderungen
1. Client neu generieren: `pnpm run generate:api`
2. Auf Typfehler prüfen: `pnpm tsc --noEmit`

Erkennung wiederkehrender Muster

Wenn etwas Ähnliches wie ein vorhandener Eintrag protokolliert wird:

1. Zuerst suchen: grep -r "stichwort" .learnings/
2. Einträge verlinken: Füge **Siehe auch**: ERR-20250110-001 in den Metadaten hinzu
3. Priorität erhöhen, wenn das Problem immer wieder auftritt
4. Systemischen Fix erwägen: Wiederkehrende Probleme deuten oft auf Folgendes hin:
   • Fehlende Dokumentation (→ in CLAUDE.md oder .github/copilot-instructions.md übernehmen)
   • Fehlende Automatisierung (→ zu AGENTS.md hinzufügen)
   • Architekturproblem (→ Tech-Debt-Ticket erstellen)

Regelmäßige Überprüfung

Überprüfe .learnings/ an natürlichen Haltepunkten:

Wann überprüfen

• Vor Beginn einer neuen Hauptaufgabe
• Nach Fertigstellung einer Funktion
• Bei der Arbeit in einem Bereich mit früheren Erkenntnissen
• Wöchentlich während der aktiven Entwicklung

Schnelle Statusprüfung

# Anzahl ausstehender Einträge zählen
grep -h "Status\*\*: ausstehend" .learnings/*.md | wc -l

# Ausstehende Einträge mit hoher Priorität auflisten
grep -B5 "Priorität\*\*: hoch" .learnings/*.md | grep "^## \["

# Erkenntnisse für einen bestimmten Bereich finden
grep -l "Bereich\*\*: backend" .learnings/*.md

Überprüfungsaktionen

• Behobene Einträge auflösen
• Anwendbare Erkenntnisse übernehmen
• Zugehörige Einträge verlinken
• Wiederkehrende Probleme eskalieren

Erkennungsauslöser

Automatisch protokollieren, wenn du Folgendes bemerkst:

Korrekturen (→ Lerneintrag mit Kategorie correction):

• "Nein, das ist nicht richtig..."
• "Eigentlich sollte es..."
• "Du liegst falsch mit..."
• "Das ist veraltet..."

Funktionsanfragen (→ Funktionsanfrage):

• "Kannst du auch..."
• "Ich wünschte, du könntest..."
• "Gibt es eine Möglichkeit..."
• "Warum kannst du nicht..."

Wissenslücken (→ Lerneintrag mit Kategorie knowledge_gap):

• Benutzer gibt Informationen, die du nicht wusstest
• Dokumentation, auf die du verwiesen hast, ist veraltet
• API-Verhalten weicht von deinem Verständnis ab

Fehler (→ Fehlereintrag):

• Befehl gibt Exit-Code ungleich null zurück
• Ausnahme oder Stacktrace
• Unerwartete Ausgabe oder Verhalten
• Timeout oder Verbindungsfehler

Prioritätsrichtlinien

Priorität	Wann verwenden
kritisch	Blockiert Kernfunktionalität, Datenverlustrisiko, Sicherheitsproblem
hoch	Signifikante Auswirkungen, betrifft häufige Workflows, wiederkehrendes Problem
mittel	Moderate Auswirkungen, Workaround vorhanden
niedrig	Geringfügige Unannehmlichkeit, Randfall, nice-to-have

Bereichs-Tags

Verwende, um Erkenntnisse nach Codebasis-Bereich zu filtern:

Bereich	Umfang
frontend	UI, Komponenten, clientseitiger Code
backend	API, Dienste, serverseitiger Code
infra	CI/CD, Bereitstellung, Docker, Cloud
tests	Testdateien, Testwerkzeuge, Abdeckung
docs	Dokumentation, Kommentare, READMEs
config	Konfigurationsdateien, Umgebung, Einstellungen

Best Practices

1. Sofort protokollieren - Der Kontext ist direkt nach dem Problem am frischesten
2. Sei spezifisch - Zukünftige Agenten müssen schnell verstehen
3. Reproduktionsschritte angeben - Besonders bei Fehlern
4. Zugehörige Dateien verlinken - Macht Korrekturen einfacher
5. Konkrete Korrekturen vorschlagen - Nicht nur "untersuchen"
6. Konsistente Kategorien verwenden - Ermöglicht Filterung
7. Aggressiv übernehmen - Im Zweifelsfall zu CLAUDE.md oder .github/copilot-instructions.md hinzufügen
8. Regelmäßig überprüfen - Veraltete Erkenntnisse verlieren an Wert

Gitignore-Optionen

Erkenntnisse lokal behalten (pro Entwickler):

.learnings/

Erkenntnisse im Repository verfolgen (teamweit): Nicht zu .gitignore hinzufügen - Erkenntnisse werden zu gemeinsamem Wissen.

Hybrid (Vorlagen verfolgen, Einträge ignorieren):

.learnings/*.md
!.learnings/.gitkeep

Hook-Integration

Aktiviere automatische Erinnerungen durch Agent-Hooks. Dies ist optional - du musst Hooks explizit konfigurieren.

Schnelle Einrichtung (Claude Code / Codex)

Erstelle .claude/settings.json in deinem Projekt:

{
  "hooks": {
    "UserPromptSubmit": [{
      "matcher": "",
      "hooks": [{
        "type": "command",
        "command": "./skills/self-improvement/scripts/activator.sh"
      }]
    }]
  }
}

Dies fügt nach jeder Eingabeaufforderung eine Erinnerung zur Lernbewertung ein (~50-100 Token Aufwand).

Vollständige Einrichtung (Mit Fehlererkennung)

{
  "hooks": {
    "UserPromptSubmit": [{
      "matcher": "",
      "hooks": [{
        "type": "command",
        "command": "./skills/self-improvement/scripts/activator.sh"
      }]
    }],
    "PostToolUse": [{
      "matcher": "Bash",
      "hooks": [{
        "type": "command",
        "command": "./skills/self-improvement/scripts/error-detector.sh"
      }]
    }]
  }
}

Verfügbare Hook-Skripte

Skript	Hook-Typ	Zweck
scripts/activator.sh	UserPromptSubmit	Erinnert daran, nach Aufgaben Erkenntnisse zu bewerten
scripts/error-detector.sh	PostToolUse (Bash)	Wird bei Befehlsfehlern ausgelöst

Siehe references/hooks-setup.md für detaillierte Konfiguration und Fehlerbehebung.

Automatische Skill-Extraktion

Wenn eine Erkenntnis wertvoll genug ist, um ein wiederverwendbarer Skill zu werden, extrahiere sie mit dem bereitgestellten Helfer.

Kriterien für Skill-Extraktion

Eine Erkenntnis qualifiziert sich für die Skill-Extraktion, wenn JEDES der folgenden Kriterien zutrifft:

Kriterium	Beschreibung
Wiederkehrend	Hat Siehe auch-Links zu 2+ ähnlichen Problemen
Verifiziert	Status ist gelöst mit funktionierendem Fix
Nicht offensichtlich	Erforderte tatsächliches Debuggen/Untersuchung um es zu entdecken
Allgemein anwendbar	Nicht projektspezifisch; nützlich über Codebasen hinweg
Vom Benutzer markiert	Benutzer sagt "speichere dies als Skill" oder ähnlich

Extraktions-Workflow

1. Kandidaten identifizieren: Erkenntnis erfüllt Extraktionskriterien
2. Helfer ausführen (oder manuell erstellen):

   ./skills/self-improvement/scripts/extract-skill.sh skill-name --dry-run
   ./skills/self-improvement/scripts/extract-skill.sh skill-name
   

3. SKILL.md anpassen: Vorlage mit Lerninhalt füllen
4. Lerneintrag aktualisieren: Status auf promoted_to_skill setzen, Skill-Pfad hinzufügen
5. Überprüfen: Skill in einer neuen Sitzung lesen, um sicherzustellen, dass er in sich geschlossen ist

Manuelle Extraktion

Wenn du die manuelle Extraktion bevorzugst, erstelle einen neuen Skill-Ordner:

mkdir -p skills/mein-skill-name
cp skills/self-improvement/templates/SKILL.md skills/mein-skill-name/

Fülle dann die Vorlage aus:

# Mein Skill-Name

## Beschreibung
Kurze Beschreibung dessen, was dieser Skill bewirkt

## Auslöser
Wann dieser Skill aktiviert werden sollte

## Aktion
Was der Agent tun soll

## Konfiguration
Alle notwendigen Setup-Schritte (Umgebungsvariablen, API-Keys, Dateipfade)

## Beispiele
- Beispiel 1: ...
- Beispiel 2: ...

## Zugehörige Erkenntnisse
- LRN-20250115-042: Ursprüngliche Erkenntnis, die zu diesem Skill führte
- LRN-20250120-015: Verfeinerung des Ansatzes

Extraktionsvorlage

Verwende templates/SKILL.md als Ausgangspunkt:

cp skills/self-improvement/templates/SKILL.md skills/mein-skill-name/SKILL.md

Diese Vorlage enthält Platzhalter für:

• {{SKILL_NAME}} — Der Name des Skills
• {{TRIGGER}} — Wann der Skill verwendet werden soll
• {{ACTION}} — Was der Agent tun soll
• {{CONFIG}} — Alle notwendigen Setup-Schritte
• {{EXAMPLE}} — Anwendungsbeispiele
• {{LEARNINGS}} — Verweise auf ursprüngliche Erkenntnisse

Referenzen

• references/openclaw-integration.md — Vollständige OpenClaw-Konfiguration
• references/hooks-setup.md — Detaillierte Hook-Konfiguration und Fehlerbehebung
• templates/SKILL.md — Vorlage für die Skill-Extraktion
• assets/ — Beispiel-Lerndateien
• scripts/ — Hilfsskripte (Aktivator, Fehlererkennung, Extraktion)