Prompts para o GitHub Copilot: comentários, contexto e chat

Um desenvolvedor escreve // calcula o total acima de uma função vazia. O Copilot propõe dez linhas que somam os preços, sem o IVA, sem o desconto de fidelidade, com números de ponto flutuante onde o projeto usa centavos inteiros. O código compila e está errado, porque o comentário era a única informação dada.

O GitHub Copilot é conduzido de três maneiras: o que você escreve no arquivo, o que você pede a ele no chat e as regras que você define para todo o repositório. Cada uma tem seus reflexos.

As sugestões em linha: o comentário é o seu prompt

Quando o Copilot completa o seu código enquanto você digita, ele se baseia no que está em volta do cursor: o nome da função, os arquivos abertos, os comentários. Um nome explícito e um comentário que descreve o comportamento valem mais que um longo preâmbulo.

Compare estes dois começos de função.

// calcula o total
function total(itens) {

// Total de um carrinho em centavos (inteiros).
// Aplica o desconto de fidelidade de 5 % se cliente.fiel for verdadeiro,
// depois soma o IVA de 20 %. Arredonda para o centavo inferior.
// Carrinho vazio: retorna 0.
function totalCarrinho(itens, cliente) {

O segundo diz a unidade, a ordem das operações, o arredondamento e o caso-limite. O Copilot não precisa mais adivinhar. Se você não tem certeza da regra de negócio, não peça ao código que a adivinhe no seu lugar: escreva-a antes.

Dois hábitos também ajudam. Mantenha abertos os arquivos que mostram como o projeto faz as coisas (um módulo vizinho, um teste existente), porque eles servem de exemplo. E releia cada sugestão antes de aceitá-la, principalmente as mais longas: aceitar de uma vez dez linhas que você não leu é redigir um código que ninguém entende.

O chat: escolha o que ele vê

No chat, a qualidade da resposta depende do que o Copilot tem diante dos olhos. Conforme o seu editor, ele pode ver o arquivo aberto, o código que você selecionou e os arquivos que você adiciona explicitamente ao contexto (no Visual Studio Code, por exemplo, nomeando-os com #). Veja o que a sua interface oferece, porque as opções mudam de um editor para outro.

O reflexo útil é selecionar o código em questão antes de fazer a pergunta. Um exemplo de pedido para corrigir um bug:

A função selecionada retorna 0 para um carrinho de dois itens quando o cliente é fiel. Sem desconto, ela dá o total correto.

Procure a causa, explique-a em duas frases e depois proponha a menor correção possível. Não reescreva o resto da função e não mude a assinatura dela.

“A menor possível” protege o seu histórico de commits. Sem esse limite, a ferramenta reorganiza de bom grado o arquivo inteiro, e a revisão de código vira um pesadelo.

Para as tarefas comuns, comandos como /explain, /fix ou /tests existem no chat de vários editores. Eles evitam reescrever o mesmo pedido, mas complete-os com uma frase de restrições. Por exemplo, depois de /tests:

Escreva os testes da função selecionada com o framework já usado na pasta tests/. Cubra o carrinho vazio, o cliente fiel, um preço zerado, um arredondamento que cai entre dois centavos. Um teste por caso, com um nome que descreva o caso.

Depois, rode os testes. Um teste escrito pelo Copilot pode passar porque verifica o que o código faz, e não o que ele deveria fazer. Releia os valores esperados um por um.

As regras do projeto: um arquivo de instruções

Cansou de repetir “usamos centavos inteiros” e “nada de dependência nova sem avisar”? O GitHub permite colocar no repositório um arquivo .github/copilot-instructions.md, escrito em Markdown e em linguagem natural. O Copilot o lê nos pedidos relativos a esse repositório. O suporte varia conforme o editor e a funcionalidade, então consulte a documentação do GitHub para o seu caso.

# Regras do projeto

- Os valores são inteiros em centavos. Nunca use números de ponto flutuante para dinheiro.
- Testes com Vitest, na pasta tests/, um arquivo por módulo.
- Não adicione dependência sem me avisar na resposta.
- As mensagens de erro destinadas ao usuário são em português, os nomes no código são em inglês.

Mantenha esse arquivo curto e verificável. Dez regras precisas valem mais que três páginas de princípios, e uma regra que você nunca relê acaba contradizendo o código. O mesmo raciocínio vale para as instruções de sistema e para as instruções dos agentes: escreva o que um novo colega deveria saber no primeiro dia.

O que o Copilot não sabe

Ele não conhece as suas decisões de arquitetura, o seu histórico de bugs nem as regras que estão na cabeça da equipe. Ele também pode propor uma função de uma biblioteca que não existe ou uma sintaxe de uma versão antiga. Se uma sugestão usa uma chamada que você não reconhece, abra a documentação da biblioteca antes de continuar.

Pense também no conteúdo do seu código: chaves de acesso, senhas, dados de clientes. Não os coloque num comentário nem no chat, e leia os termos do seu plano e as regras do seu empregador sobre o envio de código a um serviço externo. As bases da revisão e da depuração com uma IA estão em nosso artigo sobre prompts para desenvolvedores.

Para experimentar hoje

Pegue a próxima função que você está para escrever. Antes de digitar a primeira linha, escreva em comentário o comportamento completo dela: entradas, saídas, um caso-limite. Veja o que o Copilot propõe e depois corrija o comentário, não o código, se a sugestão se afastar do que você queria.