Zum Inhalt springen
Pathrule

doku

GitHub Copilot

Wie Pathrule CLI GitHub Copilot über den Agent-Modus in VS Code, die Copilot CLI und den Coding-Agent per Instructions, Hooks, MCP und Skills anbindet.

Auf dieser Seite

GitHub Copilot verbindet sich über Pathrule CLI oder die VS Code-Erweiterung mit deinem Pathrule-Workspace. Copilot erhält eingegrenztes Workspace-Wissen über Session- und Tool-Hooks, Instruction-Dateien und den lokalen MCP-Server. Copilot hat keinen Prompt-Submit-Hook, daher kommt der Kontext beim Start der Session und rund um Tool-Aufrufe an, nicht mit jedem Prompt. Ein Remote-MCP-Setup ist für Copilot nicht dokumentiert. Copilot ist ein Sonderfall, weil ein einziger Dateisatz auf Repository-Ebene gleich drei Oberflächen versorgt: den Agent-Modus in VS Code, die Copilot CLI und den Coding-Agent.

Diese Seite beschreibt, was Pathrule für Copilot schreibt, worin sich die Oberflächen unterscheiden, wie die Hook-Events zugeordnet sind und wie du die Integration prüfst.

Was Pathrule schreibt

Wenn du Copilot aktivierst, schreibt Pathrule in die Pfade, die Copilot ohnehin verwendet, statt neue zu erfinden. Alle Dateien liegen unter .github/, wo Copilot bereits nachsieht.

DateiFunktion
.github/copilot-instructions.mdWird im Agent-Modus und in der CLI automatisch angewendet. Mit installiertem Hook ein kurzer Pathrule-Hinweis plus die Copilot-Vorgabe, pathrule_get_context aufzurufen; ohne Hook der vollständige Text des Pathrule-Protokolls.
.github/instructions/pathrule.instructions.mdEin per applyTo eingegrenzter Verweis, der das Protokoll auch dann präsent hält, wenn das Matching der Instructions über Globs läuft.
.github/hooks/pathrule.jsonDie Hook-Konfiguration. Das ist der eine Hook-Speicherort, den alle drei Copilot-Oberflächen lesen.
.github/skills/<slug>/SKILL.mdDie Skills deines Workspace, damit Copilot sie über ihren Namen aufrufen kann.

Ist der Copilot-Hook installiert, kommt das Protokoll über den sessionStart-Hook statt über die Instructions-Datei, und das Pfadwissen kommt über die Hooks, sodass keine Wissensdateien in deinem Verzeichnisbaum landen. Ohne Hook schreibt Pathrule zusätzlich für jedes Verzeichnis, an dem Wissen hängt, eine per applyTo eingegrenzte Datei .github/instructions/pathrule-k-*.instructions.md.

Bei Skills gibt es eine Besonderheit. Copilot liest auch .claude/skills. Wenn du im selben Workspace sowohl Claude Code als auch Copilot aktiviert hast, überspringt Pathrule .github/skills, damit Copilot nicht jeden Skill doppelt sieht. Mit beiden Clients aktiv entstehen also weder doppelte Skills noch ein doppeltes Protokoll im Kontext von Copilot.

So prüfst du, was angekommen ist:

cat .github/copilot-instructions.md
cat .github/hooks/pathrule.json

Drei Oberflächen, ein Dateisatz

Dieselben Dateien unter .github/ aktivieren jede Copilot-Oberfläche, doch die Oberflächen unterscheiden sich darin, wie Hooks und MCP sie erreichen.

OberflächeHooksSpeicherort der MCP-Konfiguration
Agent-Modus in VS CodeLiest .github/hooks; liest außerdem .claude/settings.json, falls vorhandenmcp.json auf Benutzerebene oder im Editor registriert durch die Pathrule VS Code-Erweiterung
Copilot CLILiest .github/hooks~/.copilot/mcp-config.json
Coding-Agent (auf github.com)Liest .github/hooks aus dem committeten RepositoryRepository-Einstellungen auf github.com, von dir konfiguriert (nicht dateibasiert verwaltet)

Bei VS Code lautet der Wurzelschlüssel der MCP-Konfiguration servers, nicht mcpServers. Wenn du die Pathrule VS Code-Erweiterung nutzt, wird der Copilot-Agent-Modus für dich im Editor registriert, ohne dass du eine MCP-Datei von Hand bearbeiten musst.

Der Coding-Agent ist die einzige Oberfläche, die Pathrule nicht über das Dateisystem anbinden kann. Er arbeitet mit dem, was im Repository committet ist, und seine MCP-Server werden in den Repository-Einstellungen auf github.com festgelegt, außerhalb jeder Datei, die Pathrule verwaltet. Deshalb konfiguriert Pathrule MCP für ihn nicht. Damit er die Instructions und Skills bekommt, committest du die Dateien unter .github/. Hat dein Workspace eine .gitignore, stehen die materialisierten Skills dort in einem Pathrule-Abschnitt; lösche diese Zeilen, um sie zu committen. Die Hook-Konfiguration ruft den Pathrule-Hook auf, der auf dem Rechner installiert ist, auf dem sie geschrieben wurde. Kontext zur Hook-Zeit und Blockieren greifen daher dort, wo Pathrule installiert ist: im Agent-Modus von VS Code und in der Copilot CLI.

Abdeckung der Hook-Events

