Antigravity 2.0 na prática: GEMINI.md, Skills, Workflows, Subagents, Hooks, MCP e outros recursos

Se você usa o Antigravity no seu dia a dia, existe uma grande chance de você estar preso em um ciclo repetitivo que drena sua energia sem você perceber.

O roteiro quase sempre é o mesmo: você abre a ferramenta, digita um comando enorme explicando tudo o que precisa, torce para a IA acertar de primeira e, quando ela erra, você gasta um tempão consertando o código na mão. No dia seguinte, começa tudo de novo.

Para criar uma coisinha rápida aqui ou ali, esse quebra-galho funciona.

O problema de verdade aparece quando o seu projeto começa a ganhar corpo. É nesse ponto que o seu fluxo de trabalho começa a ruir e você nota alguns sinais bem frustrantes:

• Você precisa escrever textos cada vez maiores para a IA não se perder.
• O assistente começa a esquecer o que vocês combinaram minutos atrás.
• As instruções antigas começam a bater de frente com as novas.
• O código fica bagunçado, parecendo uma colcha de retalhos.
• Você perde um tempão refazendo tarefas que deveriam ser simples.

Quando isso acontece, a reação mais comum é cruzar os braços e pensar: “É, a Inteligência Artificial ainda não está pronta para um projeto de verdade.”

Mas a grande verdade é que a culpa não é da tecnologia. O erro está em tentar programar com IA sem antes arrumar a casa e organizar o contexto.

É exatamente aí que o jogo vira. Existe um abismo gigante entre:

conversar com uma IA

e:

criar um ambiente organizado de desenvolvimento assistido por IA

A maioria das pessoas só ouviu falar do arquivo GEMINI.md, e olhe lá. Mas o que quase ninguém te conta é que o Antigravity esconde um verdadeiro arsenal de ferramentas debaixo do capô.

Imagine não precisar mais improvisar. Em vez disso, você aprende a criar regras fixas que a IA nunca esquece, cria atalhos inteligentes para tarefas repetitivas, organiza a documentação do seu jeito e até escala “especialistas virtuais” para trabalharem focados em problemas complexos, enquanto você faz outra coisa.

Ao adotar essa postura, você transforma sua rotina. O improviso dá lugar a:

• Uma estrutura onde tudo tem o seu lugar certo.
• Regras e padrões de código que são seguidos à risca.
• Processos automáticos que funcionam mesmo se você não estiver olhando.
• Múltiplos assistentes trabalhando juntos e em paralelo para você.

Neste guia prático e direto ao ponto, nós vamos desmistificar todo esse ecossistema. Você vai descobrir, sem termos técnicos complicados:

• A utilidade real do GEMINI.md (e do AGENTS.md).
• Onde ficam guardadas as memórias das suas conversas e como usá-las.
• Como organizar o seu projeto usando a pasta docs/ e as rules.
• A diferença prática entre workflows e skills.
• O poder dos subagents (os seus especialistas dedicados).
• Como automatizar tudo com hooks e conectar o mundo externo via MCP.
• O que você deve compartilhar no Git e o que deve guardar só para você.

Esqueça a ideia de decorar códigos, nomes de pastas ou comandos complexos. O nosso objetivo aqui é fazer você entender a engrenagem por trás da ferramenta.

Afinal, o verdadeiro segredo não está no aplicativo que você instalou, mas sim na sua capacidade de organizar o conhecimento e os processos do seu sistema. É isso o que traça a linha definitiva entre:

Vibe Coding

e:

desenvolvimento assistido por IA

O que é o Antigravity 2.0?

O Antigravity 2.0 é a central de comando de agentes de IA do Google para desenvolvimento de software.

A diferença para um chat comum é enorme. No Antigravity 2.0, o agente pode:

• trabalhar dentro da pasta do projeto;
• ler, criar e editar arquivos;
• entender a estrutura do codebase;
• seguir padrões e regras;
• rodar múltiplos subagentes em paralelo;
• executar tarefas agendadas de forma autônoma;
• controlar o Chrome para testar aplicações;
• executar fluxos de desenvolvimento completos com mínima intervenção humana.

Em vez de você explicar tudo novamente a cada conversa, você cria arquivos que ensinam ao agente como aquele projeto funciona.

A lógica é:

Você organiza o contexto e o Antigravity trabalha seguindo esse contexto.

Isso evita repetir instruções como:

Use PHP 8.3.
Use MySQL.
Use Bootstrap.
Siga MVC.
Não misture SQL na view.

Você escreve isso uma vez no lugar certo, depois o Antigravity usa essas informações durante o desenvolvimento.

O que mudou do Antigravity 1.0 para o 2.0

O Antigravity original, lançado em novembro de 2025, era uma IDE baseada no VS Code com um assistente de código inteligente integrado. Era capaz, mas limitado.

O Antigravity 2.0 foi construído do zero como uma aplicação desktop standalone. Ele não é uma atualização da IDE, é uma mudança de paradigma completa. A IDE continua disponível como produto separado para quem precisa de um ambiente de edição de código tradicional.

Com o 2.0, o ecossistema Antigravity se divide em quatro pilares:

• Antigravity 2.0 Desktop App: aplicação standalone para orquestrar múltiplos agentes em paralelo, agendar tarefas e gerenciar projetos complexos;
• Antigravity IDE: a IDE original, baseada em VS Code, recomendada para quem prefere edição de código tradicional integrada com agentes;
• Antigravity CLI: ferramenta de linha de comando construída em Go, substitui o Gemini CLI;
• Antigravity SDK & API: permite integrar o mesmo motor de agentes do Google nos seus próprios sistemas.

Como instalar o Antigravity 2.0

Antes de criar arquivos como GEMINI.md, rules, skills ou workflows, você precisa instalar o Antigravity.

Existem três formas principais de usar o Antigravity:

1. Pelo aplicativo desktop (Antigravity 2.0)
2. Pela IDE (Antigravity IDE)
3. Pela CLI (Antigravity CLI, no terminal)

Instalando o Antigravity 2.0 Desktop

A página oficial de downloads fica em:

👉 https://antigravity.google/download

Nessa página, você encontra os instaladores para macOS, Windows e Linux.

A vantagem do aplicativo 2.0 é que ele foi projetado especificamente para orquestração de agentes. Ele oferece uma interface visual para lançar múltiplos agentes em paralelo, revisar artefatos como planos de implementação e planos de tarefa, gerenciar conversas organizadas por projetos e configurar tarefas agendadas que rodam automaticamente em segundo plano.

Após instalar, execute o aplicativo e faça login com sua conta Google. Na primeira vez, o Antigravity vai pedir para você escolher um preset de comportamento do agente:

• Agent-driven development: máxima autonomia, o agente decide e executa tudo;
• Agent-assisted development: equilíbrio recomendado, o agente decide mas pede aprovação nos momentos importantes;
• Review-driven development: o agente sempre pede revisão antes de agir;
• Custom configuration: você configura cada permissão manualmente.

Para começar, o Agent-assisted development é a escolha mais segura.

Instalando o Antigravity IDE

Se você prefere continuar com uma experiência de IDE tradicional integrada com agentes, baixe o Antigravity IDE separadamente na mesma página de downloads.

O Antigravity IDE é recomendado para desenvolvedores que querem trabalhar diretamente no código, revisar diffs dentro do editor e continuar usando uma interface familiar de edição.

Se você já tem o Antigravity 1.x instalado, a atualização para a versão mais recente vai transformá-lo no Antigravity IDE. Você pode baixar o Antigravity 2.0 Desktop separadamente e ter os dois instalados ao mesmo tempo, o que é altamente recomendado.

Instalando a CLI (Antigravity CLI)

Para quem prefere o terminal, o Antigravity CLI é a ferramenta certa. O comando da CLI é agy.

A CLI foi construída do zero em Go e é mais rápida que o Gemini CLI que ela substitui. Ela usa o mesmo motor de agentes do Antigravity 2.0 Desktop, então qualquer melhoria que o Google lança no núcleo do agente chega automaticamente para os dois.

Para instalar:

Windows CMD

curl -fsSL https://antigravity.google/cli/install.cmd -o install.cmd && install.cmd && del install.cmd

Windows PowerShell:

irm https://antigravity.google/install.ps1 | iex

macOS, Linux ou WSL:

curl -fsSL https://antigravity.google/install.sh | bash

macOS com Homebrew:

brew install --cask antigravity-cli

Após a instalação, entre na pasta do seu projeto no terminal e execute:

agy

Esse comando inicia a sessão do Antigravity CLI naquele projeto.

Atenção: muitas vezes é necessário fechar e abrir novamente o terminal após a instalação.

💡 Dica de CLI (agy inspect): Ao iniciar o trabalho em uma pasta nova, execute o comando:

agy inspect

Ele faz uma varredura diagnóstica completa no ambiente do diretório e imprime na tela um resumo de tudo o que o assistente detectou (quais regras estão ativas no projeto, skills locais configuradas, servidores MCP conectados e o estado do contexto), funcionando como o ponto de partida ideal para alinhar o ambiente.

Depois de instalar

• Na primeira execução do app desktop ou da CLI, você vai autenticar com sua conta Google.
• A versão gratuita dá acesso a modelos como o Gemini 3.1 Pro.
• Para acessar o Gemini 3.5 Flash (o modelo padrão do Antigravity 2.0, que é cerca de quatro vezes mais rápido) e recursos avançados, você precisará de um plano pago.
• Planos corporativos contam também com a integração do Antigravity ao Gemini Enterprise Agent Platform no Google Cloud, fornecendo controles estritos de conformidade de dados corporativos.
• Um detalhe importante para a comunidade é que recursos como a orquestração e criação de Subagentes permanentes e customizados exigem o plano AI Ultra (ou superior), enquanto o plano AI Pro e a versão gratuita utilizam subagentes dinâmicos gerados em tempo real na própria sessão.

Qual opção escolher?

• Se você está começando e prefere uma interface visual, comece pelo Antigravity 2.0 Desktop.
• Se você já usa terminal no desenvolvimento, instale a CLI e use o agy.
• Se você quer continuar em uma IDE com editor de código integrado, use o Antigravity IDE.
• Na prática, muitos desenvolvedores usam os dois: o 2.0 Desktop para tarefas maiores e a IDE para edição de código.

Preparando o ambiente para usar todo o potencial do Antigravity

Se você chegou até aqui, já consegue instalar e começar a usar o Antigravity. Mas existe um ponto importante que faz toda a diferença na prática.

Para aproveitar todos os recursos da ferramenta, especialmente aqueles ligados à execução de tarefas automáticas e integração com serviços externos, é recomendado ter algumas ferramentas instaladas no seu computador.

As principais são:

• Git
• Node.js (com NPX)

Por que isso é importante

O Antigravity não funciona apenas como um chat com IA dentro do projeto.

Ele permite que o agente:

