Regeln schreiben

Eine Regel ist eine Vorgabe, die der Assistent innerhalb eines Geltungsbereichs befolgen muss. Regeln sind die stärkste Form von Inhalten in Pathrule: Sie kommen als Anforderung an, nicht als Hintergrundinformation, und eine Regel mit einer freigegebenen ausführbaren Einschränkung kann eine passende Änderung stoppen, bevor sie wirksam wird.

Diese Seite erklärt, wann du eine Regel schreibst, wie du Geltungsbereich und Priorität wählst, was Durchsetzung bedeutet und welche Muster du vermeiden solltest.

Wann du eine Regel schreibst

Greif zu einer Regel, wenn der Assistent in einem bestimmten Teil der Codebasis etwas niemals tun darf oder etwas immer tun muss.

• „Verwende den Service-Role-Key niemals in Browser-Code.“
• „Alle Geldbeträge werden als Ganzzahlen in Cent gespeichert. Niemals Floats verwenden.“
• „Migrationen müssen vor der zugehörigen Codeänderung laufen. Ohne Ausnahme.“
• „JSX-Dateien in apps/web verwenden ausschließlich Tailwind-Klassen. Keine CSS-Module, keine Inline-Styles.“

Lautet die Antwort „kommt auf die Situation an, der Assistent sollte darüber nachdenken“, dann ist das eine Memory, keine Regel. Regeln sind für Dinge, über die nicht verhandelt wird.

Geltungsbereichstypen

Jede Regel hat einen Geltungsbereichstyp, der festlegt, für welche Pfade oder Dateien sie gilt.

