Como contribuir em um projeto open source com o Claude Code sem ter o PR recusado?

Seu PR não foi recusado porque o código estava ruim

Ele foi recusado porque ignorou as regras da casa

O cenário mudou rápido: um monte de projeto open source parou de tratar "contribuição com IA" como detalhe e escreveu regra própria sobre isso, às vezes num arquivo separado, às vezes no meio do guia de contribuição. E aqui vai a parte que muita gente esquece: quando você abre o Claude Code dentro do repositório de outra pessoa, ele entra como VISITANTE, não como dono da casa 🙂

Seu repositório pessoal é onde tu manda

O repositório dos outros é onde tu obedece

Por que tanto PR gerado por IA é recusado hoje

Tem estudo acadêmico olhando exatamente isso, e o resultado é meio constrangedor pro nosso lado

Um trabalho no arXiv montou um benchmark chamado RepoComplianceBench, com 106 issues de 49 repositórios que possuem regras de contribuição sobre IA

O que apareceu foi o seguinte: os agentes praticamente nunca vão atrás das regras de contribuição por conta própria

E olha esse número, porque ele explica muita coisa: recusa e escalonamento pra um humano ficaram em 0% nos quatro modelos testados

Ou seja, mesmo em repositório que PROÍBE contribuição gerada por IA, o agente simplesmente… contribui

Agora a parte boa, que é onde tu entra

O mesmo estudo mostra que um lembrete genérico, a citação literal da cláusula do repositório ou uma rodada de feedback elevam bastante a conformidade: a divulgação do uso de IA sobe pra faixa de 77% a 97% e a verificação pra 90% a 100%

Sacou o tamanho do salto? O modelo não é burro, ele só está sem o contexto certo

E o contexto que falta não é sobre a linguagem, nem sobre o framework

É sobre o REPOSITÓRIO

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

O que você precisa ter em mãos antes de começar

Antes de digitar o primeiro prompt, junta isso aqui:

• O repositório clonado localmente, não só aberto no navegador
• A issue que você pretende resolver, e a confirmação de que ela já foi aceita pelos mantenedores (issue aberta por qualquer pessoa não é issue aceita, cuidado nessa parte)
• O guia de contribuição do projeto, lido de verdade, não passado o olho
• O arquivo de política de IA, se existir: tem projeto que separou isso num arquivo próprio, como o AI_POLICY.md do Ghostty
• A checagem de que o projeto não proíbe contribuição gerada por IA

Esse último item é o que separa o PR aceito do PR fechado em cinco minutos

E existe um atalho pra isso: um repositório público que reúne as políticas de diferentes projetos open source sobre contribuições geradas por IA, o open-source-ai-contribution-policies

É um bom ponto de partida pra ter noção do terreno

Mas atenção, a fonte que vale é sempre a do projeto em si: agregador desatualiza, política de projeto muda

Passo a passo para contribuir com o Claude Code em um repositório que não é seu

A lógica aqui é uma só: você carrega a regra pro agente, o agente não sai caçando regra sozinho

1. Leia as regras do projeto e cole a cláusula LITERAL no prompt

Não escreva "siga o guia de contribuição do projeto" e vá tomar café

Abra o guia, copie o trecho que fala de escopo, estilo e uso de IA, e cole dentro do prompt, entre aspas mesmo

Lembra do estudo? Citação literal da cláusula é justamente uma das coisas que puxam a conformidade pra cima

O erro comum deste passo: assumir que o agente vai ler o CONTRIBUTING.md sozinho porque o arquivo está ali na raiz

2. Entenda como o Claude Code carrega contexto do repositório

A documentação oficial é clara sobre o que ele lê: arquivos CLAUDE.md são lidos no início de cada sessão, como instrução persistente do projeto

O carregamento acontece por directory walk, ou seja, ele caminha da pasta atual em direção à raiz do repositório coletando os CLAUDE.md que encontra pelo caminho

E arquivos referenciados por @caminho são carregados na abertura da sessão também (eles NÃO reduzem contexto, então nada de importar meio mundo de arquivo achando que sai de graça)

Tem ainda a memória de usuário, em ~/.claude/CLAUDE.md

Essa é SUA, vale pro seu fluxo pessoal em qualquer projeto, e é separada do arquivo do repositório

É como a diferença entre a regra da empresa e a sua mania de organizar a mesa: as duas existem, mas só uma delas o time inteiro precisa respeitar 😀

Se o projeto ainda não tem um CLAUDE.md, existe o comando /init, que guia a criação do arquivo pro projeto

Só que aqui vai o aviso: criar CLAUDE.md num repositório de terceiros é MUDANÇA no repositório dos outros, e mudança não pedida

O erro comum deste passo: confundir sua memória de usuário com regra do projeto e sair impondo seu padrão pessoal no código alheio

3. Use o modo de planejamento antes de deixar ele tocar em qualquer arquivo