• execute comandos no terminal;
• manipule arquivos;
• rode scripts;
• interaja com o sistema operacional;
• automatize tarefas de desenvolvimento.

E é aqui que o Git e o Node.js entram.

O papel do Git e do Node.js

Git

O Git é a ferramenta de versionamento de código mais usada no mundo. Para o Antigravity, ele vai além de versionar: é através do Git que o agente consegue usar o terminal de forma completa, especialmente no Windows.

Sem o Git instalado no Windows, o Antigravity pode ficar limitado a um terminal menos capaz. No macOS e no Linux, o Git normalmente já vem instalado. No Windows, você pode baixar em git-scm.com.

Node.js e NPX

O Node.js é importante principalmente para quem quer usar servidores MCP, que são as conexões do Antigravity com ferramentas externas como Google Drive, Jira, Slack e outras.

Boa parte desses servidores é instalada e executada via NPX, que vem junto com o Node.js e permite rodar pacotes diretamente, sem precisar instalar tudo manualmente.

Se precisar de um guia completo para instalar o Node.js, preparei um passo a passo detalhado:

👉 Node.js e NPX — Guia completo para iniciantes

O que acontece se você não instalar

Sem essas ferramentas, o Antigravity ainda funciona, mas com limitações.

Você pode:

• conversar com o agente;
• gerar e editar código;
• criar e organizar arquivos.

Mas pode ter dificuldades quando o agente precisar:

• executar comandos no terminal;
• conectar com serviços externos via MCP;
• rodar scripts e automatizar tarefas mais completas.

Antes de começar: sobre comandos e interfaces

O Antigravity está disponível em três formatos: aplicativo 2.0 Desktop, IDE e CLI (agy). A grande maioria dos recursos e conceitos descritos neste artigo funcionam nos três ambientes, embora a forma de acessá-los possa variar.

No Desktop e na IDE, muitos recursos aparecem como botões, menus e painéis visuais. Na CLI, tudo é feito via comandos de texto. Se você não encontrar algum recurso na interface que está usando, pergunte diretamente no chat. O próprio agente te orienta para o caminho certo.

💡 Dica de Acessibilidade: O Antigravity 2.0 agora conta com suporte nativo a Transcrição de Voz. Tanto no Desktop quanto na IDE, você pode clicar no ícone de microfone na barra de digitação (ou usar o atalho de teclado Ctrl + M) para ditar suas instruções por voz. A fala é convertida em texto em tempo real diretamente no prompt, sendo ideal para dar feedbacks rápidos ou revisões.

Arquivos locais e globais do Antigravity

Antes de entender GEMINI.md, rules, skills ou workflows, existe um conceito importante que costuma confundir iniciantes: local vs global.

Essa diferença é mais simples do que parece.

Pense assim

• Arquivos locais: Pertencem apenas ao projeto atual.
• Arquivos globais: Ficam disponíveis para qualquer projeto do seu computador.

O que significa ~?

Ao longo da documentação do Antigravity, você verá caminhos como:

~/.gemini/

O símbolo ~ representa a pasta do usuário no sistema operacional.

Por exemplo:

Windows:

C:\Users\SeuUsuario\

Linux:

/home/seu-usuario/

macOS:

/Users/seu-usuario/

Então ~/.gemini/ significa: a pasta global do Antigravity no seu computador.

Estrutura local do projeto

Quando algo pertence apenas ao projeto atual, normalmente fica dentro da pasta:

.agents/

Exemplo:

meu-sistema/
├── .agents/
│   ├── rules/
│   ├── skills/
│   ├── workflows/
│   └── agents.md
├── GEMINI.md

Tudo isso pertence apenas àquele sistema.

Estrutura global do Antigravity

O Antigravity também possui uma estrutura global no computador do usuário.

Exemplo:

~/.gemini/
├── GEMINI.md
└── antigravity/
    └── skills/

Esses recursos ficam disponíveis em qualquer projeto da máquina.

Quando usar arquivos globais?

Arquivos globais funcionam muito bem para coisas que você reutiliza constantemente.

Por exemplo:

• regras pessoais de codificação;
• skills genéricas;
• preferências que valem para qualquer projeto.

Exemplo:

~/.gemini/antigravity/skills/revisar-codigo/SKILL.md

Essa skill pode funcionar em vários projetos diferentes.

Quando usar arquivos locais?

Arquivos locais fazem sentido quando o conteúdo depende daquele projeto específico.

Por exemplo:

• regras do ERP da empresa;
• arquitetura do projeto;
• padrões internos;
• workflows específicos do negócio.

Exemplo:

.agents/rules/financeiro.md

Essa rule provavelmente não faz sentido fora daquele sistema.

Regra simples para não se perder

Uma pergunta ajuda bastante:

Isso pertence ao projeto ou pertence à minha máquina?

• Se pertence ao projeto: use estrutura local do projeto.
• Se pertence apenas ao seu computador (pode ser usado em vários projetos): use estrutura global.

Você não precisa escrever tudo sozinho

Depois de conhecer recursos como:

GEMINI.md
rules
skills
workflows
agents

é normal pensar:

Isso parece complicado demais para criar manualmente.

Mas existe um detalhe importante:

• Você pode usar o próprio agente para criar praticamente tudo isso.
• Na prática, é exatamente isso que quase todo mundo faz.
• Integração com o Google AI Studio: Agora o ecossistema permite que você inicie o desenho de fluxos, teste prompts ou prototipe o comportamento de agentes de forma rápida na interface web do Google AI Studio e, com um único clique, exporte todo esse contexto e configurações diretamente para o Antigravity local em sua máquina.

Pense assim

Você não precisa sentar e escrever um GEMINI.md perfeito do zero.

Também não precisa decorar:

• estrutura de skills;
• organização de rules;
• formato de workflows;
• padrões de documentação.

O agente pode ajudar em praticamente todo esse processo.

Exemplo simples

Você pode pedir:

Crie rules para um projeto PHP focadas em segurança e boas práticas.

E o agente pode gerar algo parecido com:

- usar prepared statements
- validar uploads
- nunca misturar SQL na view
- seguir PSR-12

O mais importante é: você não precisa acertar tudo na primeira versão. Com o tempo, a estrutura evolui naturalmente.

O que é o GEMINI.md?

O GEMINI.md é o principal arquivo de contexto permanente do projeto.

Pense nele como o “manual principal” que ensina ao agente como aquele sistema funciona.

É o lugar onde você organiza:

• objetivo do projeto;
• tecnologias utilizadas;
• arquitetura;
• padrões principais;
• estrutura do sistema;
• regras importantes que devem valer sempre.

Na prática, ele funciona como o ponto de partida do projeto dentro do Antigravity.

O problema que o GEMINI.md resolve

Quando as pessoas usam IA sem organização, normalmente acontece algo assim:

Todo dia elas repetem:

Use PHP 8.3.
Use MySQL.
Siga MVC.
Use Bootstrap.
Nunca misture SQL na view.

Com o tempo:

• os prompts ficam enormes;
• regras começam a se contradizer;
• partes importantes são esquecidas;
• o projeto perde consistência.

O GEMINI.md existe justamente para evitar isso.

Em vez de explicar tudo em cada conversa, você ensina uma vez no arquivo principal do projeto.

Pense no GEMINI.md como a “porta de entrada” do projeto

Uma forma simples de entender é imaginar alguém entrando na equipe pela primeira vez.

Essa pessoa precisaria de um documento inicial explicando:

• o que é o sistema;
• como ele funciona;
• quais tecnologias usa;
• quais padrões seguir;
• quais cuidados são importantes.

O GEMINI.md faz exatamente esse papel. Ele apresenta o projeto para o agente.

Onde o GEMINI.md fica?

O arquivo normalmente fica na raiz do projeto.

Exemplo:

financeiro-app/
├── GEMINI.md
├── app/
├── public/
├── database/
├── docs/
├── .agents/

GEMINI.md e AGENTS.md: qual usar?

Existe um detalhe importante aqui.

O GEMINI.md é específico para o Antigravity e para o Gemini. Ele funciona perfeitamente dentro do ecossistema Google.

O AGENTS.md é um formato mais genérico, compatível com outras ferramentas de desenvolvimento com IA como Cursor e Windsurf. Se os dois arquivos existirem no projeto, o AGENTS.md costuma ter precedência.

A escolha depende do contexto:

• Se o time usa apenas Antigravity: prefira GEMINI.md.
• Se o time mistura ferramentas diferentes: prefira AGENTS.md para garantir compatibilidade.

Os níveis de contexto no Antigravity

O Antigravity carrega instruções de forma hierárquica, do mais geral para o mais específico:

1. Nível global → fica em ~/.gemini/GEMINI.md, no computador do desenvolvedor. Aplica preferências pessoais em todos os projetos da máquina. Útil para padrões que você quer em qualquer projeto, como “sempre usar TypeScript” ou “nunca gerar chaves de API no código“.

2. Nível do projeto → é o GEMINI.md (ou AGENTS.md) na raiz do projeto, compartilhado com toda a equipe via Git. O mais comum e o que este artigo aborda principalmente.

Quando existem instruções em mais de um nível, o Antigravity combina os dois. O arquivo do projeto tem mais peso e pode sobrescrever preferências globais quando houver conflito.

Exemplo simples de GEMINI.md

# Sistema Financeiro

Este projeto é um sistema de contas a pagar e contas a receber.

## Tecnologias

- PHP 8.3
- MySQL 8
- Bootstrap 5

## Arquitetura

- MVC
- Repository Pattern
- Service Layer

## Regras importantes

- Nunca misturar SQL nas views.
- Sempre usar prepared statements.
- Controllers devem ser leves.
- Validar uploads de arquivos.

Quanto deve ter no GEMINI.md?

A recomendação é manter o GEMINI.md focado e conciso. Arquivos muito longos tornam o contexto mais pesado e fazem com que o agente siga as instruções com menos precisão.

Se o arquivo estiver crescendo demais, é sinal de que parte do conteúdo deveria ir para outros lugares, como rules em .agents/rules/, skills em .agents/skills/ ou documentação na pasta docs/.

O maior erro com GEMINI.md

Esse talvez seja o erro mais comum de todos.

Muita gente transforma o GEMINI.md em um “super prompt gigante“.

Misturando:

• arquitetura;
• segurança;
• deploy;
• frontend;
• backend;
• testes;
• checklists.

No começo parece funcionar, mas com o tempo vira bagunça.

Projetos organizados usam o GEMINI.md como:

visão geral
+
regras permanentes principais
+
referência para o restante do contexto

E não como um arquivo infinito.

GEMINI.md local e global

Na maioria dos casos, o GEMINI.md pertence ao projeto atual e vai para o Git junto com o restante do sistema.

Mas existe também o conceito de configurações locais da máquina. No Antigravity 2.0, essas configurações ficam no próprio painel de configurações do aplicativo (Project Settings), onde você pode definir permissões, ferramentas permitidas e outros comportamentos específicos para aquele computador, sem compartilhar com ninguém.

