Rollenschicht
Innate ist hilfreich – es darf niemals die Hauptaufgabe blockieren. Alle Innate-Operationen erfolgen nach dem Best-Effort-Prinzip. Bei einem Tool-Fehler: einmal mit korrigiertem Aufruf wiederholen, dann abbrechen und fortfahren.
Wann abrufen
Rufe Wissen nur zu Beginn einer Aufgabe ab, wenn die Aufgabe:
- In einer Domäne mit bekannten wiederkehrenden Mustern liegt (z. B. einer bestimmten Codebasis, einem Framework oder Protokoll)
- Das Debuggen oder Beheben eines Problems betrifft, das möglicherweise schon einmal aufgetreten ist
- Architektur- oder Design-bezogen ist – frühere Entscheidungen sind relevant
Abruf überspringen für: schnelle Einzeiler, Fragen mit klaren Antworten, Aufgaben, die der Benutzer als völlig neues Gebiet ohne vorherigen Kontext abgegrenzt hat.
Abfrageformulierung
Verwende kanonische Absicht, nicht wörtliche Benutzerwörter. Halte Abfragen sitzungsübergreifend konsistent – dieselbe Problemklasse sollte immer dieselbe kanonische Form verwenden, da Innate Kontextstatistiken pro Abfragemuster sammelt.
| Benutzer sagt | Gute Abfrage | Schlechte Abfrage |
|---|---|---|
| „Warum stürzt das beim Start ab?“ | startup crash sqlite init | „Warum stürzt das beim Start ab“ |
| „Refaktoriere den Auth-Flow“ | auth flow session token handling | „Refaktoriere Auth-Flow“ |
| „Füge der API Ratenbegrenzung hinzu“ | rate limiting middleware pattern | „Füge Ratenbegrenzung hinzu“ |
| „Debugge den flaky test“ | flaky test race condition timing | „Debugge flaky test“ |
Aufruf: innate_recall(query=<kanonische_absicht>, budget=4000, source="mcp")
Füge abgerufene Wissenschnipsel in deinen Arbeitskontext ein. Erwähne dem Benutzer gegenüber, welches (falls vorhanden) relevante Vorwissen gefunden wurde – ein Satz reicht.
Automatischer Abruf-Hook
Wenn Innate mit Hooks installiert ist, kann ein UserPromptSubmit-Hook automatisch einen <innate-recall>-Block in die Konversation einfügen – er hat bereits einen relevanzgefilterten Abruf für die Eingabeaufforderung durchgeführt und trägt eine trace_id. Wenn du diesen Block siehst:
- Verwende seine
trace_idfür den abschließendeninnate_record– rufe nicht erneutinnate_recallfür dieselbe Aufgabe auf (das würde einen doppelten, nicht zugeordneten Trace erzeugen). - Behandle seine Wissenschnipsel genauso wie selbst abgerufene: wende an, was hilft, und schließe dann mit einem Urteil pro Wissenschnipsel ab (siehe unten).
- Wenn der Block fehlt und die Aufgabe es rechtfertigt, rufe manuell ab wie oben beschrieben.
Der Hook ist relevanzgefiltert, daher bedeutet sein Schweigen „nichts hat hoch genug bewertet“ – nicht „kein Wissen existiert“. Rufe manuell ab, wenn du relevantes Vorwissen vermutest, das der Filter übersehen hat.
Wann aufzeichnen
Zeichne nach einer Aufgabe auf, die ein echtes Ergebnis (Erfolg oder Misserfolg) hervorgebracht hat. Überspringe Aufzeichnungen für:
- Erkundende Hin- und Her-Kommunikation ohne endgültiges Ergebnis
- Aufgaben, bei denen der Benutzer vor Abschluss unterbrochen hat
- Reine Abfragen (der Benutzer hat nur eine Frage gestellt, nichts wurde gebaut oder geändert)
Ergebnistabelle
| Situation | outcome |
|---|---|
| Aufgabe abgeschlossen, Benutzer hat bestätigt oder das Ergebnis akzeptiert | ok |
| Aufgabe fehlgeschlagen, Ansatz war falsch, Benutzer musste korrigieren | fail |
| Sitzung abgebrochen, Ergebnis unklar | unknown |
Urteil pro Wissenschnipsel – Pflicht
Dies ist der wichtigste Vertrag in Innate: Die Vertrauenswürdigkeitseinstufung ist nur so gut wie die Präzision dessen, was du hier meldest. Jeder Abruf, der Wissenschnipsel hervorgebracht hat (manuell oder per Hook eingefügt), muss mit einem Urteil pro Wissenschnipsel abgeschlossen werden. Für jeden Wissenschnipsel, der dir vorgelegt wurde, fällt er in genau einen von drei Bereichen:
| Urteil | Bedeutung | Wohin |
|---|---|---|
| Verwendet + geholfen | Du hast ihn angewendet und er hat Zeit gespart / einen Fehler verhindert | used=[id] und feedback_up=[id] |
| Verwendet + in die Irre geführt | Du hast ihn angewendet, aber er war falsch oder hat dich in die falsche Richtung geschickt | used=[id] und feedback_down=[id] |
| Nicht verwendet | Abgerufen, aber nie angewendet | vollständig weglassen (nicht in used auflisten) |
Regeln, die das Signal sauber halten:
usedlistet nur Wissenschnipsel auf, die du aktiv in deiner Argumentation oder Ausgabe referenziert hast – typischerweise ein bis drei. Fülle es niemals mit bloß abgerufenen Wissenschnipseln auf.- Wenn du nichts angewendet hast, ist das ein echtes, wertvolles Signal: setze
used=[]explizit (bekannt keine). Überspringe die Aufzeichnung nicht – Stille ist nicht dasselbe wie „nichts hat geholfen“. - Ein Wissenschnipsel, den du
usedhast, sollte fast immer auch ein hoch oder runter Signal tragen. Ein verwendeter Wissenschnipsel ohne Urteil verschwendet den stärksten Ranking-Eingang, den du geben kannst. - Sei ehrlich bei
feedback_down. Ein falscher Wissenschnipsel, den du markierst, wird überprüft und archiviert; ein falscher Wissenschnipsel, den du unmarkiert lässt, führt weiterhin zukünftige Sitzungen in die Irre.
Ausgabe-Zusammenfassung – Strukturiertes Format
Schreibe einen in sich geschlossenen Satz, den ein zukünftiger Agent kalt anwenden kann. Verwende diese Struktur:
<was getan oder gelernt wurde> — <wichtige Einschränkung oder Methode> — <wann dies zutrifft>
Gute Beispiele:
SQLite-WAL-Modus-Erkennung behoben, indem PRAGMA journal_mode-Antwort überprüft wurde, anstatt WAL anzunehmen – tritt bei jeder neuen DB-Verbindung in Multi-Prozess-Setups aufFlaky-Auth-Test durch Einfügen eines Clock-Mocks behoben – die reale Systemzeit verursacht Race Conditions bei der Token-AblaufprüfungRatenbegrenzung muss vor der Auth-Middleware angewendet werden, nicht danach – sonst umgehen unauthentifizierte Anfragen die Begrenzung
Schlechte Beispiele (zu vage für Wiederverwendung):
Den Fehler behobenIch habe dem Benutzer bei Auth geholfenDas Problem war das Timing
Die output_summary wird der wiederverwendbare Wissenschnipsel. Wenn sie wie eine Geschichte klingt, schreibe sie als Prinzip um. Bevorzuge die allgemeine, übertragbare Form – entferne Repo-/Datei-/Funktionsnamen und einmalige Bezeichner und formuliere die Lektion so, dass sie auch im nächsten Projekt hilft; behalte projektspezifische Details nur, wenn die Lektion ohne sie ihren Sinn verlieren würde. Wenn du keine nützliche Zusammenfassung schreiben kannst, setze output="unknown" und überspringe die Aufzeichnung.
Aufruf: innate_record(trace_id=<id>, outcome=<ok|fail|unknown>, used=[<chunk_ids>], output_summary=<satz>)
Explizites Feedback – Warum es wichtig ist
Die feedback_up- / feedback_down-Listen aus der Urteilstabelle oben sind das schnellste Signal für die Wissensqualität und treiben direkt Ranking und Lebenszyklus: zwei Down-Signale auf demselben Wissenschnipsel lösen eine Governance-Überprüfung aus; fünf lösen automatische Archivierung aus. Umgekehrt ist wiederholtes used + feedback_up das, was einen pending-Wissenschnipsel zu active befördert. Das Zurückhalten von Feedback friert die Wissensbasis ein; Feedback zu geben, lässt gutes Wissen aufsteigen und schlechtes Wissen herausfallen.
Nominierung – Selten, Explizit
Verwende das nomination-Feld nur für wirklich generalisierbare Lektionen – Muster, die das nächste Mal viel Zeit sparen, wenn diese Art von Problem auftritt. Selten. Nicht für jede Aufgabe.
Format für Nominierung (in sich geschlossenes Prinzip):
<prinzip> — <wann es zutrifft> — <was vermieden werden sollte>
Beispiel:
innate_record(..., nomination="SQLite UNIQUE index on partial WHERE clause requires exact WHERE match in ON CONFLICT – gilt für alle Upsert-Muster; bare ON CONFLICT ohne WHERE führt stillschweigend zum Überspringen des Upserts")
MCP-Tool-Referenz
| Tool | Verwendung | Hinweise |
|---|---|---|
innate_recall | Aufgabenbeginn (wenn relevant) | Kanonische Abfrageform verwenden – konsistente Formulierung sammelt Kontextstatistiken |
innate_record | Aufgabenende (wenn echtes Ergebnis existiert) | Strukturierte output_summary + präzise verwendete IDs |
innate_add | Bestätigte Erkenntnis erfassen | Immer source="mcp"; geht in pending, wartet auf Überprüfung |
innate_spark | Schnelle Idee für später | Kurze destillierte Form; keine Überprüfung nötig |
innate_evolve | Sitzungsende | trigger="manual"; destilliert Protokolle + kuratiert Wissensbasis |
innate_inspect | Gesundheitscheck | Chunk-Anzahl, Schuldenverhältnis, Wiederaufbau-Warteschlange |
innate_appraise | Bauchgefühl vor einem riskanten Schritt | Referenzsignal nur – Intuition, KEINE präzise Antwort. Gewichte es als einen Input; lasse es niemals deine eigene Analyse überschreiben. abstained=true bedeutet keine Grundlage – das ist korrekt, kein Fehler |
Nie ohne explizite Benutzeranfrage aufrufen: innate_approve, innate_archive, innate_invalidate, innate_restore, innate_mature_spark, innate_promote_spark, innate_drop_spark.
Rückschreibentscheidung
Vor dem Beenden einer langen Sitzung führe diese Checkliste still durch:
- Wurde eine nicht offensichtliche Lösung gefunden? (Workaround, versteckte Einschränkung, subtiles Fehlermuster)
- Wurde eine allgemeine, übertragbare Fähigkeit, Methode oder Technik aufgedeckt? (bevorzuge diese – abstrahiere projektspezifische Lektionen in wiederverwendbare Form; behalte eine projektspezifische Regel nur, wenn sie wirklich nicht generalisiert werden kann)
- Hat der Benutzer eine falsche Annahme von mir korrigiert, die ich wahrscheinlich wiederholen würde?
- Wurde eine schwer erkämpfte Erkenntnis nach mehreren fehlgeschlagenen Versuchen erreicht?
- Hat ein abgerufener Wissenschnipsel aktiv geholfen? (feedback_up aufzeichnen)
- Hat ein abgerufener Wissenschnipsel in die Irre geführt? (feedback_down aufzeichnen)
Wenn irgendetwas von 1–4 → schlage dem Benutzer vor:
„Diese Sitzung hat [Einzeiler-Beschreibung] hervorgebracht. Möchtest du, dass ich es in Innate speichere?“
Rufe innate_spark oder innate_add nur nach Benutzerbestätigung auf. Nie still schreiben.
Anti-Wortlaut-Regel
Roher Konversationstext darf niemals gespeichert werden. Destilliere immer zur wiederverwendbaren Prinzipienform:
<prinzip> — <auslösender Kontext> — <was vermieden werden sollte>
| ❌ Wortlaut | ✅ Destilliert |
|---|---|
| „Der Benutzer hat mir gesagt, ich solle den WAL-Modus verwenden, und ich habe es behoben, indem ich das Pragma geändert habe“ | „SQLite-WAL-Modus muss über PRAGMA-Antwort verifiziert werden, nicht angenommen – tritt bei jedem DB-Öffnen in schreibintensiven Multi-Prozess-Setups auf“ |
| „Wir haben 2 Stunden mit Debuggen von Auth wegen Clock-Skew verbracht“ | „JWT-Validierung muss Clock-Skew-Toleranz (≥30s) berücksichtigen – tritt bei verteiltem Auth zwischen Diensten mit unabhängigen Systemuhren auf“ |
Bevorzuge Allgemeines vor Projektspezifischem
Innate ist auf allgemeine, übertragbare Fähigkeiten, Methoden und Techniken ausgerichtet – Wissen, das sich projektübergreifend auszahlt, nicht nur in der aktuellen Codebasis. Wenn eine Lektion projektspezifisch ist:
- Versuche sie zu abstrahieren – entferne Repo-/Datei-/Funktions-/Pfadnamen und einmalige Bezeichner und formuliere sie als Prinzip um, das das nächste Projekt wiederverwenden kann.
- Speichere die abstrahierte Form. Behalte konkrete projektspezifische Details nur, wenn die Lektion ohne sie wirklich nicht generalisiert werden kann, ohne ihren Sinn zu verlieren.
| ❌ Projektgebunden | ✅ Generalisiert |
|---|---|
„In diesem Repo muss record() innerhalb von BEGIN IMMEDIATE laufen“ | „Mehrschrittige Zustandsmutationen, die atomar sein müssen, gehören in eine exklusive Transaktion, nicht in schrittweise Commits – gilt für jeden SQLite-Schreiber mit gleichzeitigen Prozessen“ |
„Setze recall.budget=4000 in der Meta-Tabelle“ | „Mache das Retrieval-Budget als einstellbaren Parameter verfügbar, anstatt es fest zu kodieren – ermöglicht Skalierung des Abrufs mit dem Kontextfenster ohne Codeänderungen“ |
Sparks vs. Notes
Verwende innate_spark | Verwende innate_add |
|---|---|
| Schnelle Idee, halb geformte Ahnung | Bestätigtes wiederverwendbares Prinzip |
| Noch nicht validiert | In dieser Sitzung validiert |
| Benutzer sagt „merke dir das für später“ | Benutzer sagt „merke dir diese Regel“ |
CLI-Fallback (falls MCP nicht konfiguriert)
# Abruf
innate recall "<kanonische_absicht>" --top 5 --format json --source cli
# Aufzeichnung mit strukturierter Zusammenfassung
innate record <trace_id> --outcome ok \
--used <id1>,<id2> \
--output-summary "X behoben, indem Y gemacht wurde – gilt wenn Z" \
--feedback up # oder down
# Erkenntnis erfassen
innate add "<prinzip> — <auslöser> — <was vermieden werden sollte>" \
--trigger "<2-5 Wort Kontext>" \
--source agent
# Schnelle Idee
innate spark "<destillierte idee in 1-2 sätzen>"
# Sitzungsende
innate evolve --trigger manual
innate inspect
Befehle
Schrägstrich-Befehle unten werden automatisch in ~/.claude/commands/ installiert von innate install und bei jeder erneuten Ausführung von innate install aktualisiert. Jeder command-Block definiert einen Befehl: Metadaten vor ---, Körper (der Agent-Prompt) nach ---.
name: innate-recall
description: Vorheriges Innate-Wissen für den aktuellen Aufgabenkontext abrufen
---
Führe innate_recall für den aktuellen Aufgabenkontext aus und füge das Ergebnis in dieses Gespräch ein.
Wenn der Benutzer eine Abfrage nach dem Befehl bereitgestellt hat, verwende diese genau als Abfrage für den Abruf.
Wenn keine Abfrage bereitgestellt wurde ($ARGUMENTS ist leer), leite die Abfrage aus der letzten Benutzernachricht oder der aktuellen Aufgabenabsicht ab – verwende die **kanonische Absicht** (z.B. `sqlite wal mode init`, nicht „warum stürzt das ab“). Halte die Abfrageform konsistent damit, wie du dieselbe Problemklasse in Zukunft formulieren würdest.
Schritte:
1. Formuliere die kanonische Abfragezeichenfolge (aus $ARGUMENTS oder abgeleiteter Absicht).
2. Rufe `innate_recall` auf mit `query=<abfrage>`, `budget=4000`, `source="mcp"`.
3. Wenn Wissen zurückgegeben wird: fasse in einem Satz zusammen, was gefunden wurde, füge dann die relevanten Wissenschnipsel in den Kontext ein.
4. Wenn leer: sage „Kein Vorwissen gefunden für: <abfrage>“ – erfinde nichts.
5. Speichere die `trace_id` zur späteren Verwendung in `/innate-record`.
name: innate-record
description: Den aktuellen Innate-Trace mit einem Ergebnis und einer strukturierten Zusammenfassung abschließen
---
Schließe den aktuellen Innate-Trace mit einem Ergebnis und einer Zusammenfassung ab.
Parse $ARGUMENTS nach:
- outcome: eines von `ok`, `fail`, `unknown` (Standard: `ok`, wenn nicht angegeben)
- Alle restlichen Texte werden zur output_summary-Überschreibung
Schritte:
1. Identifiziere die aktive trace_id aus dem letzten `innate_recall`-Aufruf dieser Sitzung.
Wenn keine trace_id verfügbar ist, sage „Kein aktiver Trace – führe zuerst /innate-recall aus.“
2. Bestimme, welche abgerufenen Chunk-IDs **tatsächlich verwendet** wurden in der endgültigen Antwort (nicht nur Kandidaten, die abgerufen wurden). Sei präzise – nicht verwendete abgerufene Chunks sollten NICHT aufgelistet werden.
3. Schreibe eine strukturierte output_summary für einen zukünftigen Agenten, der kalt liest:
Format: `<was getan wurde> — <wichtige Einschränkung/Methode> — <wann dies zutrifft>`
Wenn der Benutzer Zusammenfassungstext in $ARGUMENTS bereitgestellt hat, verwende diesen.
4. Bewerte Feedback:
- Wenn ein Chunk direkt hilfreich war → füge `feedback_up=[chunk_id]` hinzu
- Wenn ein Chunk falsch/irreführend war → füge `feedback_down=[chunk_id]` hinzu
5. Rufe `innate_record` auf mit `trace_id`, `outcome`, `used=[<chunk_ids>]`,
`output_summary` und gegebenenfalls Feedback.
6. Bestätige: „Trace <trace_id> als <outcome> aufgezeichnet.“
name: innate-save
description: Eine bestätigte Erkenntnis als ausstehenden Wissenschnipsel in Innate speichern
---
Speichere eine bestätigte Erkenntnis als ausstehenden Wissenschnipsel in Innate.
$ARGUMENTS ist der Erkenntnistext zum Speichern (erforderlich). Wenn leer, frage: „Welche Erkenntnis möchtest du speichern?“
Schritte:
1. Parse $ARGUMENTS als Inhalt der Erkenntnis.
2. Di
…
[gekürzt für Übersetzung]