Copilot Angular : instructions, skills, agents, MCP

Pourquoi personnaliser Copilot sur un projet Angular

Angular a énormément bougé en peu d'années : composants standalone par défaut, signals, input() et output() en fonctions, @if et @for dans les templates, inject() à la place du constructeur, zoneless, resource APIs. Un modèle de langage entraîné sur l'ensemble du web a vu dix fois plus de code Angular « ancienne génération » que de code moderne. Résultat : laissé sans consigne, Copilot vous proposera spontanément un NgModule, un @Input() titre: string et un *ngIf, alors que votre base de code est en signals depuis dix-huit mois.

Répéter « utilise les signals, pas de NgModule, syntaxe de flux de contrôle moderne » à chaque question fonctionne, mais coûte du temps et finit par être oublié. C'est exactement le problème que résout la personnalisation : on écrit la règle une fois, dans un fichier versionné, et l'outil l'applique à toutes les requêtes de toute l'équipe.

VS Code expose aujourd'hui six mécanismes distincts. Ils ne sont pas concurrents : ils répondent à des questions différentes, et le vrai sujet de cet article est de savoir lequel choisir pour quel besoin.

Les six mécanismes de personnalisation

Prerequis

Demarrage : generer la configuration avec le CLI Angular

L'équipe Angular maintient un ensemble de règles destinées aux assistants de code, et le CLI sait les matérialiser dans le format attendu par chaque outil. La commande accepte une option --tool qui liste les cibles à générer.

# Genere la configuration IA pour GitHub Copilot ET le format generique AGENTS.md
ng generate ai-config --tool=copilot,agents

# Valeurs autorisees pour --tool :
#   agents    -> AGENTS.md a la racine (format multi-outils)
#   claude    -> CLAUDE.md (Claude Code)
#   copilot   -> .github/copilot-instructions.md (GitHub Copilot)
#   cursor    -> regles Cursor
#   gemini    -> GEMINI.md
#   jetbrains -> guidelines pour les IDE JetBrains
#   windsurf  -> regles Windsurf
#   none      -> valeur par defaut, ne genere rien

# En mode interactif, le CLI pose la question et vous laisse cocher les cibles
ng generate ai-config

Générer à la fois copilot et agents est le choix pragmatique en 2026 : le premier est lu par Copilot, le second par la plupart des autres agents de code. Vous couvrez ainsi les collègues qui utilisent un autre outil sans dupliquer le travail intellectuel.

Angular publie également ses fichiers de contexte en accès direct, ce qui permet de les injecter dans n'importe quel outil, y compris ceux qui n'ont pas de schematic dédié.

# Index des ressources de contexte Angular destinees aux LLM
curl -s https://angular.dev/llms.txt

# Contexte long : description complete d'Angular et du developpement d'application
curl -s https://angular.dev/assets/context/llms-full.txt -o docs/angular-llms-full.txt

# Bonnes pratiques Angular au format markdown, directement reutilisable
curl -s https://angular.dev/assets/context/best-practices.md -o .github/instructions/angular-best-practices.md

Instructions de depot : copilot-instructions.md et AGENTS.md

VS Code cherche les instructions toujours actives à trois endroits : .github/copilot-instructions.md, un AGENTS.md à la racine de l'espace de travail, et un CLAUDE.md (racine, .claude/ ou ~/.claude/). Les trois peuvent coexister, et leur prise en compte se pilote par les réglages chat.useAgentsMdFile, chat.useNestedAgentsMdFiles et chat.useClaudeMdFile.

Voici un fichier d'instructions réaliste pour une application Angular moderne. Notez la structure : d'abord ce qu'est le projet, puis comment on l'exécute, enfin ce qui est interdit. Les interdits explicites sont la partie la plus rentable du fichier, parce qu'ils contredisent frontalement les habitudes statistiques du modèle.

# Instructions projet — Application Angular

## Stack
- Angular 20 en composants standalone, zoneless, changement de detection OnPush
- TypeScript en mode strict, pas de `any` implicite ni explicite
- Etat local via signals, etat serveur via `httpResource()` et `resource()`
- Tests unitaires avec Vitest, tests end-to-end avec Playwright
- Style avec Tailwind CSS, aucun fichier SCSS global hors `styles.css`