Para a CLI, você pode criar um arquivo .antigravity.md na raiz do projeto para guardar contexto específico daquele ambiente local, sem enviar para o Git.

Memória de conversas

O Antigravity 2.0 armazena todas as suas conversas automaticamente no seu computador.

Cada conversa gera um registro completo no diretório:

~/.gemini/antigravity/brain/<conversation-id>/

Dentro de cada conversa, você vai encontrar:

• Logs de interação (.system_generated/logs/): todos os seus prompts, respostas do agente, chamadas de ferramentas e mensagens do sistema, salvos em formato JSONL (JSON Lines). Útil para revisitar o que foi feito ou entender como o agente chegou a uma decisão.
• Artefatos gerados: arquivos como implementation_plan.md, task.md e walkthrough.md criados pelo agente durante o trabalho. São os planos e documentos de acompanhamento que o Antigravity produz para organizar tarefas maiores.

Por que isso importa?

Diferente de um chat que desaparece quando você fecha a janela, o Antigravity preserva todo o histórico de trabalho do projeto.

Isso significa que:

• você pode revisitar decisões tomadas em sessões anteriores;
• o agente tem acesso ao histórico da conversa atual dentro de uma sessão;
• artefatos como planos de implementação ficam salvos e podem ser consultados depois.

Como ver as conversas anteriores

No Antigravity 2.0 Desktop, existe uma opção de Conversation History no canto superior esquerdo da interface. Ela mostra todas as conversas organizadas por projeto.

Na CLI, use:

/resume

Esse comando lista sessões anteriores e permite retomar de onde parou.

O Project-centric approach e a organização por conversas

O Antigravity 2.0 consolida uma transição importante de paradigmas: do modelo “centrado em repositórios/pastas” para o modelo de Projects (Projetos).

Isso traz duas grandes vantagens práticas no desenvolvimento com agentes:

1. Multi-codebases: Um único “Projeto” no Antigravity pode gerenciar conversas e monitorar o contexto de múltiplas pastas e codebases completamente diferentes ao mesmo tempo.
2. Git Worktrees Nativos: Para suportar a orquestração paralela de agentes em segundo plano sem quebrar seu fluxo de trabalho, o Antigravity gerencia automaticamente diretórios em segundo plano por meio de Git Worktrees. Isso impede que subagentes executando rotinas automáticas paralelas alterem ou entrem em conflito com os arquivos locais do diretório ativo que você está editando no momento.

O Antigravity 2.0 usa uma abordagem centrada em projetos. Cada projeto é uma configuração de pastas que define o ambiente e o escopo do agente.

Dentro de cada projeto, você pode ter várias conversas separadas. Isso é importante porque:

• diferentes funcionalidades podem ter suas próprias conversas;
• o contexto de cada conversa é isolado, o que mantém o foco;
• o agente sabe exatamente em qual projeto está trabalhando.

Para criar uma nova conversa dentro de um projeto, basta clicar no + ao lado do nome do projeto no painel esquerdo.

O que é a pasta docs/?

A pasta docs/ é usada para guardar a documentação do projeto.

Pense nela como a “biblioteca” do sistema.

É o lugar onde você explica como o projeto funciona.

Por exemplo:

• regras de negócio;
• fluxo do sistema;
• estrutura dos módulos;
• funcionamento das telas;
• integrações;
• APIs;
• documentação técnica;
• decisões importantes do projeto.

Muita gente acha que documentação serve apenas para humanos. No Antigravity, ela também ajuda o agente a entender o sistema.

Observação importante

A pasta docs/ serve como a “biblioteca central” do seu sistema. É o lugar perfeito para você criar arquivos de texto simples (no formato Markdown, com a extensão .md) para explicar as regras de negócio do projeto, como funcionam as telas, as integrações de APIs ou os fluxos que o usuário faz no seu site.

Mas aqui vai uma “observação técnica importante” que pouca gente percebe: a pasta docs/ não é um recurso de fábrica ou uma ferramenta nativa da IA. Diferente das pastas de skills ou de subagentes (que precisam ter nomes exatos e específicos para a IA encontrar), a pasta docs/ é apenas uma convenção de organização. Os desenvolvedores, costumam usar esse padrão no mercado para deixar manuais e papéis arrumados dentro de qualquer projeto.

A IA não tem nenhuma linha de código secreta que diz “procure uma pasta chamada docs”. O que ela faz, na verdade, é ter a capacidade de ler e indexar os arquivos de texto do seu projeto para usá-los como base de conhecimento (contexto).

Ao criar uma pasta docs/ e colocar seus manuais ali dentro, você não está ativando um botão oculto da IA; você está apenas aplicando uma boa prática de mercado que facilita a vida da IA na hora de encontrar e ler os seus arquivos de documentação.

O problema que a pasta docs/ resolve

Quando não existe documentação organizada, começam a surgir problemas:

• ninguém lembra como o sistema funciona;
• regras de negócio ficam espalhadas;
• cada pessoa explica de um jeito;
• decisões importantes se perdem;
• o agente começa a responder de forma inconsistente.

E isso piora muito conforme o projeto cresce.

Onde a pasta docs/ fica?

Ela normalmente fica na raiz do projeto.

Exemplo:

meu-sistema/
├── GEMINI.md
├── docs/
├── app/
├── public/
├── database/
├── .agents/

Dentro dela, você pode organizar os assuntos em vários arquivos.

Exemplo:

docs/
├── arquitetura.md
├── regras-negocio.md
├── fluxo-financeiro.md
├── api.md
├── integracoes.md
└── deploy.md

Exemplo simples de documentação

Arquivo: docs/regras-negocio.md

Conteúdo:

# Regras de negócio

- Toda cobrança possui data de vencimento.
- Cobranças vencidas geram multa após 5 dias.
- Apenas administradores podem cancelar pagamentos.
- Relatórios financeiros devem considerar fuso horário UTC-3.

Agora o projeto possui um lugar centralizado explicando essas regras.

docs/ NÃO é a mesma coisa que rules

Essa diferença é extremamente importante. Muita gente mistura os dois.

docs/
Explica como o sistema funciona.

Exemplo:

• fluxo financeiro;
• regras de comissão;
• funcionamento do ERP.

rules
Explica como o agente deve trabalhar.

Exemplo:

• usar prepared statements;
• nunca misturar SQL na view;
• seguir MVC.

Uma forma simples de pensar é:

• docs/ – conhecimento sobre o sistema;
• rules – padrões técnicos do projeto.

Quando usar a pasta docs/?

A pasta docs/ funciona muito bem para:

• regras de negócio;
• documentação de APIs;
• fluxos do sistema;
• integrações;
• arquitetura;
• decisões importantes;
• documentação técnica.

Uma boa pergunta é:

Isso explica como o sistema funciona?

Se a resposta for sim, provavelmente pertence ao docs/.

Como fazer o Antigravity ler a sua pasta docs/?

Agora que você já sabe que a pasta docs/ é apenas uma forma de organizar seus manuais, você precisa ensinar o Antigravity a usá-la. Existem duas maneiras bem simples de fazer isso: uma automática e outra manual.

Maneira 1: Deixando no “piloto automático” usando o GEMINI.md

A melhor estratégia para projetos de médio e grande porte é usar o seu arquivo principal, o GEMINI.md, como um “guia” que aponta para a sua pasta de documentação.

Você pode adicionar uma seção de referências dentro do seu GEMINI.md ligando os assuntos aos arquivos de texto. Veja este exemplo:

# Sistema Financeiro (GEMINI.md)

## 📌 Documentação de Apoio
Sempre que precisar entender as regras do negócio ou o funcionamento das telas, consulte os arquivos abaixo:

- **Regras de Cobrança e Multas:** Veja o arquivo [docs/regras-negocio.md](docs/regras-negocio.md)
- **Integração com o Banco/API:** Veja o arquivo [docs/api-bancaria.md](docs/api-bancaria.md)
- **Fluxo das Telas do Usuário:** Veja o arquivo [docs/fluxo-telas.md](docs/fluxo-telas.md)

Como o Antigravity lê o GEMINI.md no início de cada conversa, ele vai enxergar esse mapa. Quando você pedir algo sobre finanças, ele saberá exatamente qual manual abrir na pasta docs/ para ler as regras antes de criar o código.

Maneira 2: Chamando direto no seu Prompt (Na conversa)

Se você estiver conversando com o assistente e quiser que ele use um manual específico para resolver uma tarefa pontual, você pode citar o caminho do arquivo diretamente na sua mensagem, de forma bem natural.

Veja alguns exemplos de como você pode pedir isso no chat:

Crie a página de listagem de clientes seguindo o padrão visual que eu documentei em docs/arquitetura.md.

ou:

Dê uma olhada no arquivo docs/regras-negocio.md e ajuste a função de cálculo de juros para que ela siga exatamente o que está escrito lá.

Ao ver o caminho do arquivo entre crases ou escrito de forma clara, o Antigravity localiza a pasta, abre o documento e usa aquela regra específica para te dar a resposta perfeita.

O que é .agents/rules/?

A pasta .agents/rules/ serve para guardar regras permanentes do projeto.

Essas regras funcionam como instruções que o agente deve seguir sempre durante o desenvolvimento, independentemente da tarefa.

Pense nelas como os padrões oficiais do sistema.

Por exemplo:

• nunca misturar SQL na view;
• sempre usar prepared statements;
• validar uploads de arquivos;
• controllers devem ser leves;
• seguir padrão MVC.

Essas instruções não deveriam ficar sendo repetidas em prompts o tempo inteiro. O Antigravity carrega as rules automaticamente no início de cada sessão. Você não precisa importar ou chamar nada, elas estão sempre ativas.

Pense nas rules como as “leis do projeto“

Uma forma simples de entender é imaginar uma empresa.

Toda empresa possui regras internas:

• padrão visual;
• regras de segurança;
• processos internos;
• forma correta de trabalhar.

As rules fazem o mesmo papel dentro do projeto.

Elas dizem ao agente:

Independentemente da tarefa, estas regras devem ser respeitadas.

Onde as rules ficam?

As rules normalmente ficam dentro da pasta:

.agents/rules/

Arquivos com extensão .mdc ou .md funcionam.

Exemplo:

.agents/rules/backend.md
.agents/rules/database.md
.agents/rules/security.md
.agents/rules/testing.md

Cada arquivo pode guardar um conjunto específico de regras.

Por que separar em vários arquivos?

Porque projetos crescem. No início, o sistema parece pequeno. Depois aparecem frontend, backend, APIs, banco de dados, testes, deploy, integrações.

Se tudo ficar dentro de um único arquivo enorme, o contexto vira bagunça.

Separar as rules ajuda a manter organização e clareza.

Por exemplo:

Regras de banco

.agents/rules/database.md

Regras de segurança

.agents/rules/security.md

Regras de testes

.agents/rules/testing.md

.md ou .mdc: qual extensão usar nas suas Rules?

