eiway112/agent-wiki

Knowledge-Base-Betriebsworkflow (LLM-Wiki-Modus)

Positionierung & Anwendbarkeit

Dieser Skill ist eine plattformunabhängige Methodik: Externes Wissen wird in Verhaltensregeln (Memory/Spezifikationen/Skills) umgewandelt, die der KI-Agent zur Laufzeit aufrufen kann. Die Wissensdatenbank ist kein Lesezeichen-Ordner, sondern der Motor für die Fähigkeitssteigerung des Agenten – jeder eingepflegte Wissenseintrag muss destilliert werden; das einzige Bewertungskriterium ist: Kann er direkt die Entscheidungen des Agenten in konkreten Szenarien beeinflussen?

• Wenn das Projekt bereits eigene Spezifikationsdateien (z. B. project_specs.md) besitzt, dienen diese als maßgebliche Referenz; bei Konflikten haben die Projektspezifikationen Vorrang.
• Bei der Anwendung auf verschiedenen Plattformen/Projekten wird die dreischichtige Architektur und der Workflow dieses Skills befolgt; Verzeichnisnamen können lokalisiert werden. Das Repository examples/ enthält minimal funktionierende Beispiele.

Dreischichtige Architektur

Schicht	Empfohlenes Verzeichnis	Beschaffenheit
Raw Sources	raw_collected/ (Artikel/Diskussionen/Videos)	Schreibgeschützt – nach der Erfassung unveränderlich
The Wiki	knowledge_base/ (catalog.md, collection_experience.md, operation_log.md)	Vom LLM gewartete, abgeleitete Inhalte
The Schema	project_specs.md + program_files/config/	Gemeinsam von Mensch und LLM gewartet

Schlüsselprinzip: Originaldateien bleiben immer in den Raw Sources; sie werden nicht in das Wiki verschoben. Nach bestandener Prüfung wird ein Verweis im catalog.md eingetragen – das gilt als „Aufnahme in die Wissensdatenbank".

Rollentrennung (Verbindlich)

Rolle	Entität	Aufgaben	Verbote
Planer	Mensch	Ziele für die Erfassung festlegen, Wertvertrag definieren, Analyserichtung vorgeben	Keine direkte Dateibearbeitung
Generator	LLM	Erfassung durchführen, Metadaten ergänzen, Zusammenfassungen schreiben, Katalog und Logs pflegen	Eigene Output-Qualität nicht selbst bewerten
Evaluator	Prüf-Werkzeug (z. B. scripts/validate.py)	Unabhängige Prüfung von Format, Kodierung, Metadaten und Querverweisen	Nicht an der Generierung beteiligt

Kernregel: Das Modell bewertet sich nicht selbst. Die Wertbewertung wird vom Generator im Betriebsprotokoll festgehalten; ob eine Prüfung bestanden ist, entscheidet der Evaluator. Bei Meinungsverschiedenheiten des Menschen hat dessen Beurteilung Vorrang. Wenn kein Prüf-Werkzeug vorhanden ist, wird die sechsdimensionale Lint-Prüfung manuell durchgeführt; dennoch darf die Schlussfolgerung nicht vom Generator selbst stammen.

Ingest (Aufnahme)

Dieses Tracking-Liste kopieren und abarbeiten:

- [ ] 1. Wertvertrag vor der Erfassung (Drei Fragen)
- [ ] 2. Erfassung & Metadaten ergänzen
- [ ] 3. Inhalt lesen, Schlüsselinformationen extrahieren
- [ ] 4. Wertbewertung (bei Nichtbestehen abbrechen)
- [ ] 5. catalog.md aktualisieren (Zusammenfassung + Querverweise)
- [ ] 6. Betriebsprotokoll ergänzen
- [ ] 7. Destillationsbewertung & Statusmarkierung
- [ ] 8. Git-Commit

Schritt 1 · Wertvertrag vor der Erfassung – Vor dem Start die drei Fragen beantworten und protokollieren:

1. Welches Problem soll dieser Artikel lösen? Wie verhält er sich zu vorhandenem Wissen? (Ergänzung/Vergleich/Erweiterung)
2. Unter welcher Bedingung gilt er als „wertvoll"? Mindestens ein Kriterium muss erfüllt sein: Einführung eines neuen Konzepts, bietet eine Vergleichsperspektive, direkte praktische Anwendbarkeit.
3. In welche Ebene von catalog.md wird er voraussichtlich eingeordnet? (Grundlagentheorie/Architektur-Muster/Engineering-Praxis/Tools & Ressourcen/Community-News)

