Práticas recomendadas para prompts do GitHub Copilot

O GitHub Copilot produz ajuda de programação mais útil quando a descrição da tarefa explica o problema, o escopo, as restrições e a prova de sucesso. Um prompt curto pode funcionar para uma conclusão local de código. Uma alteração no repositório exige a mesma clareza de uma issue bem escrita.

A superfície do produto importa: a documentação atual do GitHub descreve instruções para todo o repositório, instruções específicas por caminho, instruções para agentes e arquivos de prompt reutilizáveis, com suporte que varia por funcionalidade e IDE. Use as ferramentas disponíveis no seu ambiente, mas mantenha a solicitação subjacente explícita.

Dê à conclusão de código um contrato local

Para uma função pequena, o nome, os tipos e os testes ao redor muitas vezes são suficientes. Acrescente o comportamento que é fácil errar de maneira sutil:

Implemente um analisador para o cabeçalho retry-after.

Retorne milissegundos para segundos ou para uma data HTTP válida. Retorne null
para um valor ausente, negativo ou inválido. Não lance uma exceção a partir de
um caminho de erro de resposta. Adicione testes orientados por tabela para
segundos, uma data futura, uma data passada e uma entrada malformada.

O contrato orienta a conclusão sem exigir um longo briefing de arquitetura.

Descreva o trabalho de teste como comportamento

Evite:

Escreva testes para o hook de preferências.

Use:

Adicione testes para o hook de preferências usando as convenções de teste existentes.

Verifique se o estado inicial de carregamento não redireciona, se uma leitura
bem-sucedida expõe as preferências salvas, se uma atualização grava o objeto
completo de preferências atomicamente e se uma atualização com falha mantém o
valor visível anterior.

Use comportamento público em vez de contagens internas de chamadas de funções.
Inclua a regressão que falharia com o bug relatado.

Agora o assistente tem um contrato voltado ao usuário, incluindo um caso negativo importante.

Dê a prompts de refatoração regras para preservar o comportamento

Sugestões de código podem criar uma abstração local organizada enquanto descartam um detalhe público. Coloque a preservação na solicitação:

Extraia a apresentação de status repetida destes dois cartões.

Preserve as propriedades atuais, os rótulos visíveis, os nomes de eventos de
analytics, o foco do teclado e o layout móvel. Limite as alterações a esta
funcionalidade e a seus testes diretos.

Antes de editar, liste o comportamento repetido e as diferenças que devem
permanecer separadas. Não transforme isso em um componente compartilhado do
sistema de design, a menos que o primitivo existente não consiga representar o resultado.

Se você não consegue nomear o comportamento a preservar, primeiro peça ao Copilot que explique o contrato atual e os pontos de chamada.

Depure com sintomas e evidências

Sintoma: A página de pesquisa mostra resultados desatualizados depois que um usuário
altera os filtros.

Esperado: A seleção de filtro mais recente controla os resultados exibidos.
Observado: Uma solicitação anterior mais lenta pode sobrescrever uma resposta mais nova.

Código relevante: a interface de filtro, o hook de solicitação e o renderizador
de resultados. Alteração recente: foram adicionadas novas tentativas de solicitação.

Primeiro, descreva o ciclo de vida da solicitação e as hipóteses concorrentes.
Indique quais logs ou qual timing de teste comprovariam cada uma. Depois, proponha
a menor correção e a cobertura de regressão. Não substitua a camada de dados sem evidências.

Isso evita que uma resposta genérica de “corrigir a condição de corrida” se expanda para uma migração desnecessária de gerenciamento de estado.

Use instruções do repositório para contexto estável

Regras estáveis devem ficar junto ao projeto, onde houver suporte:

como executar testes e formatação;
restrições de implantação;
localidades ou plataformas compatíveis;
APIs públicas que devem permanecer compatíveis;
caminhos em que revisões de segurança ou acessibilidade importam.

A documentação do GitHub descreve instruções personalizadas no nível do repositório e arquivos de instruções mais direcionados. Mantenha essas instruções curtas, precisas e limitadas a convenções duráveis. Coloque no próprio prompt os detalhes da issue atual — sintomas, resultado e critérios de aceitação.

Peça documentação fundamentada no código

Atualize o guia de solução de problemas de implantação após a nova verificação de ambiente.

Verifique cada comando e variável de ambiente em relação ao repositório. Explique
o sinal de sucesso, o sinal comum de falha e a próxima ação segura. Mantenha
segredos fora dos exemplos. Adicione links para o runbook operacional existente
em vez de duplicá-lo.

A expressão “verifique em relação ao repositório” importa. Ela diz ao Copilot que documentação precisa é uma tarefa de leitura de código, não de geração de prosa.

Termine todo prompt significativo com critérios de aceitação

Use uma linha de chegada que outra pessoa possa revisar:

Concluído significa:
- o comportamento relatado pelo usuário muda conforme descrito;
- o comportamento protegido permanece inalterado;
- testes focados comprovam os caminhos novo e antigo;
- a verificação de tipos e o comando de lint relevante passam;
- o diff não contém limpeza não relacionada.

Para a estrutura geral de prompts, leia como escrever prompts melhores para IA. Para padrões específicos por tarefa, continue com engenharia de prompts para desenvolvedores e, em seguida, evite os modos de falha em erros de assistentes de programação com IA e como evitá-los.

Quando uma tarefa de programação incluir scripts, saída de comando ou uma reprodução no terminal, valide-a em vez de descrevê-la de memória. Pratique o fluxo de trabalho de linha de comando no navegador antes de transformá-lo em um prompt ou teste.