Se você começar a observar as pastas de projetos que usam o Antigravity, vai reparar que algumas regras terminam com a extensão comum .md e outras terminam com .mdc. Embora pareçam quase iguais, existe um recurso que diferencia essas duas extensões.

O formato .md (o manual clássico)

O .md é o famoso Markdown, um arquivo de texto simples que serve para documentar coisas.

Como ele se comporta: Quando você joga uma regra em um arquivo .md dentro da pasta de regras, o Antigravity lê esse documento e deixa a regra ativa para o projeto inteiro de forma geral. É ótimo para padrões que valem para o sistema todo, mas o arquivo é “passivo“, ele fica ali esperando a IA lembrar de consultá-lo.

O formato .mdc (a regra com gatilho automático)

O .mdc é uma evolução do Markdown criada especialmente para o desenvolvimento assistido por IA. A grande mágica dele é que você pode colocar um cabeçalho de configurações no topo do arquivo (um painel de controle) dizendo para o Antigravity quando aquela regra deve ser ativada sozinha.

Imagine que você cria um arquivo chamado .agents/rules/banco-de-dados.mdc. No topo dele, você escreve o seguinte comando:

---
description: Ative esta regra sempre que eu estiver mexendo na pasta de banco de dados.
globs: "database/**/*"
---

# Regras de Banco de Dados
- Sempre use prepared statements para evitar invasões.
- Nunca faça consultas diretas na estrutura visual (views).

Por que isso é revolucionário?

Se você usar o formato .mdc com esse filtro (globs: "database//*"), o Antigravity ganha um “sensor de presença“. No segundo em que você pedir para ele criar ou editar qualquer arquivo que fique dentro da pasta database/, ele ativa essa regra imediatamente em segundo plano.

Isso garante que a IA siga as instruções de segurança do banco de dados na hora exata em que precisa delas, sem que você precise ficar digitando e lembrando a IA disso no prompt toda vez!

💡 Resumo para não esquecer: Use .md quando for uma regra geral que deve cobrir o projeto todo sem distinção. Use .mdc quando você quiser criar uma regra inteligente, que só “desperta” e entra em ação quando você ou a IA mexerem em uma pasta ou arquivo específico do sistema.

Exemplo simples de rule

Arquivo: .agents/rules/database.md

Conteúdo:

# Regras de banco de dados

- Nunca usar SQL diretamente nas views.
- Sempre utilizar prepared statements.
- Nunca concatenar dados do usuário em queries.
- Toda migration deve possuir rollback.
- Evitar SELECT * em queries do sistema.
- Criar índices para colunas usadas em filtros frequentes.

Agora essas regras ficam centralizadas em um único lugar. Você não precisa repetir isso em toda conversa.

Rules locais e globais

Assim como outros recursos do Antigravity, as rules podem ser locais ou globais.

Rules locais

Ficam dentro do projeto atual.

Exemplo:

meu-sistema/
├── .agents/
│   └── rules/
│       └── security.md

Use rules locais quando as regras fazem sentido apenas para aquele sistema. Essas rules normalmente vão para o Git junto com o projeto, porque toda a equipe deve seguir os mesmos padrões.

Rules globais

Rules globais ficam no arquivo ~/.gemini/GEMINI.md. Elas funcionam para preferências pessoais ou padrões que você usa em praticamente qualquer projeto.

Exemplo:

~/.gemini/GEMINI.md

Conteúdo:

# Minhas preferências globais

- Sempre usar TypeScript quando disponível.
- Documentar funções complexas.
- Evitar código duplicado.
- Priorizar legibilidade.

As rules globais carregam antes das rules do projeto. Se houver alguma contradição, a rule do projeto prevalece.

Quando usar rules?

Rules são perfeitas para comportamentos que devem acontecer sempre.

Elas funcionam muito bem para:

• padrões de arquitetura;
• segurança;
• convenções de código;
• organização de arquivos;
• padrões de banco;
• regras de testes;
• boas práticas;
• estrutura do projeto.

Uma boa pergunta para fazer é:

Isso deve valer sempre, independentemente da tarefa?

Se a resposta for sim, provavelmente isso deveria virar uma rule.

Quando NÃO usar rules?

Muita gente tenta transformar tudo em rule e isso também vira problema.

Rules não servem para tarefas operacionais.

Por exemplo:

Revise esta release e gere um changelog.

Isso não é uma regra permanente, é apenas um procedimento. Nesse caso, o melhor recurso é um Workflow.

Outro exemplo ruim para rules:

Gere uma mensagem de commit.

Isso é um processo pontual. Um Workflow com slash command faz mais sentido.

E existe outro caso importante:

Investigue gargalos de performance no banco.

Isso exige um especialista focado. Nesse caso, Subagents funcionam melhor.

Rule não é prompt

Esse é um ponto muito importante.

Rules existem para tirar instruções repetitivas de dentro dos prompts.

Sem rules, os prompts ficam assim:

Use MVC.
Não misture SQL na view.
Use prepared statements.
Valide uploads.
Crie testes.
Siga PSR-12.

Rules resolvem isso centralizando as decisões permanentes do projeto.

O que vai para o Git e o que não vai?

Git é o sistema usado para versionar projetos e compartilhar código entre desenvolvedores.

Tudo que vai para o Git pode parar na máquina de outras pessoas da equipe. Por isso, uma das decisões mais importantes em qualquer projeto é definir: o que deve ser compartilhado e o que deve permanecer local.

O que normalmente vai para o Git?

Vai para o Git tudo aquilo que faz parte do projeto e precisa ser compartilhado com a equipe.

Por exemplo:

GEMINI.md
docs/
.agents/rules/
.agents/skills/
.agents/workflows/
.agents/agents.md
app/
database/
public/

Esses arquivos ajudam outras pessoas a entender, executar e continuar o projeto. Também ajudam o agente a trabalhar seguindo os mesmos padrões para toda a equipe.

O que normalmente NÃO vai para o Git?

Arquivos locais, temporários, pessoais ou sensíveis normalmente não devem ser compartilhados.

Exemplo:

.antigravity.md
.env
logs/
tmp/
node_modules/
vendor/

Esses arquivos costumam conter:

• senhas;
• tokens;
• caminhos locais;
• arquivos temporários;
• dependências instaladas;
• configurações pessoais.

Por que isso é tão importante?

Imagine duas pessoas trabalhando no mesmo projeto.

Uma usa Windows, outra usa Linux.

Uma roda o sistema em:

C:\xampp\htdocs\

Outra usa:

/home/projeto/

Essas configurações não deveriam ficar misturadas no contexto compartilhado do projeto.

Por isso existe o .antigravity.md local (para a CLI) e as configurações de Project Settings no aplicativo desktop, que ficam na máquina local e não são enviadas para o repositório.

O papel do .gitignore

O arquivo .gitignore serve para dizer ao Git quais arquivos não devem ser enviados para o repositório.

Exemplo:

.env
node_modules/
vendor/
.antigravity.md
logs/
tmp/

Um erro muito perigoso

Um dos erros mais comuns de iniciantes é enviar arquivos sensíveis para o Git sem perceber.

Exemplo:

• senha do banco;
• token de API;
• credenciais de produção.

Isso pode virar um problema enorme, principalmente em repositórios públicos.

Regra simples para não se perder

Uma pergunta ajuda bastante:

Isso precisa existir na máquina de toda a equipe?

• Se a resposta for sim: provavelmente vai para o Git.
• Se a resposta for: “isso é pessoal, temporário ou sensível“, então provavelmente não deve ir.

O que são Workflows (e slash commands)?

Quando começamos a usar IA para programar, é comum repetir as mesmas instruções várias vezes.

Por exemplo:

Revise meu código.
Verifique riscos de segurança.
Sugira melhorias.
Gere uma mensagem de commit.

No primeiro dia isso parece normal, mas depois de alguns dias começa a ficar cansativo.

Foi exatamente para resolver esse problema que surgiram os Workflows no Antigravity.

Um Workflow é um processo reutilizável que pode ser acionado com um slash command.

Exemplo:

/revisar-release

ou:

/gerar-commit

Em vez de escrever um prompt enorme toda vez, você cria um “processo salvo“.

Você digita /gerar-commit e o agente já sabe o que precisa fazer.

Na prática, é como transformar prompts repetitivos em receitas de trabalho prontas para usar.

Onde os Workflows ficam?

Os Workflows ficam na pasta:

.agents/workflows/

Cada arquivo .md nessa pasta vira um slash command. O nome do arquivo determina o nome do comando.

Exemplo:

.agents/workflows/gerar-commit.md

vira:

/gerar-commit

A estrutura de um Workflow

Todo Workflow precisa de um YAML frontmatter no topo com, no mínimo, um campo description. Essa descrição é usada pelo agente para descobrir automaticamente quando o Workflow é relevante, mesmo sem você digitá-lo.

Exemplo:

---
description: Analisa as alterações do projeto e sugere uma mensagem de commit no padrão Conventional Commits.
---

## Gerar mensagem de commit

1. Analise as alterações não commitadas do projeto.
2. Resuma o que mudou em linguagem clara.
3. Identifique riscos importantes.
4. Sugira uma mensagem de commit seguindo o padrão Conventional Commits.
5. Não execute o commit automaticamente.

O painel de controle de um Workflow (campos YAML importantes)

Como vimos, todo Workflow começa com uma seção de configuração no topo chamada de YAML frontmatter, protegida entre três traços (---). O campo description é obrigatório para o Antigravity saber o que o comando faz, mas você pode usar outros campos para dar mais recursos ao seu atalho.

Aqui estão os campos mais importantes e úteis que você pode usar para personalizar seus comandos:

Campo	Para que serve	Exemplo prático de uso
description	(Obrigatório) Explica o objetivo do Workflow para que a IA saiba quando usá-lo.	description: Analisa o código e gera uma mensagem de commit.
name	Define um nome amigável para o comando na interface visual do aplicativo.	name: Formatador e Testador
arguments	Permite que você passe informações extras na hora de digitar o comando (variáveis).	arguments: [pasta, formato]
tools	Limita ou dá poderes de ferramentas específicas apenas para este fluxo.	tools: [Read, Write, Terminal]
timeout	Define o tempo máximo (em segundos) que a IA pode gastar tentando rodar esse fluxo antes de parar.	timeout: 120

Um exemplo real de como fica o topo do seu arquivo:

Se você quiser criar um Workflow super completo para rodar testes em uma pasta específica que você escolher na hora, o topo do seu arquivo .md ficaria mais ou menos assim:

---
name: Validador de Pasta Especial
description: Roda testes automatizados e gera um relatório apenas na pasta que o usuário escolher.
arguments:
  - name: pasta
    description: O caminho da pasta que será testada.
    required: true
tools: [Terminal, Write]
timeout: 60
---

## Passos do Workflow
1. Entre na pasta especificada no argumento `pasta`.
2. Execute o comando de testes no terminal.
3. Crie um arquivo de texto com o resumo dos erros encontrados.