## Commandes du projet
- Demarrer : `npm start` (port 4200)
- Tests unitaires : `npm test` — doivent passer avant toute proposition de commit
- Lint : `npm run lint` — ESLint avec `@angular-eslint`, zero warning tolere
- Build production : `npm run build`

## Conventions
- Un composant par fichier, selecteur prefixe `app-`
- Entrees et sorties en fonctions : `input()`, `input.required()`, `output()`
- Injection par `inject()`, jamais par le constructeur
- Templates en syntaxe de flux de controle : `@if`, `@for` (avec `track`), `@switch`
- Services metier suffixes `Service`, exposant des signals en lecture seule
- Nommage des fichiers en kebab-case : `user-profile.component.ts`

## Interdits
- Ne jamais generer de `NgModule` ni de composant non standalone
- Ne jamais utiliser les decorateurs `@Input()` / `@Output()`
- Ne jamais utiliser `*ngIf`, `*ngFor`, `*ngSwitch` dans un template
- Ne jamais appeler `.subscribe()` dans un composant : passer par `toSignal()`
  ou le pipe `async`, et gerer la desinscription
- Ne jamais modifier les fichiers generes de `src/environments/`
- Ne jamais installer de dependance sans la mentionner explicitement

Le fichier AGENTS.md suit exactement le même principe mais porte un nom neutre, adopté par un nombre croissant d'agents de code. Sur un dépôt où cohabitent plusieurs outils, la stratégie la plus simple consiste à écrire le contenu réel dans AGENTS.md et à faire de copilot-instructions.md un renvoi court.

# .github/copilot-instructions.md

Les conventions de ce depot sont decrites dans [AGENTS.md](../AGENTS.md).
Applique-les integralement.

Specifique a Copilot dans cet espace de travail :
- Utilise le serveur MCP `angular-cli` pour verifier une API Angular avant
  de l'employer, plutot que de te fier a ta memoire d'entrainement.
- Avant toute modification de plus de trois fichiers, propose un plan et
  attends validation.

Ce qu'il ne faut pas mettre dedans

Un fichier d'instructions n'est pas une documentation d'architecture. Chaque ligne est relue à chaque requête : plus il est long, plus les règles importantes se diluent et plus la facture en tokens grimpe. Visez cent à cent cinquante lignes maximum. Tout le reste — procédures détaillées, tutoriels, exemples longs — appartient aux instructions ciblées ou aux skills, qui ne se chargent que lorsqu'elles sont pertinentes.

Instructions ciblees avec applyTo

Les conventions de test n'ont aucune raison d'être injectées quand vous demandez une modification de angular.json. Les règles de template n'ont pas leur place quand vous travaillez sur un intercepteur HTTP. Le champ applyTo résout ce gaspillage en conditionnant le chargement au chemin des fichiers.

---
name: Composants Angular
description: Conventions de redaction des composants standalone
applyTo: "**/*.component.ts"
---

# Regles de redaction des composants

## Signature du composant
- Toujours `standalone: true` implicite (Angular 19+) — ne pas le declarer
- `changeDetection: ChangeDetectionStrategy.OnPush` obligatoire
- `host` en propriete du decorateur, jamais de `@HostBinding` / `@HostListener`

## Etat et reactivite
- Etat local : `signal()`, derive : `computed()`, effet de bord : `effect()`
- Ne jamais ecrire dans un signal depuis un `computed()`
- Un `effect()` ne doit jamais servir a synchroniser deux signals :
  utiliser `linkedSignal()` ou `computed()`

## Entrees et sorties
- `readonly label = input.required<string>();`
- `readonly saved = output<User>();`
- Transformer une entree avec l'option `transform`, pas dans un setter

## Template
- Template inline si moins de 20 lignes, sinon fichier `.component.html`
- `@for` toujours avec `track` sur un identifiant stable, jamais sur `$index`
- Pas d'appel de methode dans une interpolation : passer par un `computed()`

Le même principe s'applique aux tests, avec des règles qui n'ont de sens nulle part ailleurs.

---
name: Tests unitaires
description: Conventions de test Vitest pour les composants et services Angular
applyTo: "**/*.spec.ts"
---

# Regles de test

- Un `describe` par unite testee, des `it` formules en francais et au present
- Monter les composants avec `TestBed.configureTestingModule({ imports: [...] })`
- Remplacer les dependances par `provideHttpClientTesting()`, jamais de mock maison
- Ne jamais tester un detail d'implementation privee : passer par le DOM rendu
- Toujours verifier au moins un cas d'erreur en plus du cas nominal
- Interdiction de `fdescribe`, `fit`, `xit` dans le code commite

Vous pouvez multiplier ces fichiers sans crainte : ils ne coûtent rien tant qu'ils ne se déclenchent pas. Un découpage typique sur une application Angular sérieuse compte cinq à huit fichiers — composants, services, tests, templates HTML, styles, configuration de build, et éventuellement les fichiers d'internationalisation.

Prompt files : des taches repetables en commande slash

L'en-tête YAML d'un prompt file accepte plusieurs clés : description, name, argument-hint, agent (valeurs ask, agent, plan ou le nom d'un agent personnalisé), model et tools. Le corps du fichier est un prompt markdown ordinaire, dans lequel ${input:nom} insère une valeur demandée à l'utilisateur au lancement.

---
name: Nouveau composant
description: Cree un composant Angular standalone complet, avec ses tests
argument-hint: "[nom-du-composant] [dossier-cible]"
agent: agent
model: GPT-5
tools: ['search/codebase', 'edit/editFiles', 'runCommands']
---

# Creation d'un composant Angular

Cree un composant nomme `${input:nom:Nom du composant, en kebab-case}`
dans le dossier `${input:dossier:Chemin relatif depuis src/app}`.

## Ce que tu dois produire
1. Le fichier `.component.ts` : standalone, OnPush, entrees en `input()`,
   sorties en `output()`, injection par `inject()`.
2. Le template : `@if` / `@for` uniquement, `track` obligatoire sur les boucles.
3. Le fichier `.spec.ts` : au moins un test de rendu, un test d'entree et
   un test d'emission de sortie.
4. L'export du composant dans le fichier `index.ts` du dossier s'il existe.

## Ce que tu ne dois pas faire
- Ne cree pas de module.
- N'ajoute aucune dependance externe.
- Ne modifie aucun fichier hors du dossier cible, hormis `index.ts`.

## Verification finale
Lance `npm run lint` puis `npm test` sur le fichier cree, et corrige
les erreurs jusqu'a ce que les deux commandes passent.

Le second usage à fort rendement est la migration mécanique. Angular évolue vite, et chaque version apporte son lot de transformations que les schematics officiels ne couvrent pas entièrement — notamment tout ce qui touche au style de code plutôt qu'à l'API.

---
name: Migration signals
description: Convertit un composant vers les signals et la syntaxe moderne
argument-hint: "[chemin-du-composant]"
agent: agent
---

# Migration d'un composant vers les signals

Fichier cible : `${input:fichier:Chemin du composant a migrer}`

Applique les transformations suivantes, dans cet ordre, en verifiant
la compilation apres chaque etape :

1. `@Input() x: T` devient `readonly x = input<T>();`
   Si l'entree n'a pas de valeur par defaut et est utilisee sans garde,
   utilise `input.required<T>()`.
2. `@Output() y = new EventEmitter<T>()` devient `readonly y = output<T>();`
   Remplace les `y.emit(v)` inchanges.
3. `@ViewChild('ref')` devient `viewChild('ref')`, `@ViewChildren` devient
   `viewChildren`.
4. Les proprietes mutables lues dans le template deviennent des `signal()`,
   et leurs lectures dans le template gagnent des parentheses.
5. Les valeurs derivees deviennent des `computed()`.
6. Le constructeur avec injection devient des champs `inject()`.
7. Ajoute `changeDetection: ChangeDetectionStrategy.OnPush` s'il manque.

## Contrainte absolue
Ne modifie pas le comportement observable du composant. Si une
transformation est ambigue, arrete-toi et pose la question plutot
que de deviner.

## Rapport
Termine par un tableau des transformations appliquees et la liste des
points laisses en suspens.

Un troisième prompt file, discret mais très rentable, prépare la revue de code avant l'ouverture d'une pull request.

---
name: Pre-revue
description: Relit les modifications en cours avant ouverture de pull request
agent: agent
tools: ['search/codebase', 'runCommands']
---

# Pre-revue des modifications

Analyse le diff courant (`git diff --staged` puis `git diff`) et produis
un rapport structure.

## Points a verifier
- Respect des conventions decrites dans AGENTS.md
- Absence de `console.log`, de `debugger`, de `TODO` non references
- Absence de `any`, de non-null assertion `!` injustifiee
- Signals lus sans parentheses dans un template
- `@for` sans `track`
- Souscriptions RxJS sans desabonnement
- Secrets, tokens ou URL d'environnement en dur

## Format de sortie
Un tableau : fichier, ligne, severite (bloquant / a corriger / remarque),
description. Termine par une conclusion en une phrase : la branche est-elle
prete a etre ouverte en pull request ?

Ne modifie aucun fichier. Ce prompt est en lecture seule.

Agent Skills : packager un savoir-faire Angular

VS Code détecte les skills dans .github/skills/, .claude/skills/ ou .agents/skills/ pour le projet, et dans ~/.copilot/skills/, ~/.claude/skills/ ou ~/.agents/skills/ pour les skills personnelles. Le réglage chat.agentSkillsLocations permet d'en ajouter d'autres.

Le chargement se fait en trois temps, ce qui explique l'intérêt du format : la découverte lit les métadonnées de toutes les skills, l'activation injecte le corps de SKILL.md dans le contexte, et les fichiers annexes du dossier ne sont lus que si le modèle y fait référence. Une skill de deux mille lignes ne coûte donc rien tant qu'elle dort.

.github/skills/
├── angular-feature/
│   ├── SKILL.md              # obligatoire : nom, description, procedure
│   ├── component-template.ts # exemple de reference, lu a la demande
│   ├── store-template.ts
│   └── checklist.md
└── angular-perf-audit/
    ├── SKILL.md
    └── scripts/
        └── analyze-bundle.mjs

L'en-tête YAML exige deux champs : name (identifiant en minuscules, tirets autorisés, 64 caractères maximum) et description (1024 caractères maximum). La description est le seul élément lu en permanence : c'est elle qui décide si la skill se déclenche. Rédigez-la donc en décrivant à la fois ce que fait la skill et quand l'utiliser.

---
name: angular-feature
description: Cree une fonctionnalite Angular complete — routes lazy, store en
  signals, composants standalone, tests. A utiliser des qu'une demande porte
  sur l'ajout d'une nouvelle page ou d'un nouveau domaine metier a l'application.
argument-hint: "[nom-de-la-fonctionnalite]"
user-invocable: true
---

# Creation d'une fonctionnalite Angular

## Quand utiliser cette skill
- Ajout d'une nouvelle page routee
- Ajout d'un nouveau domaine metier (entite + ecrans + service)
- Extraction d'une partie de l'application en fonctionnalite autonome

## Arborescence a produire

src/app/features/<nom>/
├── <nom>.routes.ts        # routes exportees, chargees en lazy
├── data/
│   ├── <nom>.service.ts   # acces HTTP, expose des signals en lecture seule
│   └── <nom>.model.ts     # types et interfaces du domaine
├── ui/                     # composants presentationnels, sans injection
└── pages/                  # composants routes, orchestrent ui + data

## Procedure
1. Cree le fichier de routes et branche-le en lazy dans `app.routes.ts`
   via `loadChildren: () => import('./features/<nom>/<nom>.routes')`.
2. Cree le service de donnees en suivant `store-template.ts` de ce dossier.
3. Cree les composants de page en suivant `component-template.ts`.
4. Cree un `.spec.ts` par fichier produit.
5. Deroule `checklist.md` avant de considerer la tache terminee.

## Regles non negociables
- Aucun import croise entre deux dossiers `features/` : passer par `core/`.
- Les composants de `ui/` ne font aucune injection de service.
- Chaque route lazy declare son `title` pour l'accessibilite et le SEO.

Trois champs optionnels méritent l'attention. user-invocable, à true par défaut, contrôle la présence de la skill dans le menu /. disable-model-invocation, à false par défaut, empêche le chargement automatique et impose l'invocation manuelle — pratique pour une procédure coûteuse ou risquée. Enfin context: fork, expérimental, exécute la skill dans un sous-agent dédié avec son propre contexte.

Les skills officielles Angular

L'équipe Angular publie ses propres skills, ce qui évite de réécrire à la main les bonnes pratiques du framework. Deux sont disponibles : angular-developer, qui génère du code Angular et fournit des conseils d'architecture sur les composants, services, formulaires, routage et tests ; et angular-new-app, qui crée une nouvelle application via le CLI en respectant les recommandations actuelles.

# Installe les skills officielles Angular dans le projet courant
npx skills add https://github.com/angular/skills

# Les skills sont ensuite deposees dans le dossier de skills du projet
# et deviennent visibles dans le menu / du chat

Agents personnalises : un role, des outils, un modele

Les agents personnalisés se placent dans .github/agents/ pour le projet (ou .claude/agents/ au format Claude), dans ~/.copilot/agents/ pour les agents personnels, et dans tout dossier ajouté via chat.agentFilesLocations. On les invoque en les choisissant dans la liste des agents du chat, ou en tapant /agents pour ouvrir le menu de configuration.

L'en-tête accepte name, description, tools, model, argument-hint, user-invocable, agents (liste des sous-agents autorisés, ou *), handoffs (enchaînements séquentiels entre agents) et hooks. Commençons par le cas le plus utile : un relecteur en lecture seule.

---
name: revue-angular
description: Relecteur Angular en lecture seule — analyse, ne modifie jamais
model: Claude Opus 4.8
tools: ['search/codebase', 'search/usages', 'problems']
---

# Role

Tu es relecteur senior Angular. Tu analyses du code et tu produis un
rapport. Tu ne modifies aucun fichier et tu n'executes aucune commande :
ces outils ne te sont volontairement pas fournis.

# Grille de lecture

## Reactivite
- Signals lus sans parentheses dans un template
- `effect()` utilise la ou un `computed()` suffirait
- Ecriture dans un signal depuis un `computed()`
- Souscription RxJS sans desabonnement ni `takeUntilDestroyed()`

## Performance
- Composant sans `OnPush`
- `@for` sans `track` ou avec `track $index` sur une liste mutable
- Appel de methode dans une interpolation de template
- Import non lazy d'une route lourde

## Architecture
- Import croise entre deux dossiers `features/`
- Logique metier dans un composant plutot que dans un service
- Composant presentationnel qui injecte un service

## Accessibilite
- Element interactif sans role ni libelle accessible
- Image sans attribut `alt`

# Format de sortie

Un tableau : severite, fichier:ligne, probleme, correction suggeree.
Trie par severite decroissante. Si aucun probleme n'est trouve, dis-le
en une phrase — n'invente pas de remarque pour remplir le rapport.

Le second archétype est l'agent de planification, qui réfléchit sans agir. Il est particulièrement adapté aux migrations et aux refactorisations larges, où l'on veut valider une stratégie avant de laisser un agent toucher trente fichiers.

---
name: architecte-angular
description: Concoit un plan de migration ou de refactorisation, sans ecrire de code
model: Claude Opus 4.8
tools: ['search/codebase', 'search/usages', 'fetch']
agents: ['revue-angular']
handoffs: ['implementeur-angular']
---

# Role

Tu produis des plans d'implementation. Tu n'ecris jamais de code de
production et tu ne modifies aucun fichier.

# Methode

1. Cartographie l'existant : fichiers concernes, dependances, tests
   couvrant la zone. Cite les chemins reels que tu as lus.
2. Identifie les risques : ce qui peut casser silencieusement, ce qui
   n'est couvert par aucun test.
3. Decoupe en etapes independamment livrables et testables. Chaque etape
   doit laisser l'application dans un etat compilable.
4. Pour chaque etape : fichiers touches, nature du changement, critere
   de validation objectif.
5. Termine par ce qui reste incertain et necessite une decision humaine.

# Contraintes

- Pas plus de huit etapes. Au-dela, decoupe en plusieurs plans.
- Aucune etape ne doit toucher plus de dix fichiers.
- Si l'ampleur reelle depasse ce cadre, dis-le au lieu de compresser.

Le champ handoffs permet d'enchaîner : l'architecte passe la main à un agent d'implémentation qui, lui, dispose des outils d'édition. Cette séparation réduit nettement les dégâts, parce que l'agent qui décide n'est pas celui qui exécute.

MCP : brancher le serveur Angular CLI

Les instructions et les skills renseignent le modèle sur ce qu'il doit faire. Un serveur MCP lui donne accès à ce qui existe vraiment : la documentation Angular à jour, la structure de votre espace de travail, l'état de vos builds. La configuration minimale tient en cinq lignes.

{
  "servers": {
    "angular-cli": {
      "command": "npx",
      "args": ["-y", "@angular/cli", "mcp"]
    }
  }
}

Une fois le serveur démarré depuis VS Code, Copilot dispose des outils suivants.

En pratique, on ajoute rapidement d'autres serveurs. Voici une configuration complète pour une application Angular avec back-end, incluant la gestion des secrets par variables d'entrée.

{
  "inputs": [
    {
      "id": "db-password",
      "type": "promptString",
      "description": "Mot de passe de la base de developpement",
      "password": true
    }
  ],
  "servers": {
    "angular-cli": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@angular/cli", "mcp"]
    },
    "playwright": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@microsoft/mcp-server-playwright"]
    },
    "github": {
      "type": "http",
      "url": "https://api.githubcopilot.com/mcp"
    },
    "postgres-dev": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-postgres"],
      "env": {
        "PGHOST": "localhost",
        "PGDATABASE": "app_dev",
        "PGPASSWORD": "${input:db-password}"
      }
    }
  }
}

