Copilot: contexto de projeto funciona melhor quando cada regra tem um lugar

O GitHub publicou um tutorial que separa a personalização do Copilot em instruções, skills, agentes e ferramentas MCP.[7] O texto propõe manter convenções e procedimentos no repositório, em vez de repeti-los a cada tarefa.[7] Não é evidência de produtividade por si só. Meu interesse é outro: tornar explícito o que o agente precisa respeitar e o que uma alteração precisa demonstrar antes de ser aceita.

O que muda para quem desenvolve

As regras gerais ficam em .github/copilot-instructions.md, enquanto orientações específicas podem usar .github/instructions e o campo applyTo para delimitar caminhos.[7] Skills, em .github/skills, empacotam procedimentos, scripts e recursos; agentes personalizados, em .github/agents, definem papel, ferramentas e orientação para trabalhos mais amplos.[7] MCP acrescenta acesso a ferramentas e fontes externas, como documentação e navegador.[7]

Eu usaria essa separação para evitar dois extremos: um documento principal enorme e uma coleção de arquivos contraditórios. Uma convenção permanente não deveria depender de o agente descobrir uma skill específica. Já uma rotina de release não precisa ocupar todo o contexto de uma correção de CSS.

Também separaria acesso de autoridade. Dar ao agente uma ferramenta de navegador não significa autorizar publicação ou mudanças em contas reais. A configuração deve dizer o que pode ser consultado, o que pode ser alterado e qual evidência encerra a tarefa.

Como aplicar

Escolha uma regra que a equipe repete frequentemente, como o procedimento de validação de uma mudança. Registre o comando real de testes, o critério de aceite e a situação em que a execução deve parar. Evite frases vagas como “siga boas práticas”: elas não permitem conferir o resultado.

Em seguida, peça uma alteração pequena em um ambiente de teste. Confira se o agente identificou a regra, executou a validação aplicável e reportou um erro verdadeiro quando ela falhou. O experimento é sobre comportamento observável, não sobre a qualidade literária do arquivo de instruções.

Só depois extraia um procedimento recorrente para uma skill e avalie se uma revisão especializada justifica um agente separado. Para frontend, o tutorial mostra Playwright como forma de verificar a interface em um navegador.[7] Minha sugestão é exigir um roteiro curto: abrir a tela, realizar a interação afetada e conferir o resultado esperado, sem substituir os demais testes.

Versione esses arquivos e revise suas mudanças como parte do código. Inclua exemplos que não usem segredos, dados pessoais ou serviços de produção.

Cuidados e limites

O tutorial não anuncia um novo modelo nem apresenta uma prova de aumento de produtividade.[7] Ele também recomenda revisar e adaptar o conteúdo do catálogo comunitário Awesome Copilot.[7]

Eu não trataria instruções como um controle de segurança suficiente. Permissões das ferramentas e revisão das alterações precisam funcionar mesmo quando o agente interpreta uma regra de forma errada. O ganho buscado é menos ambiguidade operacional, não a promessa de que um arquivo Markdown torna toda execução confiável.

Fonte

[7] Fonte: GitHub Blog