Claude Code e Antigravity no mesmo time: como manter o mesmo padrão no repositório?

Fala aí, beleza? Time dividido em dois agentes é o novo jeito de perder o padrão do repositório sem ninguém perceber

A cena é sempre a mesma: metade da galera abriu o Claude Code, a outra metade tá no Antigravity, e cada agente lê um arquivo de regra diferente

Aí o commit sai em formato meio inventado, a revisão de PR de um dev cobra um monte de coisa e a do outro cobra quase nada, e a convenção de código que vocês combinaram no Slack vira lenda

O ponto é que o padrão não pode morar na ferramenta, nem na cabeça de cada dev

Ele tem que morar no repositório, versionado, lido pelos dois lados… é disso que esse post trata

O que você precisa antes de começar

Nada de PC da Nasa aqui, o setup é bem simples:

• Repositório sob controle de versão (o padrão só vale se ele for commitado e chegar em todo mundo)
• Antigravity na versão 1.20.5 ou superior, caso o time queira depender da leitura de regras via AGENTS.md, que entrou como melhoria nessa versão
• Um acordo prévio do time sobre o que é inegociável: padrão de mensagem de commit, checklist de PR e convenções de código

Esse terceiro item é o mais chato e o mais importante

Se o time não decidiu o padrão, nenhum agente vai decidir por vocês, ele só vai gerar código com a cara do prompt do dia 😅

O que NÃO serve como padrão de time:

Tome cuidado com essa parte, porque é onde muita gente se ferra

As regras globais do Antigravity ficam em ~/.gemini/GEMINI.md e valem pra todos os workspaces daquela máquina

Pré-inscrição Formação Claude Code

Domine o Claude Code do básico ao avançado

Você vai aprender a criar sistemas completos com Claude Code, sem precisar ser programador. Inscreva-se para ter acesso a um desconto de lançamento e bônus especiais!

Quero minha vaga

Do lado do Claude Code existe o escopo de usuário, em ~/.claude/, que também é pessoal

Os dois vivem no diretório pessoal, ou seja, não vão pro git e não chegam no colega

São ótimos pra sua preferência individual, e péssimos como padrão de projeto

Passo a passo: montando a camada de padrão no repositório

A ideia geral é uma só: escreve o padrão UMA vez, e faz cada agente apontar pra esse mesmo lugar

Se você já usou monorepo com config compartilhada, é bem parecido: tem a fonte, e tem os pontos de entrada que só importam a fonte

1. Escreva a fonte única de verdade em markdown curto

Cria uma pasta de padrões no repositório e quebra em arquivos pequenos, um assunto por arquivo:

docs/padroes/commits.md
docs/padroes/pull-request.md
docs/padroes/codigo.md

Quebrar assim não é firula, é por causa dos tetos dos dois lados: a documentação do Claude Code recomenda menos de 200 linhas por arquivo CLAUDE.md, porque arquivo grande consome mais contexto e derruba a aderência, e os arquivos de Rules e Workflows do Antigravity têm limite de 12.000 caracteres por arquivo

O erro comum deste passo: despejar tudo num arquivão único de "padrões da empresa" e achar que o agente vai seguir a regra lá do fim do arquivo

2. Aponte o Claude Code pra esses arquivos

Na raiz do repositório, o CLAUDE.md vira só uma capa que importa o resto com a sintaxe @:

# Padrão do projeto

Regras que valem para todo o repositório:

@docs/padroes/commits.md
@docs/padroes/pull-request.md
@docs/padroes/codigo.md

O CLAUDE.md é o arquivo de memória nativo do Claude Code e é lido no começo de toda sessão, e o que você importa com @ entra no contexto junto, logo no início

Vale lembrar de COMO ele carrega: o arquivo do diretório de trabalho e o dos diretórios pais entram no início da sessão, e o de subpasta é lido sob demanda, quando o Claude acessa arquivos daquela pasta

O erro comum deste passo: colocar a regra do repositório inteiro dentro de um CLAUDE.md de subpasta e estranhar que o agente ignorou ela na sessão que nunca tocou naquela pasta

3. Aponte o Antigravity pro mesmo conteúdo

Do lado do Antigravity, o local padrão atual das regras de workspace é .agents/rules (a pasta antiga .agent/rules, sem o s, continua funcionando por compatibilidade retroativa)

