Aller au contenu
Pathrule

documentation

GitHub Copilot

Comment Pathrule CLI connecte GitHub Copilot en mode agent de VS Code, dans le Copilot CLI et dans l'agent de codage, via les instructions, les hooks, MCP et les skills.

Sur cette page

GitHub Copilot se connecte à votre espace de travail Pathrule via Pathrule CLI ou l'extension VS Code. Il reçoit les connaissances de l'espace de travail, ciblées selon le contexte, par des hooks de session et d'outil, des fichiers d'instructions et le serveur MCP local. Copilot n'a pas de hook de soumission de prompt : le contexte arrive donc au démarrage de la session et autour des appels d'outils, et non à chaque prompt. La configuration Remote MCP n'est pas documentée pour Copilot. Copilot se distingue par le fait qu'un seul ensemble de fichiers au niveau du dépôt alimente trois surfaces à la fois : le mode agent de VS Code, le Copilot CLI et l'agent de codage.

Cette page présente ce que Pathrule écrit pour Copilot, les différences entre les surfaces, la correspondance des événements de hook et la manière de vérifier l'intégration.

Ce que Pathrule écrit

Lorsque vous activez Copilot, Pathrule écrit dans les chemins propres à Copilot au lieu d'en inventer de nouveaux. Tous les fichiers se trouvent sous .github/, là où Copilot regarde déjà.

FichierRôle
.github/copilot-instructions.mdAppliqué automatiquement en mode agent et dans le CLI. Avec le hook installé, il contient une courte note Pathrule et le garde-fou de Copilot pour l'appel à pathrule_get_context ; sans le hook, il contient le protocole Pathrule complet.
.github/instructions/pathrule.instructions.mdUn pointeur dont la portée est définie par applyTo, qui maintient le protocole présent même lorsque la sélection des instructions repose sur des globs.
.github/hooks/pathrule.jsonLa configuration des hooks. C'est le seul emplacement de hooks que lisent les trois surfaces Copilot.
.github/skills/<slug>/SKILL.mdLes skills rattachés à votre espace de travail, pour que Copilot puisse les invoquer par leur nom.

Lorsque le hook Copilot est installé, le protocole passe par le hook sessionStart plutôt que par le fichier d'instructions, et les connaissances liées aux chemins arrivent par les hooks : aucun fichier de connaissances n'est écrit dans votre arborescence. Sans le hook, Pathrule écrit aussi un fichier .github/instructions/pathrule-k-*.instructions.md, dont la portée est définie par applyTo, pour chaque répertoire auquel des connaissances sont rattachées.

Les skills présentent une subtilité. Copilot lit aussi .claude/skills. Si Claude Code et Copilot sont tous deux activés sur le même espace de travail, Pathrule ignore .github/skills afin que Copilot ne voie pas chaque skill en double. Activer les deux clients n'entraîne donc ni skills ni protocole dupliqués dans le contexte de Copilot.

Vous pouvez vérifier ce qui a été écrit :

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

Trois surfaces, un seul ensemble de fichiers

Les mêmes fichiers .github/ activent chaque surface Copilot, mais les surfaces diffèrent dans la façon dont les hooks et MCP les atteignent.

SurfaceHooksEmplacement de la configuration MCP
Mode agent de VS CodeLit .github/hooks ; lit aussi .claude/settings.json s'il existemcp.json au niveau utilisateur, ou enregistrement dans l'éditeur par l'extension VS Code de Pathrule
Copilot CLILit .github/hooks~/.copilot/mcp-config.json
Agent de codage (sur github.com)Lit .github/hooks depuis le dépôt commitéParamètres du dépôt sur github.com, configurés par vous (non gérés par fichier)

Pour VS Code, la clé racine de la configuration MCP est servers, et non mcpServers. Si vous utilisez l'extension VS Code de Pathrule, le mode agent de Copilot est enregistré pour vous dans l'éditeur, sans fichier MCP à modifier à la main.

L'agent de codage est la seule surface que Pathrule ne peut pas configurer depuis le disque. Il travaille à partir de ce qui est commité dans le dépôt, et ses serveurs MCP sont définis dans les paramètres du dépôt sur github.com, en dehors de tout fichier géré par Pathrule : Pathrule ne configure donc pas MCP pour lui. Pour lui fournir les instructions et les skills, commitez les fichiers .github/. Si votre espace de travail contient un .gitignore, les skills matérialisés y figurent dans une section Pathrule ; supprimez ces lignes pour les commiter. La configuration des hooks exécute le hook Pathrule installé sur la machine qui l'a écrite : le contexte injecté par les hooks et le blocage ne s'appliquent donc que là où Pathrule est installé, c'est-à-dire dans le mode agent de VS Code et le Copilot CLI.

Couverture des événements de hook