Le fichier accepte également un bloc sandbox qui borne ce que les serveurs peuvent atteindre — écriture limitée à l'espace de travail, domaines réseau autorisés explicitement. Sur un projet d'entreprise, c'est un garde-fou à activer par défaut.

{
  "servers": {
    "angular-cli": {
      "command": "npx",
      "args": ["-y", "@angular/cli", "mcp"]
    }
  },
  "sandbox": {
    "filesystem": {
      "allowWrite": ["${workspaceFolder}"]
    },
    "network": {
      "allowedDomains": ["angular.dev", "registry.npmjs.org"]
    }
  }
}

Hooks : verrouiller la boucle de l'agent

Toute la difficulté de la personnalisation par prompt est qu'elle reste une suggestion : un modèle peut ignorer une consigne, surtout en fin de contexte long. Les hooks résolvent ce point en déplaçant la contrainte hors du modèle. Une règle « lance toujours le lint après modification » écrite dans les instructions sera respectée la plupart du temps ; la même règle en hook sera respectée systématiquement.

Les hooks peuvent être déclarés au niveau d'un agent, via la clé hooks de son en-tête, ce qui permet de réserver une contrainte coûteuse aux agents qui écrivent réellement du code. Le réglage chat.useCustomAgentHooks pilote leur activation.