Dica: Para quem está começando, o campo description já resolve 90% dos problemas! Mas conforme você for criando automações mais maduras para a sua equipe, usar arguments (para criar comandos personalizados) e tools (para controlar o que a IA pode ou não acessar naquele momento) vai deixar seus processos muito mais seguros e profissionais.

Turbo Mode

Existe um recurso muito útil chamado Turbo Mode.

Normalmente, o agente pede sua permissão antes de rodar comandos de terminal como npm install ou git push. Mas se você confia totalmente em um Workflow, pode autorizar que determinados comandos rodem automaticamente.

Adicione // turbo imediatamente acima do passo que deve rodar sem confirmação:

---
description: Roda os testes e formata o código automaticamente.
---

## Verificar qualidade

// turbo
npm run lint

// turbo
npm test

Use o Turbo Mode com cuidado. É poderoso, mas deve ser reservado para comandos que você tem certeza de que são seguros de rodar sem revisão.

Slash commands nativos do Antigravity

O próprio Antigravity já possui vários comandos prontos. Eles se dividem em dois grupos.

Comandos de controle

Comando	O que faz
/config	Abre as configurações do Antigravity
/settings	Exibe configurações e permissões da sessão atual
/permissions	Gerencia a lista de comandos permitidos e bloqueados
/resume	Retoma uma sessão anterior (CLI)
/rewind	Volta para um estado anterior da conversa
/agents	Gerencia subagents disponíveis
/tasks	Exibe tarefas agendadas
/skills	Lista skills disponíveis
/mcp	Gerencia servidores MCP conectados
/memory show	Exibe o contexto completo carregado na sessão

Comandos especiais do Antigravity 2.0

Comando	O que faz
/browser	Lança um subagente que controla o Chrome para interagir com páginas web
/schedule	Cria ou gerencia tarefas agendadas
/goal	Executa um agente de forma autônoma até atingir o objetivo especificado
/grill-me	Modo de revisão técnica aprofundada

Detalhando os novos comandos nativos de destaque:

• /grill-me (O comando “Me Questiona”): Antes de começar a implementar qualquer tarefa ou alteração complexa, o assistente ativa um fluxo interativo onde ele faz perguntas cirúrgicas e críticas de volta para você. Isso alinha perfeitamente as expectativas, clarifica requisitos e evita que a IA tome caminhos errados.
• /goal (Modo Focado Autônomo): Ativa a autonomia contínua. Sob o capô, esse comando aciona as capacidades de Managed Agents do Google, executando tarefas complexas e demoradas de forma assíncrona dentro de um ambiente virtualizado e seguro (sandbox) nos servidores da nuvem do Google. Você define uma meta (como “criar toda a suíte de testes de integração”) e o assistente passará a planejar, executar e verificar tudo em segundo plano, avançando sozinho até a conclusão completa do objetivo, sem parar para pedir inputs constantes.
• /browser (Navegação Web Direta): Abre uma instância segura e depurável do Google Chrome nos bastidores para que a IA interaja com sites dinâmicos, realize pesquisas aprofundadas ou extraia dados da web com controle absoluto.

Workflows locais e globais

Os Workflows podem existir em dois níveis diferentes:

Workflows locais

São Workflows criados dentro do projeto atual.

meu-sistema/
├── .agents/
│   └── workflows/
│       └── gerar-commit.md

Esses Workflows fazem sentido apenas para aquele sistema. Você normalmente coloca no Git para compartilhar com a equipe.

Workflows globais

Ficam disponíveis em qualquer projeto.

~/.gemini/antigravity/skills/meu-workflow/SKILL.md

Use Workflows globais quando você quer reaproveitar o mesmo processo em vários projetos.

Criando seu primeiro Workflow

Imagine que você sempre pede para o agente gerar mensagens de commit.

Crie o arquivo:

.agents/workflows/gerar-commit.md

Dentro dele:

---
description: Gera uma mensagem de commit analisando as alterações atuais do projeto.
---

Analise as alterações atuais do projeto.

Depois:

1. Resuma o que mudou.
2. Identifique riscos importantes.
3. Sugira uma mensagem de commit clara.
4. Use o padrão Conventional Commits.
5. Não execute o commit automaticamente.

Agora basta usar:

/gerar-commit

Quando um Workflow vira uma Skill?

Essa é uma dúvida comum.

A resposta simples é: quando o processo envolve procedimentos de referência mais complexos, com múltiplos arquivos de apoio, scripts ou lógica especializada, ele pode evoluir para uma Skill.

Na próxima seção vamos entender melhor o que são Skills e por que elas são mais poderosas.

O que são Skills?

Skills são pacotes de conhecimento especializado que o agente carrega sob demanda, apenas quando o que você está pedindo corresponde ao propósito da skill.

Pense em uma Skill como um manual especializado.

Ela explica:

• quando usar;
• o que fazer;
• em qual ordem fazer;
• quais cuidados tomar;
• qual resultado entregar.

A diferença para um Workflow simples é de escopo.

• Workflows são processos operacionais: receitas de tarefas.
• Skills são conhecimento especializado: instruções aprofundadas para um tipo de trabalho.

E aqui existe uma diferença muito importante em relação ao GEMINI.md e às rules:

As Skills só são carregadas quando o agente identifica que elas são relevantes para a sua solicitação.

O GEMINI.md e as rules estão sempre presentes no contexto da sessão. As Skills ficam “dormentes” até serem ativadas. Isso mantém o contexto limpo e o raciocínio do agente mais preciso, especialmente em projetos grandes com muitas skills.

Onde as Skills ficam?

Uma Skill fica dentro de uma pasta própria dentro de .agents/skills/, e dentro dessa pasta existe um arquivo principal chamado SKILL.md.

Exemplo:

.agents/skills/revisar-release/SKILL.md

Nesse caso, revisar-release é o nome da skill e SKILL.md é o arquivo com as instruções.

Globalmente:

~/.gemini/antigravity/skills/revisar-release/SKILL.md

Como o agente sabe quando usar uma Skill?

O processo funciona em três etapas:

1. Descoberta: no início de cada conversa, o agente lê a lista de skills disponíveis com seus nomes e descrições.
2. Ativação: se uma skill parece relevante para o que você pediu, o agente carrega o conteúdo completo do SKILL.md.
3. Execução: o agente segue as instruções da skill enquanto trabalha na sua tarefa.

Por isso, escrever uma boa descrição na skill é fundamental. Quanto mais claro você deixar o propósito, mais fácil fica para o agente usá-la no momento certo.

Você também pode chamar uma skill diretamente com:

/revisar-release

A estrutura completa de uma Skill

Uma Skill bem configurada tem duas partes: uma seção de configuração no topo e as instruções em si.

Arquivo: .agents/skills/revisar-release/SKILL.md

---
name: revisar-release
description: Revisa todos os arquivos alterados antes de publicar uma release. Verifica riscos de segurança, migrations e gera um resumo com checklist.
---

## Revisar release

Siga estas etapas:

1. Verifique quais arquivos foram alterados.
2. Procure mudanças arriscadas.
3. Confira se existem migrations novas.
4. Veja se há testes relacionados.
5. Aponte possíveis problemas de segurança.
6. Gere um resumo claro.
7. Monte uma checklist final antes da publicação.

Não publique nada automaticamente.
Sempre peça confirmação antes de executar qualquer ação irreversível.

Arquivos de apoio dentro da Skill

Uma Skill não precisa ter apenas o SKILL.md. Você pode adicionar outros arquivos dentro da mesma pasta para deixar a Skill mais completa.

Exemplo de estrutura:

.agents/skills/revisar-release/
├── SKILL.md           (instruções principais — obrigatório)
├── scripts/
│   └── verificar.sh   (script que o agente pode executar)
├── examples/
│   └── exemplo-bom.md (exemplo de como deve ser o resultado)
└── resources/
    └── checklist.md   (checklist detalhada)

No SKILL.md você menciona esses arquivos para que o agente saiba que eles existem e quando usá-los:

## Recursos adicionais

- Para a checklist completa, consulte [resources/checklist.md](resources/checklist.md)
- Para ver um exemplo de resultado esperado, veja [examples/exemplo-bom.md](examples/exemplo-bom.md)

Isso evita que o SKILL.md fique longo demais. O conteúdo detalhado fica nos arquivos de apoio e só é carregado quando necessário.

Campos YAML mais comuns para Skills

Assim como os Workflows, toda Skill profissional precisa de um pequeno painel de configuração no topo do arquivo SKILL.md, que fica protegido entre os três traços (---). É por meio desse cabeçalho (chamado tecnicamente de YAML frontmatter) que você define as regras de como e quando a IA deve ativar esse manual especializado.

Para as Skills, os campos mais importantes e mais usuais que você vai encontrar no mercado são:

Campo	Para que serve	Exemplo prático na Skill
name	Define o nome de identificação da Skill dentro do ecossistema do Antigravity.	name: revisar-release
description	(O mais importante!) Explica detalhadamente o propósito da Skill. A IA lê esse campo para decidir, sozinha, se o seu manual deve ser aberto baseado no que você pediu no chat.	description: Use quando o usuário pedir para revisar o código antes de publicar uma versão.
tools	Lista quais ferramentas o agente está autorizado a usar enquanto estiver executando os passos dessa Skill.	tools: [Read, Grep, Terminal]

Importante: Lembre-se de que as Skills não usam o campo de argumentos (arguments) que vimos nos Workflows. Isso acontece porque os Workflows são comandos que você digita manualmente no chat (como se fosse um atalho de teclado), enquanto as Skills são conhecimentos que ficam guardados e que a IA decide puxar sozinha de forma orgânica sempre que a description bater com a necessidade da conversa! Por isso, caprichar no texto da descrição é o verdadeiro segredo para ter uma Skill que funciona perfeitamente.

Skills locais e Skills globais

Skills locais

Ficam dentro do próprio projeto.

meu-sistema/
├── .agents/
│   └── skills/
│       └── revisar-release/
│           └── SKILL.md

Use uma Skill local quando ela faz sentido apenas para aquele sistema. Skills locais podem ir para o Git, porque fazem parte da organização do projeto.

Skills globais

Ficam na pasta pessoal do usuário.

~/.gemini/antigravity/skills/

Use Skills globais quando você quer reaproveitar o mesmo procedimento em vários projetos.

Sobre prioridade: Skills do projeto local sobrescrevem Skills globais com o mesmo nome.

Quando usar Skills?

Use Skills quando a tarefa tem conhecimento especializado que precisa ser consultado consistentemente.

Elas funcionam muito bem para:

• revisar release;
• gerar documentação;
• auditar segurança;
• criar plano de testes;
• padronizar revisão de código;
• preparar descrição de pull request;
• analisar performance;
• montar changelog.

Quando NÃO usar Skills?

Não use Skills para tarefas muito curtas ou simples. Um Workflow já resolve.

