O primeiro prompt em uma ferramenta de código costuma travar antes mesmo de a ferramenta fazer qualquer coisa. A pessoa abre o projeto, vê um campo vazio e começa a tentar adivinhar a frase perfeita. O tutorial oficial do GitHub para o Copilot app parte de uma ideia mais simples: escolha um projeto, diga o que você quer mudar e refine depois.
Isso parece banal, mas muda a porta de entrada. Um prompt, nesse contexto, não é um comando secreto nem uma fórmula que precisa ser decorada. É uma descrição de tarefa com contexto suficiente para o agente encontrar o lugar certo no código.
Comece pelo projeto, não pela frase
Antes de pedir uma alteração, o Copilot precisa saber em que contexto vai trabalhar. No aplicativo, a sessão pode ser ligada a um repositório do GitHub ou a uma pasta local. Essa escolha dá acesso aos arquivos que fazem parte da tarefa.
Para quem está começando, vale selecionar um projeto pequeno e conhecido. Pode ser uma lista simples, uma página pessoal ou um exercício que já tenha alguma estrutura. Um repositório menor facilita a conferência do que o agente leu e reduz a chance de uma mudança aparentemente pequena atingir arquivos demais.
Também ajuda entrar na sessão com uma pergunta concreta. “Faça meu aplicativo melhor” deixa decisões demais abertas. “Adicione uma opção para ordenar a lista de jogos pelo valor arrecadado” aponta uma ação, um lugar provável e um resultado que pode ser conferido.
Um pedido claro já é um bom começo
O exemplo usado pelo GitHub é direto: adicionar uma opção de ordenação por maior financiamento em uma lista de jogos. Ele não descreve cada arquivo, função ou componente. A ideia é permitir que o Copilot examine a base e encontre os pontos relacionados.
Isso não significa que qualquer pedido curto será suficiente. Se o projeto tiver duas telas com listas diferentes, acrescente a informação que separa uma da outra. Se houver uma regra importante, escreva a regra. “Não altere o formato da API” ou “inclua um teste para lista vazia” pode evitar uma rodada de correção.
Uma forma prática de montar o primeiro pedido é escrever quatro coisas: o que deve mudar, em qual parte do projeto, qual comportamento você espera e o que não pode ser quebrado. Não precisa transformar isso em um formulário. Uma ou duas frases bem específicas costumam ser melhores que um parágrafo cheio de termos técnicos.
Depois do primeiro resultado, corrija o rumo
O tutorial também reforça que prompting é um processo iterativo. Você pode explicar o que ficou diferente do esperado e pedir uma alteração. O primeiro prompt não precisa antecipar todas as decisões, porque a conversa serve justamente para ajustar o trabalho.
Esse ajuste deve acontecer olhando o diff, os arquivos modificados e os testes. Um agente pode entender a tarefa, mas escolher uma solução que não combina com o projeto. Se a resposta criar código em uma camada errada, diga onde a regra deveria ficar. Se a ordenação funcionar apenas quando todos os dados estão preenchidos, teste o caso vazio e peça a correção com esse exemplo.
O melhor uso do segundo prompt não é repetir o pedido inteiro. É apontar uma diferença observável: “a tela ordena, mas perde a seleção atual quando o usuário troca o filtro”. Esse tipo de detalhe dá ao agente uma pista melhor do que uma avaliação vaga como “não ficou bom”.
Modelo, voz e outras opções ficam para depois
O GitHub Copilot app permite escolher o modelo usado na tarefa. Modelos diferentes podem se comportar melhor em tarefas complexas ou simples, mas quem está começando não precisa estudar todas as diferenças antes de fazer o primeiro teste. O modelo padrão é um ponto de partida razoável. A troca passa a fazer sentido quando a tarefa exige mais raciocínio ou quando a primeira tentativa não chega a um resultado útil.
O aplicativo também oferece entrada por voz. A fala vira texto no campo do prompt, onde pode ser revisada antes do envio. Isso pode ajudar quando a pessoa consegue explicar o problema falando, mas ainda não encontrou a forma curta de escrevê-lo. A revisão continua importante: o texto transcrito pode trocar nomes de arquivos ou termos do projeto.
Há ainda opções de agentes e sessões remotas. Elas ampliam o modo de executar o trabalho, mas não são requisitos para começar. Configurar tudo antes da primeira tarefa só aumenta a quantidade de decisões sem responder à pergunta mais importante: o Copilot consegue fazer uma mudança pequena e verificável nesse projeto?
O primeiro teste seguro
Escolha uma tarefa que tenha começo e fim visíveis. Antes de enviar o prompt, crie um checkpoint no Git, confirme que a pasta está correta e veja se há testes ou uma forma manual de conferir o resultado. Depois, escreva o pedido em linguagem comum e aguarde a proposta.
Leia o que mudou antes de aceitar. Rode os testes. Abra a tela ou execute o comando relacionado à tarefa. Se algo sair errado, reverta o checkpoint e tente de novo com um pedido mais específico. O objetivo do primeiro prompt não é entregar um sistema inteiro. É aprender como a ferramenta lê aquele projeto e onde a conversa precisa de mais contexto.
Para começar, um pedido como “explique esta pasta antes de alterar qualquer arquivo” também é válido. Ele transforma a primeira sessão em reconhecimento, especialmente quando o repositório é novo para você. Quando a estrutura estiver clara, passe para uma mudança pequena. O agente trabalha melhor quando a tarefa tem um resultado que você consegue conferir sem depender da própria explicação dele.
Fonte: GitHub Blog, por Kayla Cinnamon, publicado em 12 de agosto de 2026 e atualizado em 17 de agosto de 2026. Imagem conferida na fonte original.