---
name: implementeur-angular
description: Implemente les taches Angular avec verification automatique
tools: ['search/codebase', 'edit/editFiles', 'runCommands', 'problems']
hooks:
  afterEdit: "npx prettier --write ${file} && npx eslint --fix ${file}"
---

# Role

Tu implementes les taches decrites par l'agent architecte.

# Methode

1. Relis le plan avant de commencer. Si une etape est ambigue, demande.
2. Implemente une etape a la fois. Ne passe jamais a la suivante avant
   que la precedente compile et que ses tests passent.
3. Apres chaque etape, lance `npm test` sur le perimetre modifie.
4. Si un test existant casse, arrete-toi : c'est un signal, pas un
   obstacle a contourner. Ne modifie jamais un test pour le faire passer.

# Interdits

- Ne desactive jamais une regle ESLint par commentaire pour faire passer
  le lint : corrige le code.
- Ne supprime jamais un test.
- N'installe aucune dependance sans validation explicite.

Quel mecanisme pour quel besoin

L'erreur la plus courante consiste à tout mettre dans copilot-instructions.md. Le fichier gonfle, les règles importantes se noient, et la qualité des réponses baisse alors même qu'on croit l'améliorer. La grille suivante répartit chaque type de contenu.

Une arborescence de reference

Voici à quoi ressemble un projet Angular correctement outillé, une fois les six mécanismes en place. Rien n'oblige à tout adopter d'un coup : les deux premiers niveaux couvrent déjà l'essentiel du gain.