Schritt 2 · Erfassung & Metadaten – Verwende die Erfassungs-Engine der aktuellen Plattform, um den Originaltext zu beschaffen (siehe „Abstraktion der Erfassungs-Engine"). Speichere ihn im entsprechenden Unterverzeichnis von Raw Sources, Dateiname nach dem Schema {source}_{topic}_{date}.{ext} (z. B. github_karpathy_llm_wiki_20260630.md). Erforderliche Metadaten-Felder: URL, Erfassungszeit, Erfassungsbefehl; empfohlene Felder: By, Site, Published, Originalquelle. Die Erfassungs-Engine kann meist nur einen Teil der Felder automatisch extrahieren; die restlichen müssen ergänzt werden.

Schritt 4 · Wertbewertung (inkl. Abbruch) – Vergleiche mit dem Wertvertrag aus Schritt 1. Wenn keines der Wertkriterien klar erfüllt ist (inhaltsleer, starke Redundanz, kein Bezug zum Wissensdatenbank-Fokus), protokolliere den Abbruchgrund explizit im Betriebsprotokoll, beende den Vorgang und erzwinge nicht die vollständige Aufnahme.

Schritt 6 · Format des Betriebsprotokolls: ## [Datum] ingest | Titel (append-only).

Schritt 7 · Destillationsbewertung – Enthält der Eintrag atomare Regeln, die direkt das Verhalten des KI-Agenten steuern können?

Markierung	Bedeutung	Aktion
🟢 Übernommen	Enthält ausführbare atomare Regeln	Regeln extrahieren und in Memory/Spezifikationen/Skills schreiben; im catalog.md-Eintrag den Memory-Titel notieren
🟡 Teilweise übernommen	Teilweise vorhanden	Angeben, welche Teile übernommen wurden und welche nicht, mit Begründung
🔵 Referenz-Indikator	Keine ausführbaren Regeln	Grund im Betriebsprotokoll kurz angeben

Destillationskriterium: Die Regel muss die Entscheidungen des Agenten in konkreten Szenarien verändern können – keine abstrakten Ideen oder Referenzinformationen.

Plattformübergreifende Destillationsanpassung: In Qoder wird das Destillationsprodukt in das Memory-System geschrieben (Methodik→task_experience, Fallstricke→common_pitfalls_experience, Architekturentscheidungen→important_decision_experience usw.). Auf anderen KI-Agenten-Plattformen wird es in den entsprechenden persistenten Memory-/Verhaltensregel-Mechanismus der jeweiligen Plattform abgebildet; Bewertungskriterium und Farbmarkierungen bleiben unverändert.

Schritt 8: git add -A && git commit -m "ingest: Titel".

Query (Abfrage)

1. Zuerst knowledge_base/catalog.md lesen, um die relevanten Seiten zu identifizieren
2. Die entsprechenden Dateien vertieft lesen, Antwort synthetisieren
3. Gute Antworten als neue Seite rückfüllen – so generiert die Erkundung selbst Zinseszins
4. Betriebsprotokoll ergänzen: ## [Datum] query | Frage
5. Nach Erzeugung einer neuen Seite: git add -A && git commit -m "query: Frage"

Lint (Prüfung)

Zunächst das projektspezifische Prüf-Werkzeug ausführen (dieses Repository bietet ein null-Abhängigkeits-Beispiel: python scripts/validate.py <Wissensdatenbank-Stammverzeichnis>). Die Entscheidung des Werkzeugs hat Vorrang vor manueller Beurteilung. Ohne Werkzeug nach den sechs Dimensionen prüfen:

1. Metadaten-Vollständigkeit – Sind alle Pflichtfelder (URL, Erfassungszeit, Erfassungsbefehl) vorhanden?
2. Kodierungskorrektheit – Doppelt kodierte Zeichen, BOM, Ersatzzeichen (U+FFFD)
3. Format-Konformität – Markdown muss mit H1 beginnen, Metadaten und Fließtext durch --- getrennt; JSON muss ein _metadata-Feld enthalten
4. Namenskonvention – Folgt der Dateiname dem Schema {source}_{topic}_{date}?
5. Querverweise – Verweisen die Links in catalog.md auf tatsächliche Dateien? Erkennung von Waisen-Seiten
6. Quellenprüfung – Gehört die URL zur Whitelist der Quellen?

Betriebsprotokoll ergänzen: ## [Datum] lint | Prüfumfang; bei Korrekturen: git commit -m "lint: Prüfumfang".

Harness-Abbau: Prüf-Werkzeuge und Workflows sind Hilfsmechanismen, die Modell-Schwächen kompensieren; sie sollten mit zunehmender Modellverbesserung kontinuierlich reduziert werden. Bei jeder Lint-Prüfung hinterfragen: Welche Prüfregeln werden nicht mehr ausgelöst? Welche Schritte hat das Modell bereits verinnerlicht? Lösche sie.

Abstraktion der Erfassungs-Engine (Plattform-übergreifend)

Der Kern-Workflow ist an kein bestimmtes Erfassungswerkzeug gebunden; die Erfassungs-Engine wird basierend auf der Verfügbarkeit der Plattform ausgewählt:

Plattform-Umgebung	Erfassungsmethode
Windows + Edge-Browser	AutoCLI: autocli read "URL" -f markdown -o "Ausgabepfad", extrahiert automatisch By/Site/URL; Achtung: unter PowerShell werden stderr-Fortschrittsmeldungen fälschlich als ExitCode=1 gemeldet – Ausgabe enthält „Saved to ..." bei Erfolg
KI-Agenten-Plattform mit Web-Lese-Fähigkeit	Web-Fetch-Tool (oder ähnlich) zum direkten Herunterladen und Konvertieren nach Markdown
Öffentliche API-Quellen	Hacker News, Lobsters usw. – benötigen keinen Browser, direkte API-Anfragen
Kein Netzwerktool	Benutzer fügt Originaltext ein, manuelle Speicherung mit ehrlicher Angabe des Erfassungsbefehl als „manuelles Einfügen"

Unabhängig von der Engine sind die Anforderungen an Metadaten, Prüfung und Destillation nach der Aufnahme identisch. Das Feld Erfassungsbefehl dokumentiert ehrlich die tatsächlich verwendete Engine und den Befehl (einschließlich Downgrade-Wechsel), um Reproduzierbarkeit zu gewährleisten.

Kurzübersicht der Konventionen

• Dateiname: {source}_{topic}_{date}.{ext}, source in Kleinbuchstaben
• Betriebsprotokoll: append-only, Format ## [Datum] {ingest|query|lint} | Kurzbeschreibung
• Commit-Nachricht: {ingest|query|lint}: {Kurzbeschreibung}; Initialisierung: init: Wissensdatenbank-Baseline
• Strukturierte Aufzeichnung von Fallstricken und Erkenntnissen in collection_experience.md, nicht im Betriebsprotokoll