Também não use Skill para uma regra que precisa valer o tempo todo.

Exemplo:

Nunca misturar SQL dentro das views.

Isso não é Skill, isso é uma regra permanente do projeto. Faz mais sentido colocar no GEMINI.md ou em .agents/rules/.

Outro caso: se você precisa de um especialista separado para investigar algo com profundidade, talvez o melhor recurso seja um Subagent.

• A Skill fornece conhecimento especializado carregado sob demanda.
• O Subagent é um especialista separado com seu próprio contexto de trabalho.

Skill não é mágica

• Uma Skill não torna o agente perfeito. Ela apenas reduz improviso.
• Sem Skill, o agente depende muito do que você explicou naquela conversa.
• Com Skill, ele recebe um manual pronto para aquele tipo de tarefa.

É como entregar uma receita para alguém cozinhar. A pessoa ainda precisa executar bem, mas agora ela sabe os ingredientes, a ordem e os cuidados principais.

O que são Subagents?

Subagents são assistentes especializados que trabalham separadamente da conversa principal.

Na prática, eles funcionam como “especialistas da equipe“.

Por exemplo:

• especialista em segurança;
• especialista em MySQL;
• especialista em testes;
• especialista em debugging;
• especialista em arquitetura.

Mas existe um detalhe muito importante:

O principal objetivo dos Subagents não é apenas especialização. É separação de contexto.

O problema que os Subagents resolvem

Imagine esta situação: você está desenvolvendo uma funcionalidade nova.

Ao mesmo tempo, quer:

• revisar segurança;
• analisar performance;
• investigar bugs;
• revisar arquitetura;
• validar testes.

Se tudo acontecer na mesma conversa, o contexto começa a ficar enorme e bagunçado.

Com Subagents, em vez de fazer tudo na conversa principal, o agente cria “assistentes separados” para executar tarefas específicas. Cada um trabalha na própria janela de contexto, sem poluir a conversa principal. Quando termina, devolve apenas o resultado relevante.

O grande diferencial do Antigravity 2.0: agentes paralelos

Uma das funcionalidades mais marcantes do Antigravity 2.0 é justamente a capacidade de rodar múltiplos agentes em paralelo.

Enquanto você continua trabalhando, diferentes subagentes podem estar simultaneamente:

• Agente 1 → Analisando riscos de segurança no módulo financeiro;
• Agente 2 → Procurando gargalos de performance no banco de dados;
• Agente 3 → Verificando cobertura de testes.

Cada um trabalhando de forma independente, sem esperar o outro terminar.

Onde os Subagents ficam guardados?

Quando você decide criar seus especialistas permanentes no projeto, o Antigravity oferece total liberdade para você escolher como quer organizar a “casa“. Existem duas formas de estruturar esses arquivos locais, e você pode adotar a que for mais confortável para o tamanho do seu sistema:

Opção 1: Todos os especialistas juntos (arquivo único)

Para quem está começando ou tem poucos ajudantes virtuais, a forma mais prática é colocar todos eles dentro de um único arquivo chamado agents.md na raiz da sua pasta .agents/.

A estrutura fica bem enxuta:

meu-projeto/
└── .agents/
    └── agents.md  (Todos os subagents moram aqui dentro)

Para separar um funcionário virtual do outro dentro desse arquivo único, basta empilhar as configurações usando as divisórias de três traços (---) para abrir o painel de controle de cada um.

Opção 2: Cada um na sua gaveta (pasta organizada)

Se o seu projeto crescer e você começar a ter muitos especialistas (um para segurança, um para banco de dados, um para testes, um para frontend…), aquele arquivo único pode virar uma bagunça sem fim.

Para resolver isso, você pode simplesmente ignorar o arquivo anterior e criar uma pasta chamada agents/ dentro de .agents/. Dentro dela, você cria um arquivo .md separado para cada especialista:

meu-projeto/
└── .agents/
    └── agents/
        ├── security-reviewer.md  (Apenas as regras do especialista em segurança)
        ├── mysql-expert.md       (Apenas as regras do especialista em banco)
        └── tester-bot.md         (Apenas as regras do especialista em testes)

O Antigravity é esperto o suficiente para ler essa pasta inteira e recrutar todos os ajudantes que encontrar ali dentro!

E onde ficam os Subagents Globais?

Se você criou um especialista tão bom que quer usá-lo em qualquer projeto do seu computador (sem ter que copiar os arquivos para cada pasta nova), você pode guardá-lo na pasta global do Antigravity na sua máquina, no caminho:

~/.gemini/antigravity/

Dessa forma, o seu “funcionário virtual” fica disponível em segundo plano no seu sistema operacional, pronto para ser chamado em qualquer codebase que você abrir para trabalhar.

Como criar um Subagent

Cada Subagent é uma definição com nome, descrição, comportamento e ferramentas permitidas.

Exemplo no arquivo .agents/agents.md:

---
name: security-reviewer
description: Especialista em segurança PHP. Use quando precisar revisar riscos de segurança no código.
tools: [Read, Grep, Glob]
---

Você é um especialista em segurança PHP.

Sua função é:

- procurar SQL Injection;
- identificar falta de validação;
- encontrar senhas expostas;
- revisar uploads inseguros;
- analisar permissões;
- procurar riscos comuns em aplicações web.

Sempre entregue:

- resumo dos riscos;
- arquivos afetados;
- nível de prioridade;
- sugestões de correção.

Nunca altere arquivos automaticamente.

Campos YAML essenciais para subagents

Como os Subagents funcionam como verdadeiros “funcionários virtuais” focados em uma única tarefa técnica, o cabeçalho de configuração deles (o YAML frontmatter no topo do arquivo) serve para definir as regras de contratação desse especialista. É aqui que você define o que ele pode fazer, qual modelo de IA ele vai gastar e quais ferramentas ele tem permissão para usar.

Os campos mais importantes e específicos para configurar seus Subagents são:

Campo	Para que serve	Exemplo prático no Subagent
name	O nome de identificação do Subagent (como você vai chamá-lo no chat usando a arroba, ex: @auditor).	name: auditor-seguranca
description	Explica para a IA principal qual é a especialidade deste subagente, para que ela saiba quando deve delegar uma tarefa para ele.	description: Especialista em procurar brechas de segurança e códigos maliciosos.
tools	(Muito importante!) Funciona como uma trava de segurança. Diz exatamente quais ferramentas o subagente pode usar.	tools: [Read, Grep] (Nesse caso, ele só lê arquivos, ficando proibido de alterar seu código).
model	Permite que você escolha uma versão específica do Gemini para este subagente rodar, economizando seus créditos.	model: gemini-3.5-flash

Como fica o topo do seu arquivo de Subagent na prática:

Se você quiser criar um assistente focado puramente em ler o seu código e encontrar erros de digitação ou padrões quebrados, sem o risco de ele alterar nada sozinho, o topo do arquivo ficaria assim:

---
name: revisor-sintaxe
description: Assistente focado em analisar arquivos de código para encontrar erros de ponto e vírgula, funções mal escritas ou padrões fora do padrão PSR-12.
tools: [Read]
model: gemini-3.5-flash
---

Você é um revisor de código extremamente detalhista. Sua única função é ler os arquivos fornecidos pelo agente principal e listar erros de sintaxe. Não tente corrigir os arquivos, apenas aponte onde estão os erros e o que está quebrado.

Dica: Percebeu como o campo tools aqui funciona como um verdadeiro “crachá de acesso“? Se você criar um subagente e não colocar a ferramenta Write na lista de ferramentas dele, ele poderá analisar o seu projeto inteiro, mas nunca vai conseguir modificar ou apagar nenhuma linha de código da sua máquina. Isso dá um controle e uma segurança absurda para o desenvolvedor, permitindo soltar os subagentes para trabalhar sem medo de eles quebrarem o sistema!

Como os Subagents funcionam no seu plano?

Como vimos antes, a possibilidade de criar e salvar seus próprios Subagents permanentes na pasta do projeto é um recurso exclusivo dos planos mais caros, como o AI Ultra ou os planos para empresas.

Se você está usando o plano gratuito ou o plano Pro, precisa entender o que acontece na prática para não achar que seu sistema está com defeito. Vamos descomplicar:

1. Se você criar um arquivo de Subagent na pasta .agents/agents/

Você pode até criar as pastas e os arquivos Markdown com as regras do seu especialista, mas, se você estiver no plano gratuito ou Pro, o Antigravity vai ignorar esses arquivos. Na hora de rodar, os comandos visuais ou de texto para chamar aquele agente específico vão dar um aviso de que você precisa fazer um upgrade de plano.

2. Como usar Subagents se o meu plano é o Pro ou o Gratuito?

Não se preocupe, você não fica totalmente sem os especialistas! O Antigravity usa um recurso chamado Subagentes Dinâmicos em Tempo de Execução.

Funciona assim: quando você pede uma tarefa muito grande ou complexa (como “Faça uma revisão completa de segurança neste código”), a própria IA principal percebe o tamanho do desafio e cria “ajudantes temporários” na memória daquela conversa para realizar o trabalho.

• A vantagem: A tarefa é dividida e resolvida com mais inteligência.
• A desvantagem: Você não pode customizar as regras exatas desse ajudante, e ele “desaparece” assim que a conversa é encerrada.

3. E se eu instalar um Plugin que já vem com Subagents?

Os plugins são pacotes prontos que instalamos para ganhar superpoderes. Se você instalar um plugin que possui subagents (mesmo estando no plano gratuito ou Pro), a instalação vai funcionar perfeitamente!

O que o Antigravity faz nos bastidores é um “reajuste“: em vez de registrar esses subagents do plugin como especialistas fixos e independentes na sua máquina, ele lê o manual deles e os transforma em subagentes dinâmicos. Eles vão trabalhar para você dentro daquela sessão, mas de forma temporária.

🚨 Atenção com suas cotas diárias: Subagentes gastam muito mais requests do que uma conversa comum, pois eles conversam entre si em segundo plano. Se você estiver na versão gratuita (que tem poucas requisições por dia), um plugin com subagentes pode esgotar toda a sua cota diária em poucos minutos. Use com moderação!

Como chamar um Subagent?

Existem três formas:

1. Pedindo em linguagem natural:

Use o subagent security-reviewer para analisar este módulo.

2. Usando @-mention:

@security-reviewer analise os arquivos de autenticação

3. Deixando o agente decidir:

Faça uma análise profunda de segurança neste sistema.

Se o agente identificar que existe um Subagent adequado para isso, ele o aciona automaticamente.

Subagents em segundo plano

Subagents podem rodar em dois modos:

• Em primeiro plano → A conversa principal fica pausada enquanto o Subagent trabalha;
• Em segundo plano → O Subagent trabalha enquanto você continua usando o Antigravity normalmente. Útil para tarefas longas que não precisam da sua atenção o tempo todo.

