Personalizar a modernização do GitHub Copilot

A modernização do GitHub Copilot é extensível. O agente fornece vários pontos de personalização para codificar os padrões de atualização da equipe, impor padrões de codificação durante as atualizações e definir novos fluxos de trabalho de atualização.

Visão geral dos pontos de personalização

Personalizar por meio do chat

Personalize o comportamento do agente em tempo real por meio da conversa natural. O agente aplica sua instrução imediatamente ou a persiste em scenario-instructions.md para referência futura.

Editar artefatos de cenário

Quando o agente executa uma atualização, ele cria um workspace em .github/upgrades/{scenarioId}/. A pasta de atualização contém artefatos editáveis que controlam diretamente o comportamento do agente.

scenario-instructions.md

O scenario-instructions.md arquivo é a memória persistente do agente para a atualização. O agente sempre carrega esse arquivo no contexto, portanto, tudo o que você escreve aqui influencia diretamente cada decisão tomada pelo agente.

Adicione seções como estas para orientar o 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

O plan.md arquivo define as tarefas e seu escopo. Editar plan.md para:

• Reordene as tarefas para alterar a sequência de execução.
• Adicione tarefas para as quais o agente não planejou.
• Remova tarefas que não se aplicam.
• Adicione anotações para fornecer contexto para tarefas específicas.

Arquivos de tarefa individuais

Cada tarefa em tasks/{taskId}/task.md contém a especificação da tarefa e as anotações de trabalho. Edite estes arquivos para:

• Refinar o escopo de uma tarefa.
• Adicione o contexto específico do domínio que o agente deixou de considerar.
• Forneça exemplos de código para o resultado desejado.

Criar competências personalizadas

Habilidades são o principal ponto de extensão do agente. Uma habilidade é um arquivo Markdown com um cabeçalho de metadados que ensina o agente a lidar com uma atualização, um padrão ou uma tarefa específico.

Onde colocar habilidades personalizadas

Estrutura de arquivo de Skill

Cada arquivo de habilidade tem duas partes: um cabeçalho de metadados (que o agente usa para entender quando a habilidade se aplica) e um corpo Markdown (instruções que o 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

Campos de metadados

Práticas recomendadas para criação de habilidades

• Seja específico na descrição: Inclua nomes exatos de pacote, nomes de biblioteca e frases de gatilho de linguagem natural que os usuários podem digitar.
• Inclua fluxos de trabalho claros e passo a passo: Numerar as etapas. Seja explícito sobre quais arquivos alterar e quais comandos executar.
• Inclua critérios de êxito: Sem critérios de êxito, o agente não sabe quando parar. Use caixas de seleção ou uma lista clara de condições verificáveis.
• Inclua o tratamento de erros: Prevejo modos comuns de falha, como pacotes ausentes, falhas de build ou testes interrompidos.
• Mantenha as habilidades focadas: Uma habilidade por atualização ou tipo de tarefa. Uma habilidade para "atualizar o FooBar v2 para v3" é melhor do que "atualizar todas as bibliotecas internas".
• Nome com um verbo gerúndio: Usar upgrading-foobar-v2-to-v3, não foobar-upgrade ou foobar-v3.
• Use a descoberta de lazy: use a descoberta de lazy para a maioria das habilidades personalizadas para evitar o inchaço da janela de contexto do agente.

Criar cenários personalizados

Para usuários avançados que desejam definir fluxos de trabalho de atualização totalmente novos, os cenários personalizados permitem orquestrar um pipeline de atualização de várias fases completo. Um cenário é uma habilidade com metadata.discovery: scenario a qual define as fases que o 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

Coloque arquivos de cenário dentro .github/skills/ ou .github/upgrades/skills/ para que o agente os descubra.

Controle do código-fonte e ramificação

O agente se oferece para trabalhar em uma ramificação do Git, mas você tem controle total sobre a estratégia:

• Nomenclatura de ramificação: Informe ao agente qual nome de ramificação usar ou deixe o agente sugerir um.
• Ramificações por tarefa: solicite uma ramificação separada por tarefa para uma análise detalhada.
• Tempo de confirmação: Escolha quando o agente executa a confirmação: após cada tarefa concluída (padrão), somente no final da atualização completa ou sob demanda.
• Nenhum controle do código-fonte: O agente também funciona com pastas não Git, mas recomenda fazer backup do projeto primeiro.

Instruções de chat de exemplo:

• "Use o nome do branch 'upgrade/dotnet10' para esta atualização"
• "Crie uma ramificação por tarefa para que eu possa examinar cada uma separadamente"
• "Não se comprometa até que eu peça explicitamente para você"
• "Confirmar após cada tarefa com uma mensagem descritiva"

Prioridade de carregamento de habilidades

Quando o agente descobre várias habilidades, ele as resolve usando um sistema de prioridade. Fontes de prioridade mais alta substituem ou complementam as de prioridade mais baixa:

O agente coleta habilidades de todas as fontes. Quando as habilidades têm escopo sobreposto, as fontes de prioridade mais alta têm precedência. O campo discovery controla quando o skill é carregado. lazy significa sob demanda quando relevante e preload significa sempre disponível.

Conteúdo relacionado

• Conceitos básicos
• Referência de cenários e habilidades
• Aplicar instruções de atualização personalizadas
• Práticas recomendadas