Les événements de hook de Copilot correspondent aux mêmes points d'injection que ceux utilisés par Pathrule sur Cursor et Claude Code.

  • sessionStart. Au début d'une session. Pathrule renvoie les métadonnées de l'espace de travail, le protocole et le contexte de votre équipe, soit l'amorçage que Claude Code reçoit au démarrage de sa session.
  • postToolUse. Après l'exécution d'un outil. Pathrule fournit le contexte lié au chemin pour ce que l'agent vient de toucher, et enregistre l'activité.
  • preToolUse. Avant l'exécution d'un outil. C'est ici qu'une règle dotée d'un motif de blocage approuvé refuse une modification correspondante avant qu'elle ne soit appliquée, en donnant comme motif la règle et la correction approuvée. En mode agent de VS Code, cet événement peut aussi transporter le contexte lié au chemin ; le Copilot CLI n'accepte du contexte que sur sessionStart et postToolUse.
  • agentStop, subagentStop et sessionEnd. Clôturent le tour et la session.

L'événement déclenché à chaque prompt n'est volontairement pas branché. La sortie de Copilot pour cet événement ne transporte aucun contexte supplémentaire : s'y abonner coûterait un processus par prompt sans aucune injection. SessionStart et PostToolUse couvrent le même terrain. Le résultat est équivalent au profil d'injection de Cursor.

Un seul script de hook partagé gère tous les clients. Il détecte la forme du payload Copilot, la normalise vers une forme canonique unique, applique la même sélection de règles et de mémoires que pour tous les autres clients, puis répond dans le schéma de Copilot. Vous n'avez rien à configurer par surface. Le script est permissif en cas d'échec, par conception : un payload non reconnu ou mal formé ne renvoie rien au lieu d'interrompre votre session Copilot.

Installation

Avec Pathrule CLI :

pathrule setup

Lancez la commande dans le dossier du projet et choisissez GitHub Copilot lorsqu'elle vous demande quels outils d'IA vous utilisez. Le setup vous connecte à Pathrule Cloud si nécessaire, rattache le dossier à un espace de travail, installe les entrées MCP, mémorise votre choix pour ce dossier et écrit les fichiers .github/. Lancez plutôt pathrule setup --local pour utiliser Pathrule sans compte.

Pour installer les éléments à la main dans un dossier déjà rattaché :

pathrule install copilot
pathrule sync
pathrule doctor

pathrule install copilot écrit le serveur Pathrule dans les deux configurations MCP, ~/.copilot/mcp-config.json pour le Copilot CLI et le mcp.json utilisateur de VS Code, sans toucher aux autres serveurs de ces fichiers. pathrule sync écrit les fichiers de projet pour les outils d'IA choisis pour ce dossier, ou, si aucun n'a été choisi, pour ceux qu'il détecte dans le dossier.

Avec l'extension VS Code de Pathrule, choisissez GitHub Copilot dans Connect AI Clients. L'extension enregistre le mode agent de Copilot dans l'éditeur et écrit pour vous les fichiers d'instructions et la configuration des hooks.

Vérification

Ouvrez un espace de travail rattaché à Pathrule et démarrez une session Copilot sur la surface que vous utilisez.

  • Mode agent de VS Code ou Copilot CLI. Démarrez une nouvelle conversation. Le contexte lié au chemin doit arriver avant le premier appel d'outil. Modifiez un fichier situé sous un chemin auquel des connaissances sont rattachées et observez l'apparition des règles et mémoires pertinentes.
  • Agent de codage. Une fois les fichiers .github/ commités, l'agent de codage lit les instructions et les skills depuis le dépôt. Ajoutez un serveur MCP dans les paramètres du dépôt sur github.com si vous voulez qu'il appelle des outils.

Si l'intégration reste muette :

pathrule doctor

Le doctor fonctionne en lecture seule. Il indique votre connexion, votre espace de travail et si ce dossier est rattaché, liste Copilot deux fois, une pour la configuration du Copilot CLI et une pour le mcp.json de VS Code, afin qu'une installation partielle soit visible, et montre quels fichiers gérés par Pathrule se trouvent dans le dossier et qui les a écrits. Ajoutez --json pour obtenir le rapport complet, qui nomme chaque chemin de configuration et signale aussi une entrée MCP pointant vers un runtime qui n'existe plus. Pour corriger ce cas, lancez :

pathrule repair

Repair réécrit les entrées MCP Pathrule obsolètes, laisse vos autres serveurs intacts, resynchronise les fichiers de projet et relance le doctor. pathrule uninstall copilot retire l'entrée Pathrule des deux configurations MCP, et désactiver Copilot pour le dossier supprime tous les fichiers que Pathrule possède pour lui.

Ce qui ne change pas

Tout ce que vous écrivez dans Pathrule parvient à Copilot sous la même forme qu'à Claude Code et Cursor.

  • Une mémoire écrite avec le CLI, l'extension VS Code ou via MCP apparaît dans Copilot.
  • Une règle dotée d'un motif de blocage approuvé bloque une modification correspondante dans Copilot.
  • Un skill peut être invoqué par son nom dans Copilot.
  • Les outils MCP (pathrule_get_context, pathrule_write_memory et les autres) se comportent de façon identique.

Vous écrivez vos connaissances une seule fois, et chaque agent pris en charge les lit.