Irgendwann passiert es jedem Team, das einen Dev-Advisor-Bot ernsthaft nutzt: Der Bot wirkt plötzlich “schlauer”, weil du ihm mehr Kontext gibst – und genau dadurch wird er gefährlicher.

Das Muster ist immer ähnlich. Du willst einen PR reviewen. Du copy-pastest ein paar Files, dann noch ein Stück Terraform, dann eine alte ADR, dann ein Ticket-Thread aus Jira. Der Bot antwortet schnell, selbstbewusst, plausibel. Du übernimmst zwei Sätze – und merkst später: Er hat eine Annahme gemacht, die bei euch nie gilt. Nicht, weil er böswillig ist. Sondern weil du ihm einen Kontext-Cocktail gegeben hast, in dem “Source of Truth” und “Noise” nicht mehr unterscheidbar waren.

Wenn du Openclaw als Tech/Dev-Advisor stabil bauen willst, ist Kontext keine Beilage. Kontext ist ein Systembestandteil – mit Regeln, Lebenszyklus und Governance. Und ja: Das ist exakt “Data as a Product”-Denken, nur diesmal für Inputs.

Der zentrale Gedanke: Kontext ist ein Produkt – nicht ein Prompt-Appendix

In Data-Produkten hast du gelernt: “Mehr Daten” ist nicht automatisch “mehr Wert”. Ohne Struktur wird es nur mehr Angriffsfläche, mehr Missverständnis, mehr Kosten.

Bei Bots ist es genauso. Kontext ist dein Rohstoff. Und wie bei Rohstoff gilt: Du brauchst Verarbeitung, Klassifizierung und ein klares Vertrauensmodell. Sonst bekommst du Halluzinationen, Fehlentscheidungen oder – im schlimmsten Fall – Sicherheits- und Compliance-Probleme.

Die wichtigste Frage für Openclaw lautet deshalb nicht: “Wie gebe ich ihm möglichst viel?”
Sondern: “Welche Art von Kontext darf er überhaupt sehen – und unter welchen Bedingungen?”

Die drei Kontext-Schichten, die du sauber trennen musst

In der Praxis funktioniert ein Dev-Advisor-Bot dann gut, wenn du Kontext in drei Schichten behandelst – wie Datenzonen:

1. Session Context (flüchtig)
   Das ist alles, was in dieser Konversation relevant ist: ein PR-Diff, ein Log-Auszug, eine Frage, ein aktueller Entwurf. Das darf kurzfristig helfen, soll aber nicht “Wahrheit” werden.
2. Memory (persönliche Präferenzen & Arbeitsstil)
   Das sind Dinge wie: “Antwortformat kurz”, “Sprache Deutsch”, “Fokus auf Spec-Driven Development”, “Security-by-default”, “Azure/Fabric/Synapse-Umfeld”. Memory ist kein Wissensspeicher, sondern ein Stil- und Arbeitsvertrag. Und Memory ist der Ort, an dem du am schnellsten aus Versehen heikle Dinge “mitträgst”, wenn du nicht hart begrenzt.
3. Knowledge (versionierte Fakten, Policies, Specs)
   Das ist dein stabiler Teil: Repo-Dokumentation, ADRs, Architekturprinzipien, Coding Standards, Plattform-Policies. Knowledge ist das, was in einem Team eigentlich “gilt”. Und genau deshalb gehört es versioniert und zitierbar in eine Wissensbasis, nicht in den Chatverlauf.

Wenn du diese drei Schichten sauber trennst, lösen sich viele Probleme von allein. Der Bot kann dann gleichzeitig hilfreich und kontrollierbar sein.

Sources of Truth: Openclaw braucht eine Hierarchie

Ein Dev-Advisor darf nicht so tun, als sei alles gleich vertrauenswürdig. Darum gibst du ihm eine Hierarchie, die er konsequent anwendet. Das kann so simpel sein wie diese Tabelle:

Rang	Quelle	Beispiel	Warum das zählt
1	Policies / Standards / ADRs	security-policy.md, adr-012-staging.md	Definiert “was gilt”
2	Repo-Code & IaC	PR-Diff, Terraform, Pipeline YAML	Definiert “was ist”
3	Tickets / Chat / Slack	Jira-Kommentare, Diskussionen	Kontext, aber oft unvollständig
4	Vermutungen	“Ich denke, ihr nutzt X”	Muss als Annahme markiert werden

Das klingt banal, ist aber ein echter Qualitätssprung: Openclaw lernt, dass er lieber nachfragt, als Rang-3-Kontext als Rang-1-Wahrheit zu behandeln.

RAG in normaler Sprache: “Hol nur das, was du belegen kannst”

RAG (Retrieval Augmented Generation) wird oft als Buzzword verkauft. Für Openclaw ist es schlicht eine Disziplin: Er darf aus deiner Wissensbasis nur dann “sprechen”, wenn er auch sauber sagen kann, woher es kommt.

Das bringt zwei Effekte, die du aus Data Governance kennst:

• Nachvollziehbarkeit: Aussagen sind auditierbar (“steht in ADR-012, Abschnitt 3”).
• Freshness: Du kannst aktiv steuern, welche Version gilt (Branch/Tag/Release).

Und es löst einen Klassiker: “Der Bot hat das irgendwo gelesen.” – Nein. Er hat es aus genau dieser Datei in genau diesem Commit.

Kontext-Minimierung: Weniger ist nicht nur besser – es ist sicherer

Openclaw sollte standardmäßig so arbeiten, als wäre jedes zusätzliche Stück Kontext eine potenzielle Schwachstelle. Nicht paranoid, sondern professionell.

Was das praktisch bedeutet:

Wenn du Logs gibst, gibst du nicht “alles”, sondern den kleinsten Ausschnitt, der das Problem zeigt. Wenn du Code gibst, gibst du nicht das ganze Repo, sondern den relevanten Layer plus Interfaces. Wenn du Policies gibst, gibst du nicht den PDF-Friedhof, sondern den konkreten Abschnitt.

Das ist “least privilege” für Kontext – und es passt perfekt zu einem Dev-Advisor, der Security-by-default lebt.

Das wichtigste Artefakt für Post #4: die “Context Map” (v0.1)

Wenn du Openclaw wachsen lassen willst, braucht er ein Dokument, das erklärt, wie Kontext fließt. Nicht als Architekturposter, sondern als Betriebsanleitung.

Hier ist ein leichtgewichtiger Start, den du in dein Repo legen kannst: openclaw.context-map.md.

Kerninhalt (in Prosa, nicht als Overkill):
Openclaw nutzt Session Context nur für die aktuelle Aufgabe und behandelt ihn als potenziell unvollständig. Memory enthält ausschließlich Kommunikations- und Arbeitspräferenzen, keine Secrets, keine personenbezogenen Daten, keine technischen Zugangsdaten. Knowledge ist die einzige langfristige Faktenbasis und muss versioniert, referenzierbar und kuratiert sein. Bei Widersprüchen gilt: Policies/ADRs schlagen Tickets/Chat. Wenn Knowledge fehlt oder zu alt ist, fragt Openclaw nach oder liefert Optionen mit klaren Annahmen.

Damit hast du einen “Contract”, den du später erweitern kannst – aber schon v0.1 verhindert die meisten Kontext-Unfälle.

Ein Praxisbeispiel: PR Review ohne Kontext-Salat

Stell dir vor, du willst einen Terraform-PR reviewen. Der häufigste Fehler ist, dem Bot einfach den ganzen PR-Text zu geben und zu hoffen, dass er “alles sieht”.

Der bessere Flow ist:

Openclaw bekommt den Diff (Session Context), plus einen Link/Verweis auf eure relevanten Standards (Knowledge), zum Beispiel “RBAC-Guideline”, “Naming Conventions”, “Change-Window Policy”. Dann kann er zwei Dinge tun, die du wirklich willst: Er kann den PR gegen die Standards prüfen, und er kann seine Kritik belegen (“weicht von Naming Policy ab”). Und wenn ihm etwas fehlt (z.B. welche Subscription, welches Environment), fragt er genau danach – statt zu raten.

Das ist der Unterschied zwischen “AI schreibt Kommentare” und “AI ist ein verlässlicher Reviewer”.

Mini-CTA: Was du jetzt anlegst, bevor wir Skills bauen

Bevor wir im nächsten Post tiefer in Skill-first Thinking gehen, leg diese drei Dateien an (wirklich nur diese drei, keine Materialschlacht):

• openclaw.context-map.md (Kontext-Regeln und Hierarchie)
• openclaw.memory-allowlist.md (was Memory sein darf – und was nie)
• openclaw.knowledge-registry.yaml (Liste der zugelassenen Knowledge-Quellen: ADRs, Policies, Standards)

Damit hast du die Grundlage, damit Skills später nicht “wild” werden. Denn ein Skill ohne Kontext-Disziplin ist wie ein Pipeline-Job ohne Guardrails: schnell, beeindruckend – und irgendwann teuer.