Para tarefas em segundo plano, você pode acompanhar o progresso no painel de conversas do Antigravity 2.0.

Quando usar Subagents?

Subagents são excelentes quando:

• a tarefa é muito especializada;
• a investigação pode gerar muito contexto;
• você quer separar análises da conversa principal;
• existem tarefas paralelas;
• o projeto é grande;
• você quer especialistas dedicados.

Exemplos muito bons:

• análise de segurança;
• investigação de bugs;
• revisão de arquitetura;
• análise de performance;
• otimização de banco;
• revisão de testes.

Quando NÃO usar Subagents?

Não use Subagents para tarefas simples.

Por exemplo:

Gerar mensagem de commit

Isso é simples demais. Um Workflow resolve melhor.

Também não use Subagents para regras permanentes do projeto.

Exemplo:

Nunca misturar SQL na view

Isso pertence ao GEMINI.md ou ao .agents/rules/.

Skill e Subagent NÃO são a mesma coisa

Isso costuma confundir muita gente.

• Uma Skill é conhecimento especializado carregado sob demanda.
• Um Subagent é um especialista com contexto próprio e separado.

Skill: instruções aprofundadas para um tipo de tarefa.

Subagent: especialista separado que trabalha de forma independente.

A Skill fornece o manual. O Subagent executa como um expert separado.

Tarefas agendadas: o agente que trabalha enquanto você dorme

Uma das funcionalidades mais interessantes do Antigravity 2.0 é justamente o agendamento de tarefas.

Em versões anteriores, se você queria que o agente fizesse algo, precisava estar presente para pedir. Agora você pode configurar tarefas que rodam automaticamente em horários específicos, sem nenhuma intervenção sua.

O que são tarefas agendadas?

Uma tarefa agendada é um prompt que o Antigravity executa automaticamente no dia e horário que você definir.

Exemplos de uso:

• Gerar um relatório de mudanças todo domingo às 23h;
• Rodar uma análise de segurança toda madrugada;
• Verificar dependências desatualizadas toda segunda de manhã;
• Enviar um resumo de progresso toda sexta às 17h.

Como criar uma tarefa agendada

No Antigravity 2.0 Desktop, acesse a opção Schedule no menu principal.

Clique em New e preencha:

• Nome da tarefa: uma descrição curta do que ela faz;
• Projeto: em qual projeto a tarefa deve rodar;
• Frequência: diária, semanal, mensal ou uma data específica;
• Horário: quando executar;
• Prompt: o que o agente deve fazer quando a tarefa disparar.

Pela CLI, use o slash command:

/schedule

Exemplo prático

Uma tarefa que lembra você de uma reunião diária às 17h:

Nome: Lembrete reunião diária
Frequência: Diária
Horário: 17:00
Prompt: Me lembre que tenho reunião em 30 minutos. Verifique se há alguma tarefa pendente no projeto que devo mencionar.

Ou uma tarefa semanal de revisão de segurança:

Nome: Revisão de segurança semanal
Frequência: Toda segunda-feira
Horário: 09:00
Prompt: Faça uma revisão de segurança nos arquivos modificados esta semana. Use o subagent security-reviewer e gere um relatório resumido.

O prompt pode ser simples ou complexo, pode chamar skills, workflows e subagents normalmente.

📌 Nota importante: As tarefas agendadas rodam em segundo plano, mas se você estiver usando o Antigravity 2.0 instalado direto no seu computador (plano gratuito ou Pro), a sua máquina precisa estar ligada e conectada à internet para o gatilho funcionar. Deixar o notebook fechado na mochila significa que a tarefa não vai rodar até você abri-lo de novo! A automação 100% independente (com o computador desligado) é um recurso voltado para grandes empresas integradas à nuvem do Google Cloud.

Hooks: automatizando ações ao redor do agente

Existe um recurso chamado Hooks que permite executar ações automáticas antes ou depois de o agente fazer alguma coisa.

A ideia é simples: você define um gatilho e um comando. Quando o gatilho acontece, o comando roda automaticamente, sem depender de o agente lembrar ou decidir fazê-lo.

Por que isso é útil?

O GEMINI.md e as rules ensinam o agente a seguir padrões. Mas o agente ainda é uma IA tomando decisões. Em alguns momentos, especialmente em projetos com regras críticas, você não quer depender da decisão dele.

Hooks resolvem isso de forma determinística. Eles simplesmente acontecem, independentemente do que o agente decidiu fazer.

Exemplo prático: você quer que o código seja formatado automaticamente toda vez que o agente editar um arquivo. Sem hook, você precisaria confiar que o agente vai lembrar de formatar. Com hook, a formatação roda automaticamente após cada edição, sem exceção.

Exemplos de uso

Alguns casos onde Hooks fazem diferença:

• Formatar código automaticamente após cada arquivo editado pelo agente;
• Rodar o linter antes de cada commit para garantir que o código está limpo;
• Registrar em log quais arquivos o agente modificou durante a sessão;
• Validar comandos antes de o agente executá-los no terminal, bloqueando operações perigosas;
• Notificar quando o agente terminar uma tarefa longa.

Como os Hooks se encaixam no ecossistema

Até aqui, você viu recursos que orientam o comportamento do agente:

• GEMINI.md explica o projeto;
• rules definem padrões permanentes;
• skills fornecem conhecimento especializado;
• subagents especializam tarefas;
• workflows definem processos.

Todos esses recursos influenciam o agente, mas ainda dependem dele para agir.

Hooks são diferentes. Eles executam comandos do sistema operacional diretamente, fora do controle do agente.

É como ter um assistente que, independentemente do que o agente fizer, garante que certas ações sempre acontecem.

Onde os Hooks ficam configurados?

Se você estiver utilizando exclusivamente o aplicativo visual do Antigravity 2.0 Desktop, temos um detalhe importante: os Hooks não possuem botões, menus visuais ou comandos de chat dentro do aplicativo. Se você tentar procurar por eles nas configurações ou digitar /hooks na barra de conversas, o sistema vai retornar um aviso de “No matching results”.

Isso acontece porque os Hooks são ferramentas de automação feitas sob medida para quem trabalha diretamente com linhas de comando. A configuração e o gerenciamento deles funcionam assim:

Exclusivo da CLI (agy)

O comando

 /hooks

serve para listar ou gerenciar gatilhos é um recurso que funciona exclusivamente quando você está utilizando o Antigravity direto pelo terminal da sua máquina (a CLI agy).

Como eles rodam nos bastidores

Mesmo que o aplicativo Desktop não tenha um painel visual para os Hooks, o motor do Antigravity continua sendo o mesmo. Isso significa que, se você tiver um arquivo de configuração de ganchos configurado localmente na pasta do seu projeto, o aplicativo desktop vai respeitar e executar as regras (como formatar um código automaticamente) de forma silenciosa em segundo plano.

A forma mais fácil de criar

Como não há menus visuais para isso, a maneira mais simples para um iniciante configurar um gatilho é conversando diretamente com o agente no chat e pedindo para ele criar a automação no código do projeto:

Crie a estrutura de um hook local para formatar automaticamente meus arquivos toda vez que você editá-los.

Para quem os Hooks são recomendados?

Hooks são um recurso mais avançado. Para a maioria dos projetos e para quem está começando, o GEMINI.md, as rules, os workflows e as skills já resolvem bem.

Hooks começam a fazer sentido quando:

• você precisa de garantias que não dependam da decisão do agente;
• o projeto tem regras críticas de segurança ou qualidade;
• você quer automatizar verificações que hoje faz manualmente;
• a equipe precisa de consistência absoluta em determinados processos.

MCP: conectando o agente às suas ferramentas

Por padrão, o Antigravity trabalha dentro do seu projeto. Ele lê arquivos, edita código, roda comandos no terminal e entende a estrutura do sistema.

Mas e se você quiser que ele também acesse o Jira para atualizar um ticket? Ou leia um documento no Google Drive? Ou busque informações no Slack?

É para isso que existe o MCP.

O que é MCP?

MCP é a sigla para Model Context Protocol, que em português significa Protocolo de Contexto de Modelo.

O nome técnico pode assustar, mas a ideia é simples:

MCP é um padrão que permite conectar o agente a serviços externos.

O MCP é um protocolo de padrão aberto desenvolvido originalmente pela Anthropic (criadora do Claude) no final de 2024 para unificar a conexão de IAs com fontes de dados. O Google abraçou esse padrão aberto e o adotou nativamente no Antigravity 2.0.

Pense como uma tomada universal. Em vez de cada ferramenta criar uma integração diferente do zero, o MCP define um formato padrão que qualquer serviço pode usar para se conectar ao Antigravity.

O que você pode conectar?

O Google disponibiliza uma série de servidores MCP gerenciados diretamente na infraestrutura do Google Cloud. Alguns exemplos:

• Google Maps → o agente acessa dados de localização e mapas;
• BigQuery → consulta direta a banco de dados de grande escala;
• Cloud Run → gerencia e faz deploy de serviços;
• Firestore → acessa banco de dados em tempo real;
• Cloud Logging → lê logs de produção;
• Developer Knowledge → acessa a base de conhecimento oficial do Google para desenvolvedores.

Além dos servidores do Google, já existem conectores prontos para muitos serviços populares, como Jira, Slack, GitHub, Notion e outros.

Onde fica a configuração do MCP?

As configurações dos servidores MCP ficam no arquivo:

~/.gemini/config/mcp_config.json

Exemplo de configuração:

{
  "mcpServers": {
    "bigquery-mcp": {
      "serverURL": "https://bigquery.googleapis.com/mcp",
      "authProviderType": "google_credentials",
      "oauth": {
        "scopes": [
          "https://www.googleapis.com/auth/cloud-platform"
        ]
      },
      "timeout": 30000,
      "headers": {
        "x-goog-user-project": "SEU_PROJECT_ID"
      }
    },
    "developer-knowledge-mcp": {
      "serverUrl": "https://developerknowledge.googleapis.com/mcp",
      "headers": {
        "X-Goog-Api-Key": "SUA_API_KEY"
      }
    }
  }
}

Como isso muda o trabalho na prática?

Sem MCP, um fluxo comum é assim:

1. Você abre o Jira, copia a descrição do ticket;
2. Cola no Antigravity;
3. O agente gera o código;
4. Você volta ao Jira para atualizar o status manualmente.

Com MCP conectado ao Jira:

1. Você diz “implemente o ticket JRA-234“;
2. O agente lê a descrição direto do Jira, gera o código e atualiza o ticket.

O agente para de depender de você copiar e colar informações de um lugar para outro.

Gerenciando MCP no Antigravity

No Antigravity 2.0 Desktop, você pode gerenciar os servidores MCP em:

Settings → Customizations → MCP Servers

Lá você pode:

• ver quais servidores estão ativos;
• adicionar novos servidores via botão Add MCP+;
• desativar servidores específicos;
• ver quais ferramentas cada servidor expõe.

Na CLI:

/mcp

MCP por projeto

