Memories schreiben

Eine Memory ist eine kurze Markdown-Notiz, die dein Team aufschreibt, damit der Assistent sie später lesen kann. Memories liegen an einem Workspace-Pfad und tauchen nur auf, wenn der Assistent unterhalb dieses Pfads arbeitet. Sie sind der häufigste Inhaltstyp in Pathrule und der einfachste Einstieg.

Diese Seite erklärt, wann du eine Memory schreibst, wie du sie aufbaust und wie Pfadbezug und Versionierung funktionieren.

Wann du eine Memory schreibst

Greif zu einer Memory, wenn du Wissen hast, das sich nicht von selbst aus dem Code ergibt und vermutlich wieder relevant wird.

• Entscheidungen. „Wir nutzen in diesem Repository für alles Postgres auf Supabase. Kein ORM einführen. Den supabase-js-Client direkt verwenden.“
• Stolperfallen. „Wenn du das Enum orders.status änderst, musst du die Datenmigration vor der Schemamigration ausführen. Die Reihenfolge ist umgekehrt zum restlichen Schema.“
• Postmortems. „Am 2026-04-12 haben wir einen Webhook-Handler ausgeliefert, der Kunden doppelt belastet hat, weil wir den Idempotency-Key von Stripe nicht geprüft haben. Ihn ab jetzt immer mitgeben.“
• Konventionen. „Tests liegen neben der Datei, die sie testen, nicht in einem parallelen Verzeichnis __tests__.“
• Stammeswissen. „Nur noch eine Person weiß, warum es dieses Flag gibt. Es ist wegen einer Laufzeit-Eigenheit im Upstream weiterhin nötig.“

Verzichte auf Memories für Dinge, die der Code schon klar sagt, für Dinge, die sich wöchentlich ändern, und für reine persönliche Vorlieben.

Aufbau

Jede Memory hat einen Titel und einen Markdown-Text. Halte beides klein.

• Titel: kurz, als Aussage formuliert, passt in eine Seitenleiste. „Nur Postgres. Kein ORM.“ ist besser als „Notizen zu Datenbankzugriffsmustern“.
• Text: so wenig Markdown wie nötig, um den Punkt zu machen. Aufzählungen sind meist klarer als Absätze. Füg ein Beispiel hinzu, wenn es hilft.

Eine Pflichtvorlage gibt es nicht, aber ein brauchbarer Standard ist:

The constraint or fact in one sentence.

Why:
- The reason this matters or the incident that prompted it.

How to apply:
- The concrete thing the assistant should do when the topic comes up.

Pfadbezug

Der Pfad ist die halbe Memory. Er entscheidet, wo sie auftaucht.

• Eine Memory unter /apps/api/payments taucht bei jeder Arbeit unterhalb von apps/api/payments auf.
• Eine Memory unter /apps/api taucht für das gesamte api-Verzeichnis auf.
• Eine Memory unter / taucht überall im Workspace auf.

Wähl den spezifischsten Pfad, der die gewünschten Fälle noch abdeckt. Eine Memory über Zahlungen auf Workspace-Ebene ist bloß Rauschen und schlechter als eine Memory im Payments-Ordner.

Versionierung und gleichzeitige Änderungen

Jedes Speichern wird gegen die Version geprüft, von der du ausgegangen bist. Hat zwischendurch jemand anderes gespeichert, wird dein Speichern abgelehnt, statt dessen Änderung zu überschreiben. So verhindert Pathrule, dass zwei Personen oder eine Person und ein Agent sich stillschweigend gegenseitig überschreiben.

• In Pathrule für VS Code ist eine Memory ein Markdown-Tab. Würde ein Speichern eine neuere Änderung aus deinem Team überschreiben, bekommst du Reload, Copy My Version & Reload (dein Text landet vorher in der Zwischenablage) oder Keep Mine (Overwrite) angeboten.
• Über MCP kann der Assistent die zuletzt gelesene Version mitgeben. Passt sie nicht, bekommt er einen Konflikt mit der aktuellen Version zurück, liest neu und führt die Änderungen zusammen, statt zu überschreiben.

Auch das Löschen ist umkehrbar. In VS Code bietet ein Löschvorgang sofort Undo an, und in einem Pathrule Cloud-Workspace bleibt eine gelöschte Memory im Workspace-Archiv, bis sie endgültig gelöscht wird. Dort kann ein Owner oder Admin sie in den Einstellungen der Webkonsole (Workspace, Archive) wiederherstellen oder endgültig löschen. In der Praxis sind Konflikte selten, weil Memories meist klein und fokussiert sind, aber das Sicherheitsnetz ist immer aktiv.

Wer sie schreibt

• Menschen, die in Pathrule für VS Code (New Memory… oder Save Selection as Memory) oder mit der CLI schreiben.
• Der Assistent, der über das MCP-Tool pathrule_write_memory schreibt, wenn du ihn bittest, etwas zu speichern. Beim Einrichten schlägt er Memories, Regeln und Skills für das Projekt vor und schreibt nur die Einträge, die du freigibst.

