Personnaliser la modernisation de GitHub Copilot

La modernisation de GitHub Copilot est extensible. L’agent fournit plusieurs points de personnalisation pour encoder les modèles de mise à niveau de votre équipe, appliquer des normes de codage pendant les mises à niveau et définir de nouveaux flux de travail de mise à niveau.

Vue d’ensemble des points de personnalisation

Personnaliser par le biais d’une conversation

Personnalisez le comportement de l’agent en temps réel par le biais d’une conversation naturelle. L'agent peut soit appliquer immédiatement votre instruction, soit la conserver à scenario-instructions.md pour référence ultérieure.

Modifier les artefacts de scénario

Lorsque l’agent exécute une mise à niveau, il crée un espace de travail dans .github/upgrades/{scenarioId}/. Le dossier de mise à niveau contient des artefacts modifiables qui contrôlent directement le comportement de l’agent.

scenario-instructions.md

Le scenario-instructions.md fichier est la mémoire persistante de l’agent pour la mise à niveau. L’agent charge toujours ce fichier dans le contexte, donc tout ce que vous écrivez ici influence directement chaque décision prise par l’agent.

Ajoutez des sections comme celles-ci pour guider l’agent :

## User Preferences

### Technical Preferences
- Always prefer explicit type declarations over `var`
- Use `ILogger<T>` instead of `ILoggerFactory` for dependency injection
- Target .NET 10 for all projects
- Keep Newtonsoft.Json in the shared library (don't migrate to System.Text.Json)

### Execution Style
- **Pace**: Methodical
- **Pause Points**: After assessment, after each task group

### Custom Instructions

#### 02-common-lib
- Skip the database migration for now — it has external dependencies
- Use the connection string from `appsettings.Production.json` for testing

#### 03-data-layer
- Keep existing repository interfaces during migration
- Preserve all Entity Framework conventions

## Key Decisions Log
- 2025-01-15: Keep Newtonsoft.Json in SharedLib — third-party SDK requires it
- 2025-01-16: Skip database project — DBA team will handle separately

plan.md

Le plan.md fichier définit les tâches et leur étendue. Modifier plan.md pour :

• Réorganiser les tâches pour modifier la séquence d’exécution.
• Ajoutez des tâches que l’agent n’a pas prévues.
• Supprimez les tâches qui ne s’appliquent pas.
• Ajoutez des notes pour fournir un contexte pour des tâches spécifiques.

Fichiers de tâches individuels

Chaque tâche dans tasks/{taskId}/task.md contient la spécification et les notes de travail. Modifiez ces fichiers pour :

• Affiner l’étendue d’une tâche.
• Ajoutez un contexte spécifique au domaine qu’il a omis.
• Fournissez des exemples de code pour le résultat souhaité.

Créer des compétences personnalisées

Les compétences sont le point d’extension principal de l’agent. Une compétence est un fichier Markdown avec un en-tête de métadonnées qui enseigne à l’agent comment gérer une mise à niveau, un modèle ou une tâche spécifique.

Où placer des compétences personnalisées

Structure du fichier de compétence

Chaque fichier de compétence comporte deux parties : un en-tête de métadonnées (que l’agent utilise pour comprendre quand la compétence s’applique) et un corps Markdown (instructions que l’agent suit).

---
name: migrating-foobar-v2-to-v3
description: >
  Migrate our internal FooBar library from v2 to v3. Activates when
  FooBar.v2 NuGet package is detected, or when asked to "upgrade FooBar",
  "migrate FooBar", or "update FooBar library".
metadata:
  discovery: lazy
  traits: .NET | CSharp
---

# Migrating FooBar Library v2 to v3

## Overview

FooBar v3 introduces a new async-first API surface. This skill guides the
agent through replacing synchronous FooBar.v2 calls with their v3 async
equivalents, updating configuration, and verifying behavior.

## Workflow

1. **Identify FooBar.v2 references**
   - Search for `PackageReference` elements referencing `FooBar.v2`
   - Locate all `using FooBar.V2;` directives

2. **Update package references**
   - Replace `FooBar.v2` with `FooBar.v3` in all `.csproj` files
   - Run `dotnet restore` to verify resolution

3. **Migrate API calls**
   - Replace `FooBarClient.Send(...)` with `await FooBarClient.SendAsync(...)`
   - Replace `FooBarConfig.LoadFromFile(...)` with `FooBarConfig.LoadFromJsonAsync(...)`
   - Update method signatures to `async Task` where needed

4. **Update configuration**
   - Rename `foobar.config` to `foobar.json`
   - Migrate XML config entries to JSON format

5. **Verify**
   - Build the project: `dotnet build`
   - Run existing tests: `dotnet test`
   - Verify no remaining references to `FooBar.V2` namespace

## Success Criteria

- [ ] No references to `FooBar.v2` NuGet package remain
- [ ] All `FooBar.V2` namespace usages replaced with `FooBar.V3`
- [ ] Project builds without errors
- [ ] All existing tests pass

## Error Handling

- If `FooBar.v3` is not available in the configured NuGet feeds, instruct
  the user to add the internal feed
- If async migration causes deadlocks in legacy synchronous code paths,
  wrap calls with `.GetAwaiter().GetResult()` and add a TODO comment

Champs de métadonnées

Meilleures pratiques en matière de création de compétences

• Soyez spécifique dans la description : Incluez des noms de package exacts, des noms de bibliothèque et des expressions de déclencheur en langage naturel que les utilisateurs peuvent taper.
• Incluez des flux de travail clairs et pas à pas : Numéroter les étapes. Soyez explicite sur les fichiers à modifier et les commandes à exécuter.
• Incluez les critères de réussite : Sans critères de réussite, l’agent ne sait pas quand arrêter. Utilisez des cases à cocher ou une liste claire de conditions vérifiables.
• Incluez la gestion des erreurs : Anticiper les modes d’échec courants, tels que les packages manquants, les échecs de build ou les tests rompus.
• Concentrez-vous sur les compétences : Une compétence par type de mise à niveau ou de tâche. Une compétence pour la « mise à niveau de FooBar v2 vers v3 » est préférable à la « mise à niveau de toutes les bibliothèques internes ».
• Nom avec un verbe gerund : Utilisez upgrading-foobar-v2-to-v3, non foobar-upgrade ou foobar-v3.
• Utiliser la découverte lazy : utilisez la découverte lazy pour la plupart des compétences personnalisées pour éviter de surcharger la fenêtre de contexte de l’agent.

Créer des scénarios personnalisés

Pour les utilisateurs avancés qui souhaitent définir entièrement de nouveaux flux de travail de mise à niveau, les scénarios personnalisés vous permettent d’orchestrer un pipeline de mise à niveau multiphase complet. Un scénario est une compétence avec metadata.discovery: scenario qui définit les phases que l'agent suit.

---
name: migrating-soap-to-rest-api
description: >
  Migrate legacy WCF/SOAP services to ASP.NET Core REST APIs. Activates
  when WCF service references, .svc files, or SOAP clients are detected,
  or when asked to "migrate SOAP to REST", "replace WCF", or "convert
  web services to REST".
metadata:
  discovery: scenario
  traits: .NET | CSharp
  scenarioTraitsSet: [wcf, soap, web-services]
---

# SOAP to REST API Migration

## Pre-initialization

Gather from the user:
- Which SOAP services to migrate (all or specific ones)
- Whether to maintain backward compatibility with a SOAP facade
- Authentication mechanism for the new REST APIs
- API versioning strategy (URL path, header, query string)

## Assessment

Analyze the solution for:
- `.svc` files and WCF service contracts
- WSDL files and service references
- `System.ServiceModel` usage and binding configurations
- Data contracts and their serialization requirements
- Client proxies consuming SOAP services

## Planning

Create tasks in this order:
1. Create shared DTOs — Convert `[DataContract]` types to POCOs
2. Create REST controllers — One controller per `[ServiceContract]`
3. Map operations to HTTP methods
4. Migrate service implementations
5. Update clients — Replace `ChannelFactory`/generated proxies with `HttpClient`
6. Remove WCF infrastructure
7. Add API documentation — Swagger/OpenAPI via Swashbuckle

## Execution

For each service contract:
1. Create a corresponding controller
2. Create a service interface and implementation
3. Register the service in DI
4. Map WCF operations to REST endpoints
5. Update any in-solution clients to use the new REST endpoints
6. Build and run existing tests

Placez des fichiers de scénario dans .github/skills/ ou .github/upgrades/skills/ pour que l’agent les découvre.

Contrôle de code source et branchement

L’agent propose de travailler sur une branche Git, mais vous avez un contrôle total sur la stratégie :

• Nommage de branche : Indiquez à l’agent quel nom de branche utiliser ou laissez l’agent en suggérer un.
• Branches par tâche : Demandez une branche distincte par tâche pour une révision granulaire.
• Minutage de validation : Choisissez quand l’agent valide : après chaque tâche terminée (par défaut), uniquement à la fin de la mise à niveau complète ou à la demande.
• Aucun contrôle de code source : L’agent fonctionne également avec des dossiers non Git, mais recommande de sauvegarder votre projet en premier.

Exemples d’instructions de conversation :

• « Utiliser le nom de branche « upgrade/dotnet10 » pour cette mise à niveau »
• « Créer une branche par tâche afin que je puisse passer en revue chacun séparément »
• « Ne vous commitez pas tant que je ne vous demande pas explicitement »
• « Valider après chaque tâche avec un message descriptif »

Priorité de chargement des compétences

Lorsque l’agent découvre plusieurs compétences, il les résout à l’aide d’un système de priorité. Les sources de priorité supérieure remplacent ou complètent les sources de priorité inférieure :

L’agent collecte les compétences de toutes les sources. Lorsque les compétences se chevauchent, les sources prioritaires ont la préséance. Le champ discovery contrôle quand la compétence se charge. lazy signifie à la demande en cas de pertinence et preload signifie toujours disponible.

Contenu connexe

• Concepts de base
• Informations de référence sur les scénarios et les compétences
• Appliquer des instructions de mise à niveau personnalisées
• Bonnes pratiques