Um recurso importante do Antigravity é que você pode controlar quais servidores MCP ficam disponíveis em cada projeto específico.

Nas configurações de cada projeto (Project Settings), existe uma seção onde você define quais MCP Servers aquele projeto pode usar. Isso é muito útil para evitar que o agente tenha acesso a sistemas que não fazem sentido para aquele contexto específico.

Para quem o MCP é recomendado?

Assim como os Hooks, o MCP é um recurso mais avançado. Você não precisa dele para começar a usar o Antigravity de forma produtiva.

Faz sentido explorar o MCP quando:

• você repete com frequência o processo de copiar informações de outras ferramentas para o agente;
• o seu time trabalha com ferramentas de gestão como Jira, Linear ou Notion;
• você quer que o agente acesse dados em tempo real que ficam fora do repositório.

Plugins: compartilhando e instalando pacotes de contexto prontos

Ao longo deste artigo, você viu como construir skills, workflows, regras e até planejar o uso de conexões MCP do zero. Mas e se você não quiser criar tudo manualmente e preferir usar receitas que outras pessoas já testaram e aprovaram? É aí que entra o conceito de plugins.

No Antigravity 2.0, um plugin não é um programa de computador pesado que você instala clicando em uma loja de extensões ou digitando comandos complexos. Ele é, na verdade, um pacote pronto de arquivos de contexto. Pense nele como uma pasta organizada cheia de regras técnicas (.mdc), manuais especializados (SKILL.md) e atalhos de processos que alguém empacotou para facilitar a sua vida.

É como a receita de um bolo: você não precisa redescobrir as medidas dos ingredientes, basta seguir o manual que já vem pronto.

O que um plugin pode incluir?

Um único pacote de plugin pode conter qualquer combinação de:

• Skills prontas para uso técnico.
• Instruções para ativar subagents dinâmicos.
• Regras inteligentes (.mdc) com gatilhos automáticos.
• Configurações de atalhos e workflows úteis para o dia a dia.

Como instalar e usar plugins

Se você procurar um botão chamado “Plugins” nas configurações do aplicativo desktop ou tentar digitar o comando /plugin no terminal, você vai dar de cara com um aviso de erro ou “No matching results”. O Google não criou uma loja visual para isso. O ecossistema funciona de forma muito mais livre e direta, baseada em arquivos.

Na prática, você usa os plugins de duas formas:

Copiando a pasta para o projeto

Os desenvolvedores e a comunidade compartilham esses pacotes em sites como o GitHub. Para usar, você só precisa baixar a pasta do plugin e colá-la dentro do diretório .agents/ do seu sistema. O Antigravity identifica os novos arquivos e ativa os recursos na mesma hora.

Pedindo ajuda para o próprio Agente

Como a IA sabe navegar na internet, você pode passar o link de um plugin compartilhado e mandar no chat:

Instale as regras e os workflows deste link do GitHub diretamente na pasta de agentes do meu projeto.

O assistente vai fazer o download, arrumar os arquivos nas pastas corretas nos bastidores e te avisar quando terminar.

Posso criar e compartilhar meu próprio plugin?

Sim. Você não precisa pedir autorização ao Google ou registrar seu código em lugar nenhum. Tudo o que você precisa fazer é compactar a sua pasta .agents/ e enviá-la para os seus colegas de trabalho por e-mail, Slack ou colocá-la no repositório da empresa. Quando eles colarem esses arquivos na raiz dos projetos deles, o Antigravity da máquina deles passará a seguir exatamente as mesmas leis técnicas e processos que você configurou.

Quando vale a pena usar esse modelo de compartilhamento?

Esse trabalho com pacotes de contexto prontos faz sentido quando:

• Você quer começar um projeto rápido usando padrões de segurança e boas práticas de mercado sem ter que escrever tudo do zero.
• A equipe gerencia dezenas de sites ou sistemas e você quer garantir que a IA programe seguindo rigorosamente as mesmas regras em todos eles.
• Você quer reutilizar os seus atalhos pessoais (workflows) favoritos em qualquer projeto novo que iniciar na sua máquina.

Qual o melhor recurso para cada situação?

Depois de conhecer todos os recursos do Antigravity, muita gente fica com a mesma dúvida:

Mas afinal… quando eu uso cada um?

A melhor forma de entender é pensar que cada recurso resolve um tipo diferente de problema.

Visão rápida de todos os recursos

Recurso	O que é	Quando usar
GEMINI.md	Arquivo principal de contexto do projeto	Explicar visão geral, arquitetura e padrões principais
~/.gemini/GEMINI.md	Configuração global do usuário	Guardar preferências pessoais que valem para todos os projetos
.antigravity.md	Contexto local da máquina (CLI)	Guardar dados locais, caminhos e configurações sensíveis da máquina
docs/	Documentação do sistema	Explicar regras de negócio, fluxos e funcionamento do projeto
.agents/rules/	Regras permanentes do projeto	Definir padrões técnicos e comportamentos obrigatórios
.agents/workflows/	Workflows e slash commands reutilizáveis	Atalhos rápidos e processos com várias etapas
.agents/skills/	Skills especializadas carregadas sob demanda	Conhecimento aprofundado para tipos específicos de tarefas
.agents/agents.md	Subagents especializados	Delegar análises e investigações para especialistas separados
Tarefas agendadas	Prompts que rodam automaticamente	Automatizar verificações periódicas sem presença humana
Hooks	Comandos automáticos disparados por eventos	Garantir ações que não dependem da decisão do agente
MCP	Conexão com serviços externos	Integrar o agente com Jira, Google Drive, BigQuery e outros
Plugins	Pacotes prontos com skills, hooks, subagents e MCP	Instalar configurações completas sem montar tudo do zero

Pense assim

Uma analogia simples ajuda bastante:

• GEMINI.md → é a visão geral e as regras sempre presentes do projeto;
• docs/ → são os manuais do sistema;
• rules → são as leis técnicas;
• workflows → são os atalhos e processos operacionais;
• skills → são manuais especializados carregados só quando necessário;
• subagents → são especialistas separados;
• tarefas agendadas → são automações que rodam sem você estar presente;
• hooks → são as regras que executam automaticamente, sem depender do agente;
• MCP → são as pontes para o mundo fora do projeto;
• plugins → são extensões prontas que empacotam tudo isso junto.

Quando você entende essa separação, o Antigravity começa a fazer muito mais sentido.

O objetivo não é usar tudo

Outro ponto importante: você não precisa usar todos os recursos.

Projetos pequenos

Talvez precisem apenas de:

GEMINI.md
+
algumas rules

Projetos médios

Talvez já façam sentido:

docs/
workflows
skills

Projetos grandes

Aí sim começam a aparecer benefícios enormes com:

subagents
hooks
MCP
plugins
tarefas agendadas
documentação extensa
processos especializados
agentes paralelos

A regra mais importante

Se existir uma regra que resume tudo, talvez seja esta:

Não tente resolver organização com prompts maiores.

Quanto mais o projeto cresce, mais importante fica separar:

• contexto;
• documentação;
• regras;
• processos;
• especialistas;
• automações.

Outros recursos que valem explorar

O Antigravity tem ainda mais recursos que não aprofundamos neste artigo por serem mais técnicos ou voltados para usos específicos. Se você chegar num ponto onde o básico já não resolve, vale pesquisar cada um deles na documentação oficial em antigravity.google/docs.

Antigravity CLI (agy) → A ferramenta de linha de comando para quem prefere o terminal. Oferece a mesma capacidade de agentes do Desktop em um ambiente keyboard-first. Útil para integrar o Antigravity em pipelines de CI/CD e scripts de automação.

Antigravity SDK → Permite integrar o mesmo motor de agentes do Google nos seus próprios sistemas. Você define comportamentos de agente personalizados via arquivos Markdown de skill e os executa na sua própria infraestrutura. Ideal para equipes que querem incorporar capacidades de agente nos seus produtos.

Managed Agents via Gemini API → Com uma única chamada de API, você pode criar um agente que raciocina, usa ferramentas e executa código em um ambiente Linux isolado e persistente. O estado e os arquivos permanecem entre chamadas. Útil para automações backend e pipelines de dados.

Antigravity no Google Cloud → Para quem já usa Google Cloud, o Antigravity pode ser conectado diretamente aos seus projetos existentes, com controles de acesso e trilha de auditoria completa. Indicado para equipes enterprise.

Comandos de voz nativos → O Antigravity 2.0 suporta comandos de voz para controlar o agente. Alinhado com a integração de voz que o Google está implementando no Gmail e no Docs.

Subagentes dinâmicos em tempo de execução → Além de subagents definidos em arquivos, o Antigravity 2.0 permite que o agente crie subagentes temporários dinamicamente durante a execução de uma tarefa. Isso é especialmente útil para tarefas que precisam de diferentes especializações em momentos diferentes.

Antigravity IDE (para desenvolvimento de código) → Para quem ainda precisa de uma experiência de IDE tradicional com editor de código integrado, o Antigravity IDE continua sendo a melhor opção. Ele mantém o Agent Manager integrado ao editor e está especificamente otimizado para edição e revisão de código.

Esses recursos estão todos documentados em antigravity.google/docs e a documentação oficial é bem acessível. Vale uma explorada quando você já tiver o básico funcionando bem no projeto.

Conclusão

Muita gente ainda usa o Antigravity como se estivesse apenas conversando com um chatbot.

Os recursos do Antigravity 2.0 apresentados neste artigo mudam justamente essa lógica.

Em vez de depender apenas da conversa atual, você passa a construir um ambiente organizado para o agente trabalhar.

O projeto começa a possuir:

• contexto estruturado;
• documentação;
• regras permanentes;
• workflows reutilizáveis;
• conhecimento especializado sob demanda;
• especialistas separados;
• automações periódicas;
• automações que independem da decisão da IA;
• integração com as ferramentas que você já usa;
• agentes rodando em paralelo.

E isso muda completamente a qualidade do desenvolvimento.

• O agente deixa de trabalhar “no improviso“.
• Ele passa a trabalhar seguindo uma estrutura.

Essa talvez seja a principal ideia do artigo:

Desenvolvimento assistido por IA não é sobre criar prompts gigantes. É sobre organizar contexto.

Quando você organiza tudo corretamente, o projeto começa a ficar muito mais previsível, mais consistente e mais sustentável.

Principalmente em projetos longos e em equipes. E isso vale não apenas para o Antigravity.

Essa forma de pensar provavelmente vai se tornar cada vez mais importante em qualquer ambiente de desenvolvimento com IA.

Porque no futuro, a diferença não será apenas sobre “quem usa IA“. A diferença será sobre “quem sabe estruturar contexto para IA“.

No primeiro caso, você apenas conversa com a ferramenta. Isso é puro Vibe Coding.

No segundo, você constrói um ambiente real de desenvolvimento com contexto, regras, processos e organização. Isso é desenvolvimento assistido por IA.