Im Terminal ist eine Memory ein einziger Befehl. Ohne --body öffnet die CLI deinen Editor für den Text; du kannst aber auch --body übergeben oder den Text per Pipe hineinreichen. Mit pathrule memory list und pathrule memory read "Exact title" --print liest du Memories wieder aus.

pathrule memory add --path /apps/api/payments --title "Always pass the Stripe idempotency key"

Beide Quellen landen am selben Ort. Der Assistent liest, was ein Mensch geschrieben hat, und ein Mensch liest, was der Assistent geschrieben hat. Jeder Eintrag hält fest, wer ihn erstellt und wer ihn zuletzt bearbeitet hat und woher er stammt. Das zeigt die Aktion Info in VS Code an, sodass von der KI verfasste Memories leicht zu erkennen sind.

Wie die Qualität der Memories prüfbar bleibt

Pathrule hält eine Memory durch mehrere unabhängige Mechanismen eng gefasst und nachvollziehbar:

• Allgemeine Dokumentation wird beim Einrichten angeboten, nicht automatisch importiert. Aktive Anweisungsdateien, ihre Importkette, Tool-Regeln und Entscheidungsprotokolle sind stärkere Belege dafür, dass es sich um aktives Wissen handelt.
• Ein Agent soll dauerhaftes Wissen erst vorschlagen, bevor er es speichert. Was er dann speichert, ist zugeordnet, versioniert und im Workspace sichtbar wie alles andere, sodass du es öffnen, bearbeiten oder entfernen kannst.
• Der Pfadbezug begrenzt, wo ein Eintrag auftauchen kann, und ein Eintrag außerhalb des aktuellen Pfads muss zusätzlich die Relevanzschwelle überwinden.
• Die gemessene Nutzung kann die Reihenfolge qualifizierter Einträge ändern, aber keine themenfremde Memory über diese Schwelle heben.
• Bemerkt ein Agent, dass eine Memory nicht mehr zum Code passt, kann er sie als Refresh-Aufgabe markieren, die ein Assistent später unter deiner Kontrolle aufgreift und behebt. Siehe Vorschläge und Selbstprüfung. Änderungen sind versioniert und Löschen ist umkehrbar.
• Eine neue Memory, deren Titel mit einer bestehenden am selben Pfad übereinstimmt, wird standardmäßig abgelehnt, statt als zweite Kopie gespeichert zu werden. So wird dieselbe Entscheidung nicht doppelt ausgeliefert und driftet nicht auseinander. Nachdem du den bestehenden Eintrag geprüft hast, kannst du das bewusst übersteuern (--allow-duplicate im CLI).

Das Ergebnis ist eine kleine Menge eng gefasster, prüfbarer Entscheidungen und Stolperfallen, kein großes Archiv, das in den Workspace kopiert wurde. Den vollständigen technischen Vertrag findest du unter Wie Pathrule harte Aussagen belegt.

Lesen statt Zitieren

Die relevantesten Memories kommen als vollständiger Text an, mit dem der Assistent direkt arbeiten kann. Weniger sichere Kandidaten kommen als Titel mit IDs; der Assistent liest einen davon mit pathrule_read_memory vollständig, bevor er sich darauf stützt. So bleibt unsicheres Material aus der Standard-Payload heraus, ohne dass starke Treffer zusätzliche Round Trips kosten.

In VS Code zeigt Browse Knowledge Here…, was eine KI-Session an einem Pfad erhält, einschließlich dessen, was sie von übergeordneten Pfaden erbt.

Anti-Patterns

• Eine riesige Memory mit „all meinen Notizen“. Teil sie nach Thema und Pfad auf. Klein und pfadbezogen schlägt lang und global jedes Mal.
• Memories, die sagen, was der Code schon sagt. Der Assistent kann den Code lesen. Heb dir Memories für das Warum und die Stolperfalle auf.
• Veraltete Memories. Aktualisiere oder lösch sie, wenn sich die zugrunde liegende Entscheidung ändert. Ein Assistent kann eine veraltete Memory als Refresh-Aufgabe markieren, aber ein menschlicher Blick ist schneller.

Erstellen im lokalen Modus und in der Cloud

Die add-Beispiele für das Terminal auf dieser Seite gelten für einen Cloud-Workspace. Im lokalen Modus erstellst und bearbeitest du Einträge in der Local Console, in VS Code oder über lokales MCP; die Wissensbefehle der CLI listen, lesen und durchsuchen sie.

Weiterlesen

• Regeln schreiben für Vorgaben mit Priorität.
• Skills schreiben für wiederverwendbare Abläufe.
• Kernkonzepte für den Workspace-Baum, an dem all das hängt.