O modo de planejamento do Claude Code faz pesquisa e propõe mudanças sem executá-las

Você entra com Shift+Tab ou prefixando o prompt com /plan, e as edições ficam bloqueadas até você aprovar o plano

/plan Leia a issue #482 e o guia de contribuição do projeto.
Regra literal do repositório: "<cole aqui a cláusula do CONTRIBUTING/AI_POLICY>".
Proponha a MENOR mudança que resolve a issue, sem refatorar nada fora dela.

Não é firula, é guardrail (limite): o agente lê, pesquisa e responde sem alterar arquivo nenhum

O erro comum deste passo: partir direto pro modo que edita, e aí quando você percebe já tem quinze arquivos tocados e nenhum deles estava na issue

4. Recorte o plano ao escopo da issue e corte a refatoração não pedida

Essa é a hora de ser chato com o plano

Leia item por item e pergunta: isso está na issue? Se não está, sai

Renomear variável "pra ficar melhor", trocar a lib de data, padronizar indentação do arquivo inteiro: tudo isso vira ruído no diff e transforma um PR de dez linhas num PR que ninguém quer revisar

E tem o outro lado, que é o estilo: o código novo precisa parecer com o código que já está lá

Esse cuidado de fazer o agente respeitar o padrão de código do projeto vale dobrado quando a casa não é sua

O erro comum deste passo: aprovar o plano rápido porque "ele pensou bem", sem cortar os extras

5. Resolva a atribuição do commit ANTES de commitar

O Claude Code adiciona uma atribuição no commit, controlada pela configuração attribution

O padrão de attribution.commit é "🤖 Generated with Claude Code", e attribution.pr vem vazio por padrão

Vale saber também que a configuração attribution tem precedência sobre a antiga includeCoAuthoredBy, que está depreciada (se você tem tutorial velho salvo, é isso que mudou)

Se o projeto pede ausência de marca, dá pra esconder toda a atribuição deixando commit e pr como strings vazias e sessionUrl como false:

{
  "attribution": {
    "commit": "",
    "pr": ""
  },
  "sessionUrl": false
}

E olha que importante: esconder a marca do commit NÃO é a mesma coisa que esconder o uso de IA do mantenedor

Se o projeto exige divulgação, você divulga, mesmo com a atribuição automática desligada

O erro comum deste passo: descobrir a atribuição depois de abrir o PR, num projeto que trata isso como quebra de regra

6. Deixe preferência pessoal fora do versionamento

O arquivo .claude/settings.local.json serve exatamente pra isso: preferências suas, que não vão pro versionamento

Mas se liga nesse detalhe, porque ele pega gente distraída

Quando o PRÓPRIO Claude Code salva uma configuração ali, num repositório que ainda não ignora esse arquivo, ele adiciona **/.claude/settings.local.json ao arquivo global de git excludes

Agora, se VOCÊ criou o arquivo à mão, o trabalho de colocar no gitignore é seu

O erro comum deste passo: mandar sua config pessoal junto no PR e o mantenedor receber, de brinde, um arquivo que ele nunca pediu

7. Verifique linha a linha e declare o uso de IA quando o projeto exigir

Rodou, passou nos testes, parece certo? Ótimo, agora LEIA

A orientação que o Google publicou pro Google Summer of Code 2026 diz isso com todas as letras: a responsabilidade pelo trabalho segue 100% do contribuidor humano

Então o "a IA que escreveu" não é defesa, é confissão 😛

O erro comum deste passo: confiar no diff verde e mandar sem entender o que cada linha faz

Três tipos de repositório e como agir em cada um

Não existe uma regra única pro open source hoje, existe um mapa

Repositório que proíbe:

O comitê diretor do GCC adotou política que recusa contribuições juridicamente significativas geradas por LLM ou derivadas delas, e o detalhe pesado é esse: mesmo quando o humano editou ou reescreveu a saída do modelo

A política foi anunciada na lista do GCC por David Edelsohn, membro do steering committee

E "juridicamente significativa" tem régua: as diretrizes de mantenedores do GNU definem esse limiar em mais de aproximadamente 15 linhas de código ou texto

Quinze linhas é pouca coisa, né? Pois é

A Oracle, por sua vez, publicou política interina proibindo contribuições geradas por IA no OpenJDK

A proibição cobre código, texto e imagens enviados via Git, pull requests no GitHub, e-mails, wikis e issue trackers

O uso privado de IA pra entender, depurar, revisar e pesquisar continua permitido, o que é uma distinção bem sensata: usar pra APRENDER é diferente de usar pra ENTREGAR

E pra mostrar que nem dentro da mesma empresa a régua é uma só: o GraalVM, também da Oracle, aceita contribuições geradas por IA

Moral: política é por projeto, não por organização

Repositório que exige vínculo com issue aceita:

O Ghostty é o exemplo mais direto

O projeto trocou a regra simples de divulgação por um AI_POLICY.md próprio, e o texto é bem específico: PRs com IA só são aceitos quando ligados a uma issue já aceita

PR de IA sem vínculo com issue é fechado

E quem envia saída de IA não verificada pode ser bloqueado de contribuições futuras

Olha o recado embutido aí: o problema deles não é a ferramenta, é o trabalho de revisão que sobra pro mantenedor

Terreno em movimento:

Aqui é onde tu precisa perguntar antes de codar

Na lista qemu-devel, em maio de 2026, Paolo Bonzini enviou um patch propondo relaxar a proibição de contribuições geradas por IA: liberaria testes, documentação, mudanças mecânicas e correções pequenas, com o código central ainda fora sem acordo prévio de um mantenedor, além de uma marcação AI-used-for explicando onde a IA foi usada

Repara que é uma PROPOSTA na lista, não a regra vigente

O Debian abriu uma General Resolution pra decidir como o projeto trata contribuições assistidas por LLM, com propostas concorrentes que vão da proibição total ao uso permitido com salvaguardas

Até 20/08/2026, nenhuma proposta havia sido adotada como política final

O Gentoo tem política de IA mantida pelo Council do projeto, valendo pra contribuições ao Gentoo e a projetos oficiais Gentoo (sem impedir, veja bem, que se empacote software relacionado a IA ou software que usa IA no upstream)

E tem o caso do Codeberg, que saiu do nível "projeto" e foi pro nível "plataforma": os membros do Codeberg e.V. votaram e os Termos de Uso passaram a proibir projetos que consistem majoritariamente em código escrito por ferramentas de IA generativa

Foram 358 votos a favor da proibição contra 144, com a votação encerrada em 22/07/2026

A regra prática pra esse terceiro grupo é simples: quando a política é ambígua, pergunta na issue antes de escrever a primeira linha

Custoso? Cinco minutos

Mais barato que jogar fora um fim de semana de código

Motivos comuns de recusa e como evitar cada um

PR fechado sem nem ser revisado:

Causa: não existia issue aceita por trás dele

É literalmente a regra do Ghostty, e não é exclusividade dele: PR que cai do céu resolvendo algo que ninguém pediu vira trabalho extra pro mantenedor

Como prevenir: volta no passo 1 e no checklist, confirma que a issue foi ACEITA antes de rodar qualquer prompt

Mudança grande demais:

Causa: refatoração não pedida, aquela que o agente propõe com toda a boa intenção do mundo

O diff cresce, o mantenedor perde o fio do que a issue pedia, e a revisão empaca

Esse é o mesmo tipo de desvio de quem já cansou de ver o agente inventar componente fora do design system: ele resolve o problema, mas resolve do jeito dele

Como prevenir: passo 4, cortar o plano no escopo ANTES de aprovar

Ruído pro mantenedor:

Causa: relato ou patch não verificado, mandado no volume

O caso do curl é o exemplo mais doído dessa história: o projeto encerrou o programa de bug bounty por causa do volume de relatórios gerados por IA

Sem bounty a partir de 01/02/2026, com os relatos de segurança passando a ser recebidos pelo GitHub, sem pagamento

Ou seja, o comportamento de uma parte da galera custou um programa que existia pra todo mundo

Como prevenir: passo 7, verificação linha a linha antes de apertar enviar

Falta de divulgação do uso de IA:

Causa: o projeto exigia declarar e você não declarou

E esse é o mais evitável de todos, porque não custa nada: é uma frase no PR

Como prevenir: colar a cláusula de divulgação no prompt (passo 1) e escrever a declaração você mesmo, na mão, na descrição do PR

Conclusão: contexto do repositório vale mais que velocidade

Gerar código rápido deixou de ser diferencial faz tempo

O diferencial agora é entregar DENTRO das regras da casa: no escopo da issue, no estilo que já existe, com a divulgação que o projeto pede e com um diff que o mantenedor consegue revisar no café da manhã

O estudo do RepoComplianceBench mostra o buraco (agente não caça a regra sozinho, e recusa fica em 0%) e mostra a saída no mesmo fôlego: quando a cláusula entra no prompt, a conformidade sobe muito

O próximo passo concreto é bem pequeno:

Escolhe um projeto que tu já usa

Lê a política de IA dele

Pega uma issue pequena e JÁ ACEITA

Roda o modo de planejamento, corta os extras, revisa linha a linha e manda um PR mínimo

E se você acha que essa história de declarar regra é frescura de um projeto ou outro, olha o sinal: o Google publicou orientação sobre uso de ferramentas de IA no Google Summer of Code 2026, com um documento pra organizações e outro pra contribuidores, orientando que cada organização declare sua posição na lista de ideias ou nas instruções pra candidatos

Declarar a regra virou padrão

Ler a regra também precisa virar 😀

até o próximo post!