mon-app-angular/
├── AGENTS.md                          # conventions, format multi-outils
├── .github/
│   ├── copilot-instructions.md        # renvoi vers AGENTS.md + specifique Copilot
│   ├── instructions/
│   │   ├── components.instructions.md # applyTo: **/*.component.ts
│   │   ├── templates.instructions.md  # applyTo: **/*.component.html
│   │   ├── services.instructions.md   # applyTo: **/*.service.ts
│   │   ├── tests.instructions.md      # applyTo: **/*.spec.ts
│   │   └── styles.instructions.md     # applyTo: **/*.{css,scss}
│   ├── prompts/
│   │   ├── nouveau-composant.prompt.md
│   │   ├── migration-signals.prompt.md
│   │   └── pre-revue.prompt.md
│   ├── skills/
│   │   ├── angular-feature/SKILL.md
│   │   └── angular-perf-audit/SKILL.md
│   └── agents/
│       ├── architecte-angular.agent.md
│       ├── implementeur-angular.agent.md
│       └── revue-angular.agent.md
├── .vscode/
│   ├── mcp.json                       # angular-cli + playwright + github
│   └── settings.json                  # reglages de chat partages
└── src/

Le fichier .vscode/settings.json permet de partager les réglages de personnalisation avec toute l'équipe, ce qui évite le classique « chez moi ça marche » lié à une configuration locale non versionnée.