• folder. Gilt für einen Verzeichnisteilbaum. Am besten für bereichsspezifische Regeln: alles unter apps/api/auth, alles unter services/billing.
• file_type. Gilt für Dateien, die auf ein Glob-Muster wie *.tsx oder **/*.test.ts passen. Am besten für übergreifende Anliegen, die an eine Dateiart gebunden sind, nicht an ein Verzeichnis.
• project. Gilt überall im Workspace. Sparsam einsetzen. Eine Projektregel fährt bei jedem Prompt mit.

Geltungsbereich und Knotenpfad, an dem die Regel hängt, bestimmen zusammen, was der Assistent sieht. Eine folder-Regel an /apps/web gilt für alles unter apps/web.

Prioritätsstufen

Die Priorität bestimmt, wie offensiv die Regel in Erscheinung tritt. Innerhalb eines passenden Geltungsbereichs werden Regeln mit höherer Priorität zuerst berücksichtigt.

• high. Für Dinge, deren Verletzung Bugs, Sicherheitsregressionen oder Compliance-Probleme verursacht.
• medium. Der Standard. Für „fast immer, aber nicht tragend“.
• low. Stilistisch. Erscheint, wenn Platz ist und das Thema passt. Für Geschmack und Konventionen.

Hohe Priorität ist ein Budget. Wenn die Hälfte deiner Regeln hohe Priorität hat, hat keine sie wirklich. Wähl die aus, die tatsächlich nicht verletzt werden dürfen.

Durchsetzung: advisory und strict

Die Durchsetzung ist eine eigene Einstellung, unabhängig von der Priorität. Die Priorität bestimmt, wie stark eine Regel hervortritt; die Durchsetzung legt fest, was bei einem Verstoß passiert.

• advisory. Die Regel ist Kontext. Der Assistent wägt sie ab und entscheidet, wie er sie anwendet. Regeln, die du über die CLI oder VS Code schreibst, und Regeln, die ein Assistent schreibt, sind advisory.
• strict. Eine Regel wird strict, wenn sie eine ausführbare Einschränkung trägt, die eine Person freigegeben hat: die exakte verbotene Form, etwa ein Import, ein Bezeichner oder ein Ort. Der Pre-Tool-Hook kann dann eine Dateibearbeitung oder einen Schreibvorgang, der darauf passt, blockieren, bevor die Änderung wirksam wird, und gibt die Regel samt Abhilfe als Begründung zurück. Ein Assistent kann beim Schreiben oder Aktualisieren einer Regel (pathrule_write_rule, pathrule_update_rule) eine vorgeschlagene Einschränkung anhängen, doch ein Vorschlag wird als Vorschlag gespeichert und blockiert nichts, bis eine Person ihn freigibt; einen eigenen Vorschlag kann ein Assistent niemals freigeben. Siehe Regeln als Leitplanken.

Wer eine Regel umformuliert, hält die Durchsetzung ehrlich. Eine freigegebene Einschränkung ist an den Satz der Regel gebunden, anhand dessen sie geprüft wurde. Formulierst du die Regel um und dieser Satz verschwindet, hört die Einschränkung von selbst auf zu greifen. So blockiert eine Regel nie weiter aus einem Grund, den sie gar nicht mehr nennt. Änderst du andere Teile der Regel oder ergänzt einen Absatz, bleibt eine unberührte Einschränkung scharf.

Ob blockiert wird, hängt vom Client ab. Pathrule CLI installiert Tool-Hooks für Claude Code, Codex, Cursor und GitHub Copilot, und eine Blockade greift dort, wo der Pre-Tool-Hook des Clients die Entscheidung respektiert. Windsurf hat keine Hooks, und Remote MCP installiert keine, dort kommen Regeln also nur als Kontext an. Die bloße Auslieferung setzt nichts durch.

Aufbau

Eine Regel hat einen Namen und einen Inhalt. Formulier den Inhalt im Imperativ und halte ihn kurz.

Name: No service role key in browser code

Body:
- Never import SUPABASE_SERVICE_ROLE_KEY in any file under apps/web.
- Use the anon key plus row level security.
- If you need server only access, do it from apps/api or a server action.

Im Terminal ist dieselbe Regel ein einziger Befehl. Ohne --body öffnet die CLI deinen Editor für den Inhalt.

pathrule rule add --path /apps/web --name "No service role key in browser code" --priority high --scope folder

In VS Code nutzt du New Rule…, und ein Assistent schreibt Regeln mit pathrule_write_rule.

In der Praxis bewährt sich am besten eine Vorgabe pro Regel mit einem kurzen Inhalt in Stichpunkten. Lange Regeln in Fließtext werden von Menschen wie Assistenten nur überflogen.

Wiederverwenden statt duplizieren

Eine Regel liegt an genau einem Pfad und gilt für alles darunter, eine Regel reicht also für einen ganzen Teilbaum. Gilt dieselbe Vorgabe für zwei weit auseinanderliegende Ordner, leg sie an ihren nächsten gemeinsamen Pfad oder nutze einen file_type-Geltungsbereich mit Glob-Muster, statt den Text in zwei Regeln zu kopieren. Eine Regel bedeutet eine Änderung, wenn sich die Vorgabe ändert.

Pathrule hilft dabei: Eine neue Regel, deren Name einer bestehenden Regel im Workspace entspricht, wird standardmäßig abgelehnt, und der Schreibvorgang nennt dir die bereits vorhandene Regel. Nachdem du die bestehende Regel geprüft hast, kannst du das bewusst übersteuern (allow_duplicate über MCP). Um eine Regel umzuziehen, verschieb sie an einen anderen Pfad (Move… in VS Code oder pathrule_update_rule mit move_to_path).

Versionierung und gleichzeitige Bearbeitung

Regeln tragen wie Memories ein Versions-Token. Bearbeiten zwei Teammitglieder dieselbe Regel gleichzeitig, entsteht ein sauberer Konflikt, statt dass einer den anderen überschreibt. In VS Code bietet der Konflikt dieselben Optionen wie bei einer Memory: Reload, Copy My Version & Reload oder Keep Mine (Overwrite).

Wie Regeln beim Assistenten ankommen

• Regeln in einem passenden Geltungsbereich werden nach Priorität und nach ihrer Relevanz für die Aufgabe priorisiert. Die relevantesten kommen vollständig an; die übrigen werden mit Namen genannt, damit der Assistent weiß, dass es sie gibt, und eine davon mit pathrule_read_rule vollständig lesen kann.
• Eine strict-Regel kommt dort, wo sie gilt, immer vollständig an, denn ein Name allein kann eine Blockade nicht erklären.
• Regeln werden außerdem in die Anweisungsdateien kompiliert, die deine Clients lesen (zum Beispiel CLAUDE.md für Claude Code und AGENTS.md für Codex), sodass auch ein Client ohne Prompt-Hook mit ihnen startet.

Ob eine Regel eine Änderung blockieren kann, statt den Assistenten nur zu informieren, legt ihr Durchsetzungsmodus fest (advisory oder strict), nicht ihre Priorität.

Anti-Patterns

• Hohe Priorität für alles. Wähl die Regeln aus, die wirklich zählen. Der Rest sollte medium sein.
• Regeln, die wie Memories klingen. „Wir bevorzugen eher X“ ist eine Memory. „Tu niemals Y“ ist eine Regel.
• Regeln, die sich überschneiden. Zwei Regeln mit hoher Priorität und widersprüchlicher Formulierung sind schlimmer als eine klare Regel.
• Projekt-Geltungsbereich als Standard. Die meisten Regeln gehören unter einen Ordner. Zieh eine Regel nur dann auf project hoch, wenn sie wirklich überall gilt.

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

• Memories schreiben für Fakten und Entscheidungen, die keine Vorgaben sind.
• Skills schreiben für wiederverwendbare Abläufe, die der Assistent aufrufen kann.
• So funktionieren Hooks dazu, wie die Laufzeit entscheidet, welche Regeln erscheinen.