E dentro de um arquivo de Rules você referencia outros arquivos com @nomedoarquivo, sendo que caminho relativo é interpretado a partir da localização do próprio arquivo de Rules

# Padrão do projeto

@../../docs/padroes/commits.md
@../../docs/padroes/pull-request.md

Na versão 1.20.5 ou superior, o AGENTS.md também funciona como porta de entrada, já que a leitura de regras por esse arquivo entrou no changelog

O erro comum deste passo: assumir que o outro lado lê a mesma pasta

O Claude Code não lê AGENTS.md de forma nativa, e o pedido segue aberto na issue "Support AGENTS.md" do repositório oficial

Então sim: você mantém DOIS pontos de entrada, apontando pro mesmo conteúdo

4. Escolha o modo de ativação de cada Rule no Antigravity

Aqui tem um detalhe que o pessoal do Claude Code costuma não conhecer: as Rules do Antigravity têm modos de ativação diferentes

• Always On pro que é inegociável (padrão de commit, por exemplo)
• Glob pra convenção que só vale nos arquivos que casam com o padrão definido
• Model Decision pra regra situacional, com uma descrição em linguagem natural e o modelo decidindo
• Manual pro que o dev chama com @ no campo de entrada do Agent

O erro comum deste passo: deixar tudo em Manual e depois cobrar do colega uma regra que o agente dele nunca leu 😛

5. Versione a configuração do Claude Code

O Claude Code separa configuração em três escopos: usuário (~/.claude/, não vai pro git), projeto (.claude/ no repositório, compartilhado e commitado) e local (.claude/settings.local.json, pessoal, fora do versionamento)

Só o escopo de projeto serve como padrão de time

O .claude/settings.json é lido a partir do diretório onde a sessão roda e vale só pra aquele projeto, então commitar ele no controle de versão é o que dá a mesma configuração pra todos os colaboradores

.claude/settings.json         -> commitado, vale pro time
.claude/settings.local.json   -> pessoal, fora do git

Essa lógica de "o que fica versionado é o que o time herda" também é a mesma que vale pra compartilhar skills com o time, vale a leitura junto

O erro comum deste passo: colocar preferência pessoal no arquivo compartilhado e transformar o settings.json num campo de batalha de PR

6. Automatize o que não pode depender de boa vontade

Regra escrita ajuda, mas regra que roda sozinha ajuda MUITO mais

Do lado do Claude Code, os hooks são configurados editando o .claude/settings.json, e o comando /hooks lista o que está configurado

Do lado do Antigravity, o caminho equivalente são os Workflows: arquivos markdown com título, descrição e uma série de passos, executados no Agent com /nome-do-workflow

E olha que conveniente: a própria documentação cita responder a comentários de PR como exemplo de uso de Workflow

Uma nota que facilita a vida: o Claude Code recarrega os arquivos de settings quando eles mudam, sem exigir reinício da sessão, cobrindo os escopos de usuário, projeto, local e gerenciado, incluindo permissões e hooks

Ou seja, tu ajusta a regra e testa na hora, sem aquele ciclo de fechar e abrir tudo

Onde o padrão costuma quebrar (e o que colocar em cada caso)

Na prática o padrão não derrete por inteiro, ele derrete em pontos bem específicos

Mensagem de commit fora do padrão:

A regra de commit é curta por natureza, então ela é a candidata perfeita pra fonte única: um arquivo de poucas linhas, referenciado pelo CLAUDE.md com @ e pelo arquivo de Rules do Antigravity com @nomedoarquivo

O que é simétrico: os dois lados leem o mesmo texto

O que só existe de um lado: hooks, que no Claude Code são configurados no .claude/settings.json e listados com /hooks

Revisão de PR desigual:

Checklist de PR versionado no repositório, referenciado pelos dois pontos de entrada, e a revisão para de depender de quem pegou o PR naquele dia

O que só existe de um lado: o Workflow do Antigravity, invocado com /nome-do-workflow, com responder comentários de PR aparecendo como exemplo de uso na documentação

Convenção que só vale numa pasta ou tipo de arquivo:

Aqui os dois têm resposta, mas com mecânicas diferentes

