A mudança de Gems para Skills importa menos pelo nome e mais pela forma de reutilizar instruções: em vez de manter um assistente especializado isolado, a proposta é aplicar conjuntos de instruções em diferentes conversas e combiná-los conforme a tarefa. Para quem programa, isso pode reduzir a repetição de contexto — desde que as Skills sejam pequenas, explícitas e testadas. Se virarmos cada uma em um prompt gigantesco, só trocamos um tipo de acoplamento por outro.
O que muda entre Gems e Skills no Gemini
Segundo o Eurisko.com.br, os Gems foram apresentados em 2024 como assistentes personalizados para tarefas como escrita, programação e estudos. O usuário definia instruções e passava a interagir com aquele assistente especializado. A limitação apontada é que cada Gem funcionava como um ambiente separado.
Com as Skills, a lógica descrita muda: em vez de depender de um assistente fixo, o usuário cria conjuntos de instruções reutilizáveis, que podem ser acionados em conversas diferentes e combinados de acordo com o trabalho. Na prática, isso se aproxima de tratar instruções como componentes, não como personalidades completas.
Essa distinção é útil para quem desenvolve. Um Gem voltado a revisão de código pode reunir regras de estilo, formato de resposta e contexto em uma configuração única. Uma Skill, por sua vez, pode representar apenas a etapa de revisão — e ser combinada com outra que conheça as convenções de um projeto ou a linguagem usada.
Assistente especializado ou instrução reutilizável?
Eu penso nessa diferença como a que existe entre uma aplicação monolítica e uma biblioteca de funções: o monólito resolve um cenário inteiro, enquanto componentes menores podem ser reutilizados em mais de um fluxo. A analogia não é perfeita — uma Skill continua sendo uma instrução para um modelo, não necessariamente código executável —, mas ajuda a entender o impacto no uso.
Com Gems, a pergunta tende a ser “qual assistente devo abrir?”. Com Skills, a pergunta passa a ser “quais instruções fazem sentido para esta tarefa?”. Essa segunda abordagem pode ser mais flexível, especialmente quando o trabalho mistura atividades. Por exemplo, analisar um pull request pode exigir contexto do repositório, critérios de segurança e um formato de resposta para revisão.
Mas modularidade não é sinônimo automático de qualidade. Se as instruções se contradizem, são vagas ou repetem o mesmo contexto de formas diferentes, a composição pode produzir respostas inconsistentes. O ganho depende de como cada unidade é delimitada.
Por que Skills podem ser úteis para desenvolvedores
Uma rotina de desenvolvimento raramente é uma única tarefa. Posso pedir uma explicação de código, revisar um diff, gerar testes e documentar uma API no mesmo dia. Se cada atividade exige que eu reescreva as mesmas regras — como preservar compatibilidade, não inventar requisitos e apontar riscos —, há desperdício de tempo e aumenta a chance de esquecer uma instrução importante.
Instruções reutilizáveis ajudam a separar preocupações. Uma Skill pode definir como revisar código; outra pode explicar o padrão de arquitetura do time; uma terceira pode exigir que sugestões venham acompanhadas de testes. A composição ideal depende da tarefa, sem obrigar o usuário a tratar todo pedido como se fosse igual.
- Menos repetição: regras estáveis podem ser reaproveitadas em diferentes conversas.
- Mais especialização: uma instrução pode focar em revisão, testes ou documentação, sem carregar todo o fluxo de trabalho.
- Melhor manutenção: fica mais fácil localizar qual conjunto de instruções precisa ser alterado quando um padrão muda.
- Composição por tarefa: o usuário pode combinar orientações gerais e específicas, quando o produto permitir esse tipo de uso.
O último ponto merece cuidado: o Eurisko descreve a possibilidade de combinar Skills em conversas, mas isso não significa que toda forma de composição, prioridade ou resolução de conflito já esteja disponível em todas as contas. Eu confirmaria os recursos na interface e na documentação atual do Gemini antes de desenhar um processo dependente deles.
Skills, Gems, GPTs personalizados e ferramentas de agentes
Comparar Skills com alternativas ajuda a escolher a abstração certa. Gems e GPTs personalizados são mais próximos de assistentes configurados para um propósito. Instruções reutilizáveis, como as Skills descritas, se aproximam mais de componentes de contexto que podem participar de tarefas distintas. Já ferramentas como chamadas de função, APIs e servidores MCP tratam de acesso a capacidades e dados — não são apenas instruções.
| Abordagem | Uso típico | O que não presumir |
|---|---|---|
| Gem ou assistente personalizado | Manter um assistente com instruções e propósito recorrentes. | Que suas regras sejam automaticamente reutilizadas em qualquer outro assistente. |
| Skill ou instrução reutilizável | Aplicar orientações específicas em mais de uma tarefa ou conversa. | Que a instrução execute código ou acesse sistemas por conta própria. |
| Ferramenta, API ou MCP | Consultar dados, executar ações ou integrar sistemas externos. | Que uma descrição em linguagem natural substitua autenticação, autorização e validação. |
Essa separação evita um erro comum: colocar instruções e capacidades no mesmo saco. Uma Skill pode dizer “consulte a documentação antes de sugerir uma API”, mas, sem uma ferramenta de busca ou acesso aos arquivos, isso não garante que o modelo realmente consultará uma fonte externa. Instrução orienta o comportamento; integração fornece a capacidade.
Também não trataria a mudança como uma migração técnica garantida de Gems para Skills. A fonte descreve uma substituição gradual, mas não detalha compatibilidade, exportação automática ou conversão de configurações. Antes de reorganizar um fluxo de trabalho importante, eu verificaria o que a conta oferece e manteria uma cópia das instruções essenciais fora da plataforma.
Na Prática: como organizar Skills para revisão de código
Mesmo sem depender de um recurso específico da interface, dá para aplicar a mesma ideia no próprio projeto: separar instruções reutilizáveis por responsabilidade e compor apenas as necessárias. O exemplo abaixo monta um contexto para revisar um diff. Ele não chama um modelo nem substitui uma API; mostra uma forma simples de estruturar e validar os blocos de instrução na aplicação.
- Defina instruções pequenas e com objetivo claro.
- Escolha explicitamente quais instruções entram naquela tarefa.
- Combine os blocos em uma ordem previsível.
- Envie o contexto ao modelo pela integração que você já utiliza.
type SkillName = "review" | "security" | "typescript";
const skills: Record<SkillName, string> = {
review: [
"Revise o diff fornecido, não o reescreva inteiro.",
"Priorize bugs, regressões e problemas de manutenção.",
"Para cada achado, informe arquivo, impacto e correção sugerida.",
"Se não encontrar problemas, diga isso explicitamente."
].join("\n"),
security: [
"Procure validação insuficiente, exposição de segredos e falhas de autorização.",
"Não afirme que existe uma vulnerabilidade sem apontar evidência no diff."
].join("\n"),
typescript: [
"Considere segurança de tipos e comportamento em tempo de execução.",
"Não recomende remover tipos apenas para silenciar erros do compilador."
].join("\n")
};
function buildReviewPrompt(diff: string, selected: SkillName[]): string {
if (!diff.trim()) {
throw new Error("O diff não pode estar vazio.");
}
const uniqueSkills = [...new Set(selected)];
const instructions = uniqueSkills.map((name) => skills[name]);
return [
"Você está revisando uma alteração de código.",
...instructions,
"Use o diff abaixo como evidência:",
diff
].join("\n\n");
}
const prompt = buildReviewPrompt(
"diff --git a/app.ts b/app.ts\n+const role = request.query.role;",
["review", "security", "typescript"]
);
console.log(prompt);Repare que o exemplo não coloca “seja especialista em tudo” em uma instrução enorme. Cada bloco tem responsabilidade definida, e a função rejeita uma entrada vazia. Em uma aplicação real, eu acrescentaria testes para a composição, limites de tamanho e tratamento de dados sensíveis antes de enviar o contexto ao provedor.
Erros comuns ao criar Skills para IA
Transformar cada Skill em um prompt completo
Se todas repetem o papel do assistente, as regras de segurança e o formato de resposta, a manutenção fica difícil. Quando uma regra muda, alguém precisa atualizar várias cópias. Mantenha cada instrução curta e deixe as regras compartilhadas em um bloco comum, se a ferramenta permitir.
Escrever critérios vagos
“Revise com cuidado” não define o que é um bom resultado. Prefiro instruções observáveis: apontar o trecho, explicar o impacto, distinguir certeza de hipótese e sugerir uma correção proporcional. Quanto mais avaliável for a regra, mais fácil será testar se o comportamento melhorou.
Ignorar conflitos e ordem das instruções
Uma instrução pode pedir respostas curtas e outra exigir explicações detalhadas. Outra pode dizer para nunca alterar código, enquanto uma terceira pede uma versão corrigida. Não assuma que o modelo resolverá conflitos como você espera. Separe regras compatíveis e teste combinações representativas.
Colocar segredos ou dados internos no texto
Não inclua tokens, senhas, dados pessoais ou informações confidenciais em instruções reutilizáveis. Trate prompts e conversas conforme as políticas da sua organização e do fornecedor. Uma Skill que fica disponível em vários contextos merece revisão de acesso e de conteúdo, assim como qualquer configuração compartilhada.
Confiar no rótulo em vez de medir resultado
Chamar algo de Skill não torna a saída confiável. Para tarefas importantes, mantenha exemplos de entrada e resultados esperados. Teste casos normais, entradas ambíguas e situações em que a resposta correta é pedir esclarecimento ou admitir que faltam dados. Em revisão de código, confira se os achados são reais; em geração de testes, execute os testes.
Como avaliar se vale sair de um Gem para Skills
Eu começaria identificando o que realmente é reutilizável. Se o seu assistente sempre cumpre a mesma função, com contexto e formato estáveis, manter um Gem pode continuar sendo a opção mais simples. Se você precisa aplicar partes diferentes das instruções em tarefas variadas, Skills podem reduzir duplicação e facilitar a composição.
Depois, separaria instruções de contexto específico. Regras gerais de revisão podem ser reutilizadas; nomes de serviços, decisões arquiteturais e detalhes de uma tarefa pertencem ao contexto apropriado. Misturar tudo cria instruções longas e aumenta o risco de aplicar uma regra local onde ela não faz sentido.
Por fim, não migraria processos críticos sem verificar disponibilidade, controles de compartilhamento e comportamento real no produto. Como a mudança descrita é gradual, recursos e detalhes podem variar. Para times, documentar as instruções em um repositório versionado também evita depender exclusivamente de uma configuração acessível apenas pela interface.
FAQ sobre Skills e Gems no Gemini
O que são Skills no Gemini?
Na descrição citada pelo Eurisko.com.br, são conjuntos de instruções reutilizáveis que podem ser chamados em diferentes conversas e combinados conforme a tarefa. Isso as diferencia da ideia de um assistente personalizado que funciona como um ambiente separado.
As Skills substituem completamente os Gems?
A fonte descreve uma substituição gradual, mas não informa todos os detalhes de disponibilidade ou migração. Eu não presumiria que cada Gem será convertido automaticamente. Confira as opções exibidas na sua conta e preserve as instruções importantes.
Uma Skill consegue acessar meu repositório ou executar código?
Uma instrução, por si só, não concede acesso a arquivos nem executa comandos. Para isso, é necessária uma integração ou ferramenta com permissões apropriadas. Separe o que o modelo deve fazer daquilo que o sistema está tecnicamente autorizado a executar.
Skills são melhores que Gems para programar?
Depende do fluxo. Para um único assistente com comportamento consistente, um Gem pode ser suficiente. Para combinar orientações de revisão, segurança e linguagem em tarefas diferentes, instruções modulares podem ser mais práticas — desde que não criem conflitos.
Para desenvolvedores, a oportunidade está em tratar instruções como parte da arquitetura do fluxo de trabalho: com responsabilidade clara, contexto mínimo e testes. A mudança de Gems para Skills pode favorecer esse modelo, mas o resultado depende menos do nome e mais da qualidade das instruções, dos limites de acesso e da validação das respostas.
Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto.