Como revisar um pull request com o Graphify e enxergar o impacto além dos arquivos alterados?

Fala aí, beleza? Todo diff mente por omissão

Ele te mostra as 40 linhas que mudaram, e nunca te conta quem depende daquelas 40 linhas

O Graphify ataca exatamente esse ponto cego: ele é um projeto open source, criado e mantido por Safi Shamsi (safishamsi), que transforma código, docs, schemas SQL, configs e PDFs num grafo de conhecimento consultável

Um detalhe pra não te confundir: o repositório oficial hoje fica na organização Graphify-Labs/graphify, e as URLs antigas em safishamsi/graphify apontam pro mesmo projeto

E aqui vem a parte que eu acho massa: o parsing é determinístico, AST local via tree-sitter, sem banco vetorial no meio

"Determinístico?" Sim: não é embedding chutando similaridade, é a árvore sintática do teu código virando nó e aresta

Neste post tu monta o grafo do repositório, roda o painel de PRs e leva esse impacto pra dentro da sessão do Claude Code, passo a passo

O que você precisa antes de começar

Nada de PC da Nasa aqui, se liga na lista:

• Python com uv, pipx ou pip: a instalação recomendada é uv tool install graphifyy, e as alternativas oficiais são pipx install graphifyy e pip install graphifyy
• Atenção ao nome: o pacote no PyPI é graphifyy, com dois ‘y’, mas o comando de linha continua sendo graphify
• GitHub CLI (gh) autenticado: é pré-requisito do graphify prs, que puxa os dados dos pull requests do GitHub
• O suporte a MCP, se tu quiser as ferramentas dentro do assistente: ele vem num extra do próprio pacote, e o comando tá lá no passo 8
• Um repositório com PRs abertos, senão o painel não tem o que te mostrar 😀

O projeto é distribuído sob licença MIT, e a página oficial de preços do Graphify declara ele como gratuito e open source

A versão mais recente do graphifyy no PyPI é a 0.9.47, publicada em 19/08/2026

Formação Recomendada

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

• 120 aulas
• 4 projetos
• 9h 45min

Conhecer formação

Como revisar um pull request com o Graphify passo a passo

A ideia geral: constrói o grafo uma vez, mantém ele fresco, e passa a ler o PR pelo impacto, não pela lista de arquivos

Bora ver na prática?

1. Instale o pacote

uv tool install graphifyy

# alternativas
pipx install graphifyy
pip install graphifyy

O erro comum deste passo: sair procurando graphify no PyPI e achar que não existe

O pacote tem dois ‘y’ (graphifyy), o binário tem um só (graphify)

2. Registre a skill nos assistentes

graphify install

Esse comando detecta os assistentes instalados na máquina e registra a skill /graphify neles, incluindo o Claude Code, o Cursor, o Codex e o Gemini CLI

O erro comum deste passo: rodar o install e esperar que ele apareça num assistente que tu ainda nem instalou

A detecção é dos que já estão na máquina

3. Construa o grafo do repositório

/graphify

# ou apontando um caminho
/graphify ./caminho

O build grava três artefatos dentro de graphify-out/:

• graphify-out/graph.json: o grafo consultável, que é o arquivo que interessa pro resto do fluxo
• graphify-out/graph.html: a visualização
• graphify-out/GRAPH_REPORT.md: o relatório de arquitetura

Existem ainda as flags --mode deep, --cluster-only e --no-viz pra ajustar o build

O erro comum deste passo: perder o caminho do graph.json

Guarda ele na cabeça, porque o servidor MCP aponta pra esse arquivo mais adiante

4. Mantenha o grafo fresco

/graphify --update

graphify hook install

O --update reextrai só os arquivos alterados, usando cache SHA256, e existe também o --watch pra acompanhamento contínuo

O graphify hook install instala hooks de git (post-commit e post-checkout), e ainda tem graphify hook uninstall e graphify hook status

O erro comum deste passo: revisar PR com grafo velho

Grafo desatualizado te dá impacto de uma arquitetura que já não existe, e aí a revisão fica pior do que sem nada

5. Abra o painel de pull requests

graphify prs

O painel mostra os PRs abertos do GitHub com estado de CI e de revisão, mais o impacto no grafo: quais comunidades cada PR toca, onde os PRs se sobrepõem e quais pares carregam risco de merge

A assinatura completa do comando é graphify prs [<number>] [--triage] [--conflicts] [--worktrees] [--base <branch>] [--repo <owner/repo>]

O erro comum deste passo: gh não autenticado