No Claude Code você coloca um CLAUDE.md na subpasta, que é lido quando o Claude acessa arquivos daquela pasta

No Antigravity você usa uma Rule em modo Glob, aplicada aos arquivos que casam com o padrão definido

Repara numa coisa: os dois separam bem o que é contexto persistente do que é sequência de passos

No Antigravity isso é explícito, Rules dão contexto persistente e reutilizável no nível do prompt, e Workflows definem uma sequência estruturada de passos no nível da trajetória

O que a prática mostrou sobre rodar o mesmo prompt em ambientes diferentes

Agora um pedaço de experiência minha, e já aviso o recorte: o teste que eu fiz foi Codex contra Antigravity, não envolveu o Claude Code, então não estica a conclusão pra ele

Eu montei um teste com 5 prompts idênticos aplicados aos dois ambientes, na mesma ordem: setup e autenticação, upload de PDF, integração com IA, dashboard, landing page e polimento

Antes de começar, criei um arquivo de instruções do projeto descrevendo a análise do projeto, a stack, as regras que o projeto precisa seguir e os comandos que ele precisa rodar

E pra garantir que os dois lados partissem exatamente do mesmo padrão, eu copiei o arquivo criado num dos editores pra pasta do outro, em vez de gerar dois arquivos separados, e depois abri a pasta pelo outro lado só pra conferir visualmente que o conteúdo era o mesmo

Detalhe que já diz muito: criar esse arquivo foi mais simples no Antigravity, pelo menu de contexto da árvore de arquivos, e mais trabalhoso do outro lado

Eu também igualei as configurações antes de rodar, modelo mais avançado disponível em cada um e modo de trabalho equivalente, senão o teste já nasce torto

E fechei cada prompt com uma instrução explícita de escopo, proibindo o agente de criar o que não foi pedido, porque num teste anterior senti que as ferramentas passavam do combinado (e olha, ir além do pedido não é automaticamente ruim nem automaticamente bom, teve gente nos comentários me criticando por ter tratado um extra não solicitado como ponto positivo, e é um papo justo)

Sobre consumo, minha estimativa é que a cota do plano Pro do Codex não chegou a 50% durante os testes e a gravação do curso, considerando a cota de 4 horas e a semanal

Agora o que isso tem a ver com o post: mesmo com arquivo de instruções idêntico, mesmo modelo equivalente, mesmo prompt e mesma ordem, os dois ambientes não entregam a mesma coisa

Prompt igual não garante resultado igual

Por isso o padrão precisa estar escrito no repositório, e não na cabeça de cada dev nem no histórico de chat de cada um

É o mesmo raciocínio de quando você tenta manter o padrão das suas notas com a IA escrevendo: sem regra escrita, cada rodada inventa um formato novo

Ah, e sobre disparar vários agentes em paralelo no Antigravity: eu não percebi comunicação entre eles, precisava abrir cada um manualmente

No vídeo acima eu mostro o teste inteiro: o arquivo de instruções sendo criado e copiado pros dois lados, os 5 prompts rodando na mesma ordem e a comparação de recursos, onde eu achei os dois bem pareados, com leve tendência pro Codex no conjunto de recursos

Conclusão

O padrão sobrevive quando mora no repositório, não no agente

O conjunto mínimo versionado é bem enxuto: arquivos markdown curtos com a fonte única de verdade (commit, checklist de PR, convenções), o CLAUDE.md da raiz importando eles com @, os arquivos em .agents/rules referenciando o mesmo conteúdo com @nomedoarquivo, o AGENTS.md como porta de entrada no Antigravity 1.20.5 ou superior, e o .claude/settings.json commitado pra todo mundo rodar com a mesma configuração

O que fica de fora do git também precisa estar claro pro time: ~/.gemini/GEMINI.md e ~/.claude/ são pessoais, e .claude/settings.local.json é o lugar certo da sua preferência individual

Próximo passo prático? Abre um PR só com os arquivos de regra, combina com o time qual é a fonte única de verdade, e deixa os dois pontos de entrada apontando pra ela

Um PR pequeno, sem código de produção junto, que é pra discussão ser sobre o padrão e não sobre a feature 😀

Feito isso, tanto faz quem abriu Claude Code e quem abriu Antigravity, o repositório continua com a mesma cara

até o próximo post!