User Intelligence

Workspace Intelligence bildet das Projekt ab. User Intelligence bildet den Menschen hinter der Arbeit ab.

Zwei Engineers im selben Repository erwarten nicht dasselbe von einem Agenten, und der Unterschied ist nicht kosmetisch. Es geht darum, wie viel der Agent selbst entscheiden soll, wann er innehalten und Optionen vorschlagen soll, statt direkt zu implementieren, wie viel Verifikation als ausreichend gilt und welchen Weg du wählst, wenn zwei Entwürfe beide vertretbar sind.

Das ist echtes Wissen, und ohne einen Ort, an dem es liegt, steckt es in den Korrekturen, die du in jeder neuen Session erneut eintippst.

Was sie abbildet

Präferenzen bei der Umsetzung

Ob du ein schrittweises Refactoring willst oder offen für einen Rewrite bist. Ob du vor einer Implementierung Optionen sehen möchtest oder lieber hättest, dass der Agent bei einer bestimmten Art von Änderung einfach loslegt. Wie viel Abstraktion du für angemessen hältst. Bei welchen Arten von Änderungen du vorher gefragt werden willst.

Entscheidungsmuster

Welche Abwägungen du typischerweise triffst. Performance gegen Wartbarkeit. Selbst bauen gegen Übernehmen. Wie streng du Abwärtskompatibilität handhabst. Was für dich zuerst zählt, wenn eine Produktentscheidung einer technischen im Weg steht.

Qualitätserwartungen

Wie viel Testing du erwartest. Wann du einen Benchmark statt eines Arguments willst. Wann Recherche genügt und wann sie zum Ersatz fürs Ausliefern geworden ist. Was du unter „fertig“ verstehst und welches Maß an Validierung dazugehört.

Zusammenarbeit

Wie eigenständig der Agent sein soll. Wann du eine Rückfrage erwartest. Wann du eine Auswahl erwartest. Wie dir Ergebnisse zurückgemeldet werden sollen und wie ausführlich die Erklärungen sein sollen.

Was sie nicht abbildet

Nicht, wer du bist. Keine demografischen Merkmale, keine Persönlichkeit, nichts, was über dich als Person abgeleitet wird. Die Einheit ist eine Arbeitspräferenz dazu, wie Softwarearbeit erledigt werden soll, und jede davon ist etwas, das du auch laut hättest sagen können.

Drei Arten von Aussagen werden grundsätzlich abgelehnt statt gespeichert:

• Alles Persönliche. Gesundheit, Religion, Politik, Sexualität, ethnische Herkunft, Finanzen und private Beziehungen liegen außerhalb dessen, was Pathrule speichert, egal worum es in dem Satz ging.
• Eine Regel, die sich als Präferenz ausgibt. Eine Präferenz ist ein Ratschlag an einen Agenten. Eine als Verbot formulierte Aussage („nie“, „darf nicht“, „verboten“) würde wie eine Projektanforderung wirken, die sie gar nicht sein darf, deshalb wird sie nicht gespeichert. Wenn etwas in einem Projekt wirklich niemals passieren darf, gehört es dort als Regel hin.
• Ein Fakt über ein Projekt. „In diesem Repository nutzen wir den gemeinsamen Config-Helper“ gilt für eine Codebasis, nicht für dich. Als deine Präferenz gespeichert, würde es dir in das Repository eines Kunden folgen, wo es falsch ist. Das ist Workspace-Wissen, und es bleibt im Workspace.

Wie sie lernt

Du bringst es ihr bei. Führe pathrule me teach mit dem Satz aus, den du sonst immer wieder in neue Sessions tippen würdest:

pathrule me teach "Show me options before implementing anything that changes a public API"

Das optionale lokale Modell liest den Satz auf deinem eigenen Rechner und macht daraus eine strukturierte Arbeitspräferenz. Was es daraus ableitet, muss sich in deinen eigenen Worten wiederfinden: Es darf dich nicht zu einer Präferenz umformulieren, die du nie geäußert hast. Kann es nicht auf das zeigen, was du geschrieben hast, wird nichts gespeichert, und die CLI sagt dir, warum.

What you teach
      |
Checked against your own words
      |
Refused, or stored as a preference
      |
Active, and delivered where it applies

Ein konkretes Beispiel: Wenn du immer wieder sinngemäß sagst „mach nicht aus jeder Implementierung ein Forschungsprojekt“, ist die nützliche Darstellung kein gespeichertes Zitat, sondern eine Arbeitspräferenz:

Prefer implementation once the primary correctness
questions are resolved.