Die Hook-Events von Copilot entsprechen denselben Einspeisepunkten, die Pathrule bei Cursor und Claude Code nutzt.

  • sessionStart. Beim Start einer Session. Pathrule liefert die Workspace-Metadaten, das Protokoll und deinen Team-Kontext, also den Bootstrap, den Claude Code beim Start seiner Session erhält.
  • postToolUse. Nachdem ein Tool fertig ist. Pathrule liefert den pfadbezogenen Kontext zu dem, was der Agent gerade angefasst hat, und erfasst die Aktivität.
  • preToolUse. Bevor ein Tool läuft. Hier lehnt eine Regel mit freigegebenem Blockiermuster eine passende Änderung ab, bevor sie geschrieben wird, und nennt als Begründung die Regel und die freigegebene Abhilfe. Im Agent-Modus von VS Code kann dieses Event auch den pfadbezogenen Kontext transportieren; die Copilot CLI nimmt Kontext nur bei sessionStart und postToolUse an.
  • agentStop, subagentStop und sessionEnd. Schließen den Turn und die Session ab.

Das Event pro Prompt ist bewusst nicht angebunden. Die Ausgabe von Copilot für dieses Event transportiert keinen zusätzlichen Kontext, ein Matching darauf würde also pro Prompt einen Prozess kosten, ohne etwas einzuspeisen. SessionStart und PostToolUse decken dasselbe ab. Das Ergebnis entspricht dem Einspeiseprofil von Cursor.

Ein einziges gemeinsames Hook-Skript bedient alle Clients. Es erkennt die Payload-Struktur von Copilot, normalisiert sie in eine kanonische Form, führt dieselbe Auswahl von Regeln und Memories aus wie für jeden anderen Client und schreibt das Ergebnis im Schema von Copilot zurück. Nichts davon musst du pro Oberfläche konfigurieren. Das Skript ist von Grund auf fail-open: Ein unbekannter oder fehlerhafter Payload gibt nichts zurück, statt deine Copilot-Session zu unterbrechen.

Installation

Über Pathrule CLI:

pathrule setup

Führe den Befehl im Projektordner aus und wähle GitHub Copilot, wenn nach deinen KI-Tools gefragt wird. Das Setup meldet dich bei Bedarf bei Pathrule Cloud an, verknüpft den Ordner mit einem Workspace, installiert die MCP-Einträge, merkt sich deine Auswahl für diesen Ordner und schreibt die Dateien unter .github/. Mit pathrule setup --local nutzt du Pathrule stattdessen ohne Konto.

So richtest du die einzelnen Teile in einem bereits verknüpften Ordner von Hand ein:

pathrule install copilot
pathrule sync
pathrule doctor

pathrule install copilot trägt den Pathrule-Server in beide MCP-Konfigurationen ein, ~/.copilot/mcp-config.json für die Copilot CLI und die Benutzer-mcp.json von VS Code, und lässt alle anderen Server in diesen Dateien unangetastet. pathrule sync schreibt die Projektdateien für die KI-Tools, die für diesen Ordner gewählt wurden, oder für die im Ordner erkannten, falls keine gewählt wurden.

In der Pathrule VS Code-Erweiterung wählst du GitHub Copilot unter Connect AI Clients. Die Erweiterung registriert den Copilot-Agent-Modus im Editor und schreibt die Instruction-Dateien und die Hook-Konfiguration für dich.

Prüfen

Öffne einen Workspace, den du mit Pathrule verknüpft hast, und starte eine Copilot-Session auf der Oberfläche, die du nutzt.

  • Agent-Modus in VS Code oder Copilot CLI. Starte einen neuen Chat. Der pfadbezogene Kontext sollte vor dem ersten Tool-Aufruf ankommen. Bearbeite eine Datei unter einem Pfad mit hinterlegtem Wissen und achte darauf, wie die passenden Regeln und Memories auftauchen.
  • Coding-Agent. Sobald die Dateien unter .github/ committet sind, liest der Coding-Agent Instructions und Skills aus dem Repository. Füge in den Repository-Einstellungen auf github.com einen MCP-Server hinzu, wenn er Tools aufrufen soll.

Falls die Integration stumm bleibt:

pathrule doctor

Der Doctor arbeitet rein lesend. Er meldet deine Anmeldung, den Workspace und ob dieser Ordner verknüpft ist, führt Copilot doppelt auf, einmal für die Konfiguration der Copilot CLI und einmal für die mcp.json von VS Code, damit eine halb installierte Einrichtung auffällt, und zeigt, welche von Pathrule verwalteten Dateien im Ordner liegen und wer sie geschrieben hat. Mit --json bekommst du den vollständigen Bericht, der jeden Konfigurationspfad nennt und außerdem einen MCP-Eintrag markiert, der auf eine nicht mehr vorhandene Runtime zeigt. Das behebst du mit:

pathrule repair

Repair schreibt veraltete Pathrule-MCP-Einträge neu, lässt deine anderen Server unangetastet, synchronisiert die Projektdateien erneut und führt den Doctor noch einmal aus. pathrule uninstall copilot entfernt den Pathrule-Eintrag aus beiden MCP-Konfigurationen, und wenn du Copilot für den Ordner deaktivierst, werden alle Dateien entfernt, die Pathrule dafür verwaltet.

Was gleich bleibt

Alles, was du in Pathrule schreibst, erreicht Copilot in derselben Form wie Claude Code und Cursor.

  • Eine Memory, die du mit der CLI, der VS Code-Erweiterung oder über MCP schreibst, erscheint in Copilot.
  • Eine Regel mit freigegebenem Blockiermuster blockiert eine passende Änderung in Copilot.
  • Ein Skill lässt sich in Copilot über seinen Namen aufrufen.
  • Die MCP-Tools (pathrule_get_context, pathrule_write_memory und die übrigen) verhalten sich identisch.

Du schreibst Wissen einmal, und jeder unterstützte Agent liest es.