Personalizzare le funzionalità di modernizzazione di GitHub Copilot

La modernizzazione di GitHub Copilot è estensibile. L'agente fornisce più punti di personalizzazione per codificare i modelli di aggiornamento del team, applicare standard di codifica durante gli aggiornamenti e definire nuovi flussi di lavoro di aggiornamento.

Panoramica dei punti di personalizzazione

Personalizzare tramite chat

Personalizzare il comportamento dell'agente in tempo reale tramite una conversazione naturale. L'agente applica immediatamente le tue istruzioni o le memorizza in scenario-instructions.md per un utilizzo futuro.

Modificare gli artefatti dello scenario

Quando l'agente esegue un aggiornamento, crea un'area di lavoro in .github/upgrades/{scenarioId}/. La cartella di aggiornamento contiene artefatti modificabili che controllano direttamente il comportamento dell'agente.

Istruzioni per lo scenario

Il scenario-instructions.md file è la memoria persistente dell'agente per l'aggiornamento. L'agente carica sempre questo file nel contesto, quindi tutto ciò che si scrive qui influisce direttamente su ogni decisione presa dall'agente.

Aggiungere sezioni simili alle seguenti per guidare l'agente:

## 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

Il plan.md file definisce le attività e il relativo ambito. Modifica plan.md in:

• Riordinare le attività per modificare la sequenza di esecuzione.
• Aggiungere attività per cui l'agente non ha pianificato.
• Rimuovere le attività che non si applicano.
• Aggiungere note per fornire il contesto per attività specifiche.

Singoli file di attività

Ogni attività in tasks/{taskId}/task.md contiene la specifica dell'attività e le note di lavoro. Modificare questi file in:

• Perfezionare l'ambito di un'attività.
• Aggiungere il contesto specifico del dominio che l'agente ha trascurato.
• Fornire esempi di codice per il risultato desiderato.

Creare competenze personalizzate

Le competenze sono il punto di estensione principale per l'agente. Una competenza è un file Markdown con un'intestazione di metadati che insegna all'agente come gestire un aggiornamento, un modello o un'attività specifici.

Dove inserire competenze personalizzate

Struttura del file di abilità

Ogni file di abilità ha due parti: un'intestazione di metadati (usata dall'agente per comprendere quando si applica l'abilità) e un corpo in Markdown (istruzioni che l'agente segue).

---
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

Campi dei metadati

Procedure consigliate per la creazione di competenze

• Essere specifici nella descrizione: Includere nomi esatti dei pacchetti, nomi di libreria e frasi trigger in linguaggio naturale che gli utenti possono digitare.
• Includere flussi di lavoro chiari e dettagliati: Numerare i passaggi. Essere espliciti sui file da modificare e sui comandi da eseguire.
• Includere i criteri di successo: Senza criteri di successo, l'agente non sa quando fermarsi. Usare le caselle di controllo o un elenco non crittografato di condizioni verificabili.
• Includere la gestione degli errori: Prevedere le modalità di errore comuni, ad esempio pacchetti mancanti, errori di compilazione o test interrotti.
• Mantenere incentrate le competenze: Una competenza per ogni tipo di aggiornamento o attività. Una competenza per l'aggiornamento di FooBar v2 a v3 è migliore rispetto all'aggiornamento di tutte le librerie interne.
• Nome con un verbo gerund: Usare upgrading-foobar-v2-to-v3, non foobar-upgrade o foobar-v3.
• Usa lazy l'individuazione: usa lazy l'individuazione per la maggior parte delle competenze personalizzate per evitare il sovraccarico della finestra di contesto dell'agente.

Creare scenari personalizzati

Per gli utenti avanzati che vogliono definire flussi di lavoro di aggiornamento completamente nuovi, gli scenari personalizzati consentono di orchestrare una pipeline di aggiornamento a più fasi completa. Uno scenario è una competenza con metadata.discovery: scenario che definisce le fasi che l'agente segue.

---
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

Posizionare i file di scenario in .github/skills/ o .github/upgrades/skills/ per consentire all'agente di individuarli.

Controllo del codice sorgente e diramazione

L'agente offre di lavorare su un ramo Git, ma si ha il controllo completo sulla strategia:

• Denominazione dei rami: Indicare all'agente il nome del ramo da usare o lasciare che l'agente ne suggerisca uno.
• Rami per attività: Richiedere un ramo separato per attività per una revisione granulare.
• Intervallo commit: Scegliere quando l'agente esegue il commit: dopo ogni attività completata (impostazione predefinita), solo alla fine dell'aggiornamento completo o su richiesta.
• Nessun controllo del codice sorgente: L'agente funziona anche con cartelle non Git, ma consiglia di eseguire prima il backup del progetto.

Istruzioni di chat di esempio:

• "Usare il nome del ramo 'upgrade/dotnet10' per questo aggiornamento"
• "Creare un ramo per ogni attività in modo da poter esaminare ogni ramo separatamente"
• "Non eseguire il commit fino a quando non ti chiedo esplicitamente di"
• "Eseguire il commit dopo ogni attività con un messaggio descrittivo"

Priorità di caricamento delle competenze

Quando l'agente individua più competenze, le risolve usando un sistema di priorità. Le origini con priorità più alta sostituiscono o integrano quelle con priorità inferiore:

L'agente raccoglie le competenze da tutte le origini. Quando le competenze hanno un ambito sovrapposto, le origini con priorità più alta hanno la precedenza. Il campo discovery controlla quando viene caricata l'abilità. lazy significa su richiesta quando pertinente e preload significa sempre disponibile.

Contenuti correlati

• Concetti fondamentali
• Scenari e informazioni di riferimento sulle competenze
• Applicare istruzioni di aggiornamento personalizzate
• Procedure consigliate