{
  "chat.useAgentsMdFile": true,
  "chat.useNestedAgentsMdFiles": true,
  "chat.useCustomizationsInParentRepositories": true,
  "chat.promptFilesRecommendations": true,
  "chat.instructionsFilesLocations": {
    ".github/instructions": true,
    "docs/conventions": true
  },
  "chat.promptFilesLocations": {
    ".github/prompts": true
  },
  "chat.agentSkillsLocations": {
    ".github/skills": true
  }
}

Bonnes pratiques et anti-patterns

Ce qui fonctionne

Ce qui ne fonctionne pas

Mesurer que ca sert vraiment

La personnalisation a un coût : des fichiers à maintenir, des tokens consommés, une configuration à expliquer aux nouveaux arrivants. Il faut donc vérifier qu'elle rapporte. Le protocole le plus simple consiste à figer trois ou quatre demandes types de votre projet — « ajoute un champ au formulaire d'inscription », « crée une page de détail », « écris les tests de ce service » — et à les rejouer après chaque évolution de la configuration.

Comptez ensuite le nombre d'allers-retours nécessaires pour obtenir un résultat acceptable, et le nombre de violations de conventions dans la première réponse. Ces deux chiffres suffisent à savoir si une règle ajoutée sert à quelque chose. Une règle qui ne fait pas bouger l'aiguille en trois essais mérite d'être reformulée — ou supprimée.

Conclusion

Configurer GitHub Copilot sur un projet Angular n'est pas un exercice de style : c'est ce qui sépare un assistant qui vous propose des NgModule d'un assistant qui écrit du code conforme à votre base. Les six mécanismes — instructions de dépôt, instructions ciblées, prompt files, agent skills, agents personnalisés et serveurs MCP — répondent chacun à une question distincte, et les mélanger est la principale source de déception.

Le chemin le plus efficace est progressif. Lancez ng generate ai-config --tool=copilot,agents pour partir d'une base officielle, complétez-la avec vos commandes et vos interdits, puis branchez le serveur MCP Angular : ces trois actions représentent moins d'une heure de travail et couvrent la majeure partie du bénéfice. Ajoutez ensuite les instructions ciblées quand un fichier de conventions devient trop long, les prompt files quand vous vous surprenez à retaper la même demande, les skills quand une procédure mérite d'être capitalisée, et les agents quand vous voulez séparer ce qui décide de ce qui exécute.

Reste une limite qu'aucune configuration ne lève : ces fichiers orientent le modèle, ils ne le contraignent pas. Seuls les hooks, les tests et la revue humaine garantissent réellement quelque chose. La personnalisation augmente la proportion de réponses correctes du premier coup — c'est déjà considérable — mais elle ne remplace pas la relecture.