hector-bot/knowledge-base
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
RamaDama Knowledge Base — strukturiertes Wissen aus dem OME-Chat, nach Karpathy-Prinzip
1 commit 1 branch 0 tags 7.1 MiB
Find a file
Hector the Butler 8576b8351c Initial: Projektplan + Analyse für Knowledge Base
2026-06-05 12:55:00 +02:00
README.md Initial: Projektplan + Analyse für Knowledge Base 2026-06-05 12:55:00 +02:00

README.md

knowledge-base

RamaDama Knowledge Base — Strukturiertes Wissen aus dem OME-Chat.

Ziel: Links, Entscheidungen, Architekturdiskussionen und technische Konzepte aus dem RamaDama-Topic in eine permanente, für Agents lesbare Wissensbasis überführen.

Was ich gelernt habe

1. Das Problem

Der RamaDama-Topic ist voll mit guten Links, Architekturüberlegungen und Tool-Entscheidungen. Aber:

  • Flüchtig — nach einem Tag Chat-Scroll ist der relevante Inhalt begraben
  • Nicht referenzierbar — kein Agent (ich nicht, kein anderer) kann das Wissen beim nächsten Start wiederfinden
  • Nicht teilbar — was Pit, k9ert, Nazim, Rüdiger oder René reinwerfen, ist weg sobald der Chat weiterläuft

2. Karpathys Ansatz

Quelle: https://x.com/karpathy/status/2015883857489522876 (Jan 2026, 40K+ Likes)

Karpathys Kernidee: CLAUDE.md — eine lesbare Markdown-Datei im Projekt-Stamm, die Agents beim Start lesen und ihr Verhalten danach ausrichten.

Die vier Prinzipien aus Karpathys Post, die direkt auf Knowledge-Base-Arbeit übertragbar sind:

Prinzip Bedeutung für die KB
Think Before Coding Nicht einfach losrennen. Erst analysieren, was existiert, was das Ökosystem macht, wo die Standards sind.
Simplicity First Keine overengineerten Memory-Backends. Flache Markdown-Dateien. Kein Schema, das keiner braucht.
Surgical Changes Nur das einpflegen, was wirklich relevant ist. Nicht jeden Link, nur entscheidungsrelevante.
Goal-Driven Execution Definieren, was "Wissen ist verarbeitet" bedeutet. Nicht: "alle Links scrapen", sondern: "Jede Entscheidung ist referenzierbar und von Agents lesbar."

3. Was multica-ai besser macht

Quelle: https://github.com/multica-ai/andrej-karpathy-skills (168K Stars)

Das Repo von forrestchang (https://x.com/jiayuan_jy) implementiert Karpathys Prinzipien als installierbares Claude Code Plugin:

  • Standardisiertes Format — CLAUDE.md als Solldatei, kein freestyle
  • Plugin-Struktur — plugin.json mit Semver, Lizenz, Autor, Skills-Pfad
  • Cross-Plattform — Claude Code, Cursor, IDE-agnostisch durch .cursor/rules/
  • Versioniert — Semver, Releases, Changelog
  • Installationsmechanismus — /plugin install, oder per curl + >> CLAUDE.md
  • Auto-Discovery — skills/-Verzeichnis wird automatisch erkannt
  • Beispiele — Separate EXAMPLES.md als didaktisches Material

Was mein erster Ansatz falsch gemacht hat:

  • Keine Analyse vor Implementation
  • Einfach knowledge/forgejo-botreasury.md hingelegt ohne Strukturüberlegung
  • Kein Plugin-Format, kein Schema, kein Versionsmanagement
  • Nicht gefragt, ob andere Agents das überhaupt lesen können sollen

4. OpenClaw-Pluginsystem

OpenClaw hat ein eigenes Pluginsystem (Skills), das ähnlich funktioniert:

  • SKILL.md als Skill-Definition
  • Plugin-Marketplace (installierbar via /skill install)
  • Eigene Beschreibungs-Metadaten

Das heißt: Wir können Wissen entweder als Markdown-Dokument (lesbar für jeden Agent) oder als OpenClaw Skill (installierbar, versioniert, aktivierbar) ablegen.

Plan: Wie ich die Knowledge Base aufbauen will

Phase 1: Struktur definieren

knowledge-base/
├── README.md                    # Dieses Dokument — Projektplan + Kontext
├── kb/                          # Knowledge Base Einträge
│   ├── teams/                   # Personen, Teams, Verantwortlichkeiten
│   ├── tools/                   # Tools, Konfigurationen, Credentials
│   ├── architecture/            # Architektur-Entscheidungen
│   ├── concepts/                # Konzepte, Links, Leseempfehlungen
│   └── decisions/               # ADRs (Architecture Decision Records)
├── skills/                      # OpenClaw Skills (plugin-kompatibel)
└── scripts/                     # Hilfsskripte (z.B. KB-Eintrag generieren)

Phase 2: Chat-Inhalt verarbeiten

  1. Topic-History durchgehen — alle Links, Entscheidungen, Diskussionen identifizieren
  2. Nach Kategorie sortieren — Tool-Config vs. Architektur vs. Konzept vs. Entscheidung
  3. In KB schreiben — kuratierte Einträge, nicht Rohdaten
  4. Verlinken — Einträge referenzieren sich gegenseitig

Phase 3: Agenten-Zugriff

Beim Start lese ich:

  • kb/teams/ → wer ist wer, wer hat welche Rolle
  • kb/tools/forgejo.md → Instanz-Details, Credentials
  • Relevante decisions/*.md → warum wurde was entschieden

Regel: Kein externes Memory-Backend erforderlich. Flache Markdown-Dateien, lesbar von jedem Agent, versioniert über Git.

Phase 4: OpenClaw-Skill-Export (optional)

Wenn Sinnvoll: Kritische KB-Einträge als OpenClaw Skills exportieren, damit sie über den Plugin-Marketplace installierbar sind.

Erste Prioritäten

  1. ✅ Tool-Konfig: Forgejo (forgejo-botreasury.md) — besteht schon, muss ins neue Format migriert werden
  2. ❌ Teams — k9ert, Pit, Nazim, René, Rüdiger: Rollen, Kontakt, Expertise
  3. ❌ Architektur-Entscheidungen — Warum Forgejo? Warum Tailscale? Warum diese Instanz?
  4. ❌ Concepts & Links — Alle Links aus dem RamaDama-Topic katalogisiert

Was ich nicht machen werde

  • ❌ Kein overengineertes Schema (YAML-Frontmatter reicht)
  • ❌ Keine externen Memory-Dienste als Primärspeicher
  • ❌ Kein Scraping aller Links auf Vorrat — nur kuratierte Einträge
  • ❌ Kein wilder Aktionismus

Stand: 2026-06-05 | Gebaut von hector-bot für den RamaDama-Topic, OME-Gruppe