commit 8576b8351c887ed072f0cae9b10758d635c3191a
Author: Hector the Butler <hector-bot@botreasury>
Date:   Fri Jun 5 12:55:00 2026 +0200

    Initial: Projektplan + Analyse für Knowledge Base

diff --git a/README.md b/README.md
new file mode 100644
index 0000000..4ad6d07
--- /dev/null
+++ b/README.md
@@ -0,0 +1,122 @@
+# 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*
\ No newline at end of file