Source:     you told Pathrule
Applies:    across workspaces

Zum Beibringen brauchst du einen Mac mit Apple Silicon und installiertem lokalem Modell. Alles andere auf dieser Seite, auch die Auslieferung, funktioniert ohne.

Wenn du deine Meinung änderst

Bringst du eine neue Präferenz bei, die einer früheren zur selben Art von Arbeit widerspricht, ersetzt die neue die alte. Die alte wird stillgelegt, nicht gelöscht, und verweist auf ihre Nachfolgerin, sodass die Frage „warum hat sich das geändert“ immer eine Antwort hat. Zwei Präferenzen zu unterschiedlichen Arten von Arbeit gelten einfach beide.

Wer „der Nutzer“ ist

Präferenzen werden über dich formuliert. Wenn du also über die Menschen sprichst, die das nutzen, was du baust, könnte die Formulierung sie stillschweigend zu dir machen. „Löse Probleme, ohne Nutzern Fehler anzuzeigen“ würde ein Agent als „zeig mir keine Fehler“ lesen, also genau das Gegenteil dessen, was du gemeint hast. Wenn es in deinen eigenen Worten um deine Nutzer ging, spricht die Präferenz weiterhin von „Endnutzern“.

Wo eine Präferenz gilt

User Intelligence gehört dir, nicht einem Repository. Wo eine einzelne Präferenz gilt, ist eine eigene Frage.

• Was du beibringst, gilt überall. Es wurde nicht aus einem Projekt gelernt, also wird es auch nicht in einem Projekt abgelegt.
• Du kannst eine Präferenz auf einen Workspace beschränken. pathrule me scope <id>, innerhalb eines Repositorys ausgeführt, beschränkt diese Präferenz auf den Workspace, in dem du den Befehl ausführst. Mit pathrule me scope <id> --everywhere gilt sie wieder in jedem Workspace.

Wie eine Präferenz einen Agenten erreicht

Vor jedem Turn wählt Pathrule die Präferenzen aus, die für die anstehende Arbeit gelten.

• Nur aktive. Eine Präferenz, die noch nicht in Gebrauch ist, wird von pathrule me list angezeigt, erreicht aber nie einen Agenten. Stillgelegte und abgelehnte werden ebenfalls nicht verwendet.
• Nur die, die für den Workspace gelten, wie oben beschrieben.
• Nur die, die zu dieser Aufgabe passen. Eine Präferenz dazu, wie mit dir zusammengearbeitet wird, gilt für jede Aufgabe. Eine Präferenz zu einer bestimmten Art von Arbeit, etwa Architektur oder Migrationen, erreicht einen Agenten nur, wenn es in der Aufgabe darum geht.
• Wenige pro Turn, die stärksten zuerst. Gelten mehr, fallen die schwächsten weg.
• Jede gibt an, woher sie stammt, damit ein Agent „du hast das gesagt“ als genau das gewichten kann.

Sie kommen über den Prompt-Hook an, jede einmal pro Session, unter einer Überschrift, die dem Agenten mitteilt, dass die Regeln und Pflichtprüfungen des Workspace Vorrang haben. Derzeit betrifft das Sessions in Claude Code und Codex. Cursor und GitHub Copilot haben Session- und Tool-Hooks, aber keinen Prompt-Hook, und Windsurf hat gar keine Hooks, deshalb erreichen Präferenzen sie nicht. Siehe So funktionieren Hooks.

Autorität: wenn du und das Projekt unterschiedlicher Meinung seid

Eine Nutzerpräferenz setzt die Projektwahrheit nicht außer Kraft.

User Intelligence
Prefer minimal testing.

Workspace Intelligence
Rule: run migration verification before completion.

Die Regel gilt. Sie ist eine Anforderung des Workspace, und eine Präferenz für weniger Verifikation ist kein Grund, sie fallen zu lassen.

Der allgemeine Grundsatz, und den sollte man klar aussprechen:

• Workspace Intelligence steht für Projektwahrheit und Projektanforderungen. Ihre Regeln und Pflichtprüfungen sind harte Anforderungen.
• User Intelligence prägt die Zusammenarbeit: wie die Arbeit angegangen wird, wie viel eigenständig erledigt wird, wie zurückgemeldet wird. Sie definiert nicht neu, was korrekt bedeutet.

Wo es bei beiden nur um Stil geht, gilt deine Präferenz. Wo der Workspace eine Sicherheits- oder Korrektheitsanforderung festlegt, bleibt diese bestehen.

