Mapear uma base de código

Um repositório que você nunca viu, lido por três agentes ao mesmo tempo.

Numa base de código que você não conhece, o primeiro dia vai embora procurando onde ficam as coisas. Aponte uma sessão principal para o repositório e ela divide a leitura: um auxiliar fica com a camada de dados, outro com a API, outro com o frontend e o build. Cada um manda de volta um resumo curto com caminhos de arquivo, e a principal escreve uma visão geral a partir de todos eles.

Grátis e open sourceRoda no Mac e no LinuxSeus próprios logins do Claude e do Codex
O terminal do Claude Code da sessão principal depois que os auxiliares responderam, com o resumo que junta tudo
Gravado numa máquina de demonstração: a sessão principal resume o que os auxiliares mandaram.

Peça a um agente para explicar um repositório grande e você ganha um tour pela primeira pasta

Uma sessão lê tudo sozinha, e um repositório grande não cabe. As partes que ela leu primeiro saem detalhadas, e o resto ganha uma frase cada.

Um agente sozinho
  • Um leitor só percorrendo o repositório inteiro
  • Detalhe onde começou, chute no resto
  • Cada pergunta nova recomeça a leitura
Agentes lado a lado no Overvibe
  • Um auxiliar por área, todos lendo ao mesmo tempo
  • Uma visão geral escrita com todos os relatórios
  • As perguntas seguintes vão para o auxiliar que leu aquela parte

Três leitorese uma visão geral

Você digita

Sou novo neste repositório. Peça a auxiliares para mapear as partes principais em paralelo e me escreva uma visão geral em ARCHITECTURE.md.

  1. 1A principal divide o repositório

    Ela olha as pastas do nível de cima e dá a cada auxiliar uma área e as mesmas três perguntas: o que tem aqui, quem chama isso, o que é arriscado mudar.

  2. 2Os auxiliares leem, ninguém edita

    Cada um no próprio terminal sob a sessão principal, relatando o que achou com caminhos de arquivo.

  3. 3A visão geral volta

    A principal escreve o ARCHITECTURE.md com os relatórios e termina com o que ainda não sabe.

Por trás disso, um auxiliar por área. A segunda linha é para depois: o auxiliar que leu a API volta com a conversa dele e responde com base no que já leu. Leia a referência da CLI

$ overvibe new --attach --tool codex --cwd . --name "repo: map api" \
    --prompt "Read src/api. What is here, what calls it, what is risky to change? Give paths. Do not edit. When done, run: overvibe send \"$OVERVIBE_SESSION\" \"<map>\""
$ overvibe resume "repo: map api" --prompt "Where does the API check auth?"

Um agente dá conta quando

o repositório é pequeno o bastante para ler de uma vez, ou você só se importa com um canto dele. Pergunte direto ao Claude. Os auxiliares compensam quando o repositório tem várias partes e cada uma leva um tempo para ler.

Perguntas

Os auxiliares vão mudar alguma coisa?

O prompt diz para não mudarem. Num repositório em que você ainda não confia, inicie os auxiliares com --mode ask, assim cada ferramenta pergunta antes de rodar qualquer coisa e você responde no Overvibe.

Qual a diferença para um resumo de pesquisa?

É o mesmo padrão, apontado para código. O resumo de pesquisa cobre fontes de fora do repositório, como documentação, a web e exportações.

Posso fazer perguntas um dia depois?

Sim. Pare os auxiliares quando a visão geral chegar, e o overvibe resume traz um de volta com a conversa quando você tiver uma pergunta sobre a parte dele.

Outros jeitos de juntar agentes

Tenha a visão geral antes de ler o código

Instale o Overvibe, abra uma sessão principal no repositório e peça um auxiliar por área.

O app Overvibe: um coordenador com os ajudantes Codex e Gemini (agy) na barra lateral, cada um com seu status, e uma sessão esperando por você