Sem o GitHub CLI logado, não tem de onde tirar os dados dos PRs

6. Veja a sobreposição entre PRs

graphify prs --conflicts

Essa flag cruza os PRs abertos com o grafo e sinaliza quando dois PRs tocam a mesma comunidade de nós

E aqui tem um detalhe que faz MUITA diferença na leitura: ele mostra rótulos representativos dos nós, tipo ValidateToken, SessionStore, AuthMiddleware, em vez de te jogar um "Community 3" na cara

O erro comum deste passo: tratar sobreposição como conflito de texto do git

São coisas diferentes: dois PRs podem não conflitar em linha nenhuma e mesmo assim mexer na mesma região de comportamento

7. Opcional: peça a fila ranqueada

graphify prs --triage

O --triage envia a fila de PRs pro backend de LLM configurado e devolve uma lista ranqueada com uma ação por PR

A detecção do backend é automática pelo ambiente, nesta ordem: claude, kimi, openai, gemini, claude-cli, ollama

O erro comum deste passo: achar que é igual ao build

A construção do grafo é AST pura, mas o triage passa pelo modelo, então ele depende de um backend disponível no teu ambiente

8. Leve tudo pra dentro do Claude Code

pip install "graphifyy[mcp]"

python -m graphify.serve graphify-out/graph.json

Repara que o servidor MCP é iniciado apontando pro grafo JÁ construído, ou seja, o passo 3 não é opcional

Com o MCP no ar, o assistente chama dez ferramentas nativamente: query_graph, get_node, get_neighbors, shortest_path, get_community, god_nodes, graph_stats, list_prs, get_pr_impact e triage_prs

As três de pull request (list_prs, get_pr_impact e triage_prs) entraram na versão 0.8.8

O erro comum deste passo: sair colando bloco de configuração copiado de algum lugar aleatório

O caminho documentado é o graphify install pro registro e o python -m graphify.serve pro servidor, então segue por ele

O que o grafo revela que o diff sozinho não mostra

Agora a parte boa: o que muda na prática quando tu para de revisar por arquivo e passa a revisar por consumidor

PR pequeno em comunidade central. Três linhas alteradas parecem inofensivas, até o get_pr_impact te dizer que elas caem numa comunidade que meia base consome

É o clássico "aprova rápido que é só um ajuste" que volta como incidente na sexta à noite 😛

Dois PRs na mesma comunidade. O --conflicts te mostra isso antes do merge, com os nós reais no rótulo

Aí a decisão deixa de ser palpite: ou tu merga um e pede rebase do outro, ou revisa os dois juntos

Ordem de revisão e de merge. O list_prs devolve os PRs abertos acionáveis (base correta, não obsoletos) já com os dados de impacto no grafo, justamente pro agente raciocinar sobre prioridade de revisão, ordem de merge e risco de conflito

Profundidade da revisão. Nem todo PR merece o mesmo rigor, e o impacto no grafo é um critério bem melhor que "número de linhas" pra decidir onde tu gasta energia

Esse raciocínio combina direto com o fluxo de revisar PR com Claude Code: o grafo entrega o mapa, o agente entrega a leitura

E se o teu fluxo vive dentro do editor, o mesmo grafo construído uma vez fica disponível pra vários assistentes pelo mesmo mecanismo de MCP, num total de 17, incluindo Claude Code, Cursor, GitHub Copilot, Codex e Gemini CLI

Dá pra encaixar isso no jeito de comentar e mergear PR no Cursor Origin sem reconstruir nada

Os números que o próprio projeto reporta nos benchmarks:

O detalhe que eu acho topzera: nesse benchmark de código o grafo foi construído só por AST, com zero créditos de LLM

Ou seja, a estrutura sai de graça em termos de modelo, e o modelo entra depois, já sabendo pra onde olhar

Vídeo: o contexto de IA que mudou o jeito de programar

Pra situar o cenário que trouxe a gente até aqui, este vídeo do canal fala do impacto do DeepSeek para os programadores

Conclusão

Revisão boa não é ler mais linhas, é enxergar quem consome a linha que mudou

O diff te dá o arquivo, o grafo te dá o raio de alcance, e o assistente junta os dois na mesma conversa

Próximo passo, bem prático: escolhe o repositório onde tu mais revisa PR, roda o build do grafo, liga o MCP na tua sessão do Claude Code e abre o graphify prs no próximo pull request que aparecer

Depois compara com o jeito antigo, só no diff, e me conta se a diferença é a que tu esperava… 🙂

até o próximo post!