Das gilt auch ohne Workspace-Regel. Eine Präferenz, die weniger Verifikation bedeuten könnte, wird immer dann zurückgehalten, wenn die Arbeit Authentifizierung, Zahlungen, Datenmigrationen, Kryptografie oder Sicherheit berührt. Fehler sind dort unauffällig und teuer, und eine Präferenz, die bei alltäglichem Code entstanden ist, sagt nichts darüber aus, ob sie dort sicher ist.

Was du steuerst

Alles. User Intelligence ist einsehbar statt implizit. Für jede Präferenz siehst du:

• Ihren Status: candidate, active, retired oder rejected.
• Woher sie stammt und wie sicher sie ist.
• Wo sie gilt: in allen Workspaces oder nur in einem.
• Warum: die Worte, auf die sie sich stützt, mit Datum.

Und du kannst:

• Eine Präferenz direkt beibringen.
• Eine vergessen lassen. Sie wird nicht mehr verwendet und bleibt als abgelehnt gespeichert, damit dieselbe Aussage sie nicht sofort zurückbringt. Mit --delete entfernst du sie vollständig.
• Eine auf diesen Workspace beschränken oder überall gelten lassen.
• Prüfen, was ein Agent für eine Aufgabe erhalten würde, bevor du sie startest.

Eine Ableitung, die du nie zu sehen bekommst, kannst du auch nicht anfechten. Deshalb ist jede Präferenz nur einen Befehl entfernt.

Über die Kommandozeile

pathrule me list                    # what is in use, and what is not yet
pathrule me teach "I prefer incremental refactors"
pathrule me explain <id>            # the evidence behind one preference
pathrule me scope <id>              # keep it to the workspace you run this in
pathrule me scope <id> --everywhere # let it apply in every workspace
pathrule me forget <id>             # stop using it
pathrule me forget <id> --delete    # remove it entirely
pathrule me context "add a payments webhook"

pathrule me context gibt genau das aus, was ein Agent für diese Aufgabe erhalten würde, und zeigt, welche Präferenzen zurückgehalten wurden und warum. So prüfst du am schnellsten, ob eine Präferenz die Arbeit erreicht, für die du sie gedacht hast, und nur diese. Jeder Unterbefehl akzeptiert --json.

Wechsel zwischen Projekten

Öffnest du ein anderes Repository, ändert sich das Projektwissen um dich herum vollständig. Die Präferenzen, die du beigebracht hast, kommen mit, sofern du keine davon auf einen einzelnen Workspace beschränkt hast.

Genau dort treffen beide in einem Turn zusammen: Der Workspace steuert bei, was hier gilt und gefordert ist, du steuerst bei, wie die Arbeit erledigt werden soll, und die Auslieferung stellt die Anforderungen des Projekts über deine Präferenzen. Siehe Agent IR.

Einschränkungen, die du kennen solltest

• Der Abgleich erfolgt über Wörter, nicht über Bedeutung. Eine Präferenz erreicht eine Aufgabe, die Begriffe mit ihr teilt. Ist sie ganz anders formuliert als die Aufgabe, kann sie diese verfehlen.
• Zum Beibringen braucht es das lokale Modell, und das läuft nur auf Macs mit Apple Silicon.
• Präferenzen erreichen nur Clients mit Prompt-Hook: Claude Code und Codex.
• Im Zweifel verzichtet sie, statt zu raten. Ein Satz, den sie nicht in deinen eigenen Worten verankern kann, wird nicht gespeichert. Eine fehlende Präferenz kostet dich einen weiteren Satz. Eine erfundene würde dich gegenüber jedem Agenten, mit dem du arbeitest, falsch darstellen.

Datenschutz

Die Ableitung, die aus dem Beigebrachten eine strukturierte Präferenz macht, läuft auf deinem eigenen Gerät, und deine Präferenzen liegen in einem privaten Speicher auf deinem Rechner.

Wenn du einen Workspace mit einem Team teilst, wird das Wissen des Workspace synchronisiert, nicht deine persönlichen Arbeitspräferenzen. Und wenn du Claude Code, Codex oder einen anderen Agenten nutzt, gelten für alles, was diesen erreicht, die Grenzen des jeweiligen Anbieters. Die Sicherheitsseite hält diese Grenzen auseinander, denn wer sie in einen einzigen Satz zusammenfasst, macht genau damit eine Aussage unwahr.

Weiterlesen

• Workspace Intelligence: was das Projekt beisteuert und warum seine Anforderungen Vorrang haben.
• Das lokale Modell: was auf deinem Gerät läuft und wie du es installierst.
• CLI-Befehlsreferenz: alle pathrule me-Unterbefehle neben dem Rest der CLI.