DeepWiki

Diagramas de arquitetura, documentação, links para o código-fonte e muito mais para todos os seus repositórios

​

Visão geral

Devin agora indexa automaticamente seus repositórios e produz wikis com diagramas de arquitetura, links para as fontes e resumos da sua base de código.

Use-o para se atualizar rapidamente sobre partes da sua base de código com as quais você não está familiarizado — confira na sua barra lateral.

Ask Devin usará informações da Wiki para entender melhor e encontrar o contexto relevante na sua base de código. Os recursos avançados de pesquisa de código do Ask Devin, combinados com o DeepWiki, produzem respostas detalhadas e precisas baseadas no seu código.

O DeepWiki será gerado automaticamente ao conectar repositórios durante o onboarding.

​

Para repositórios públicos

Uma versão gratuita do DeepWiki e do Ask Devin que funciona com repositórios públicos do GitHub está disponível. Ela gera automaticamente diagramas de arquitetura, documentação e links para o código-fonte para ajudar você a entender rapidamente bases de código desconhecidas. Você também pode fazer perguntas complexas sobre a base de código para obter respostas específicas baseadas no contexto.

A experiência completa do Ask Devin, incluindo pesquisa avançada de código, planejamento e criação de sessões, está disponível no aplicativo Devin. O DeepWiki público e o DeepWiki MCP fornecem recursos básicos de documentação e perguntas e respostas.

Visite deepwiki.com para começar a explorar repositórios de código aberto populares como React, TensorFlow, LangChain e muitos outros. Você também pode enviar a URL do seu próprio repositório público do GitHub para indexação.

Experimente o DeepWiki agora →

​

Orientando o DeepWiki

O arquivo .devin/wiki.json permite orientar o comportamento padrão de geração de wiki do Devin, o que é especialmente importante para repositórios grandes que podem atingir limites embutidos.

Se um arquivo .devin/wiki.json for encontrado no diretório raiz do seu repositório durante a geração da wiki, usaremos os repo_notes e pages fornecidos para orientar a geração da wiki. Se pages for fornecido, ignoraremos o planejamento padrão baseado em clusters e criaremos exatamente as páginas que você especificar. Isso garante que as partes importantes da sua base de código sejam documentadas mesmo quando o sistema automático normalmente as ignoraria.

​

Formato de configuração

Crie um arquivo .devin/wiki.json na raiz do repositório com a seguinte estrutura:

{
  "repo_notes": [
    {
      "content": "Este repositório contém os principais componentes de interface na pasta cui/, que devem ser priorizados na documentação",
      "author": "Líder de Equipe"
    }
  ],
  "pages": [
    {
      "title": "Visão Geral dos Componentes CUI",
      "purpose": "Documentar a estrutura da pasta cui/ e os principais componentes de interface",
      "parent": null
    },
    {
      "title": "Sistema de Autenticação",
      "purpose": "Documentar o fluxo de autenticação e os componentes relacionados",
      "parent": null
    },
    {
      "title": "Componentes de Login",
      "purpose": "Documentação detalhada dos componentes de interface relacionados ao login",
      "parent": "Sistema de Autenticação"
    }
  ]
}

​

Opções de configuração

​

repo_notes (array)

Fornece contexto e orientação para ajudar o sistema de documentação a compreender melhor o seu repositório.

• content (string, obrigatório): Conteúdo da nota (máximo de 10.000 caracteres)
• author (string, opcional): Autor da nota

​

pages (Array, opcional)

Especifica exatamente quais páginas devem ser criadas na sua wiki.

Este campo é opcional. Se você incluir apenas repo_notes, o sistema ainda assim gerará uma wiki, usando suas anotações para orientar a estrutura e o foco, sem exigir que você detalhe cada página.

Quando você fornece pages, elas são tratadas como instruções explícitas. Somente as páginas definidas no JSON serão geradas — nem mais, nem menos.

• title (string, obrigatório): O título da página (deve ser único e não vazio)
• purpose (string, obrigatório): O que esta página deve documentar
• parent (string, opcional): Título da página principal para organização hierárquica
• page_notes (array, opcional): Anotações adicionais específicas desta página

​

Limites de validação

• No máximo 30 páginas (80 para Enterprise)
• No máximo 100 notas no total (repo_notes + todas as page_notes combinadas)
• No máximo 10.000 caracteres por nota
• Os títulos de página devem ser únicos e não podem estar em branco

​

Exemplos práticos

​

Exemplo 1: Repo Notes para orientar a geração do wiki

Se você preferir não definir páginas específicas, pode fornecer apenas repo_notes para ajudar a orientar a geração do wiki. Isso permite que o Devin crie a estrutura da documentação automaticamente, ainda levando em conta suas prioridades e áreas de foco. Isso é útil quando você quer uma cobertura e ênfase melhores, sem precisar definir explicitamente cada página por conta própria.

{
  "repo_notes": [
    {
      "content": "O repositório contém três áreas principais: a pasta frontend/ com componentes React, a pasta backend/ com serviços de API e a pasta infra/ com scripts de deploy. A documentação deve enfatizar como essas partes interagem e destacar a camada de API do backend como a maior prioridade."
    }
  ]
}

​

Exemplo 2: Garantindo a documentação de pastas específicas

Se o seu repositório grande tiver pastas importantes que não estão sendo incluídas na wiki, especifique-as explicitamente:

{
  "repo_notes": [
    {
      "content": "A pasta cui/ contém componentes de interface críticos que devem ser documentados. A pasta backend/ contém a lógica principal da API. A pasta utils/ contém utilitários compartilhados utilizados em todo o código."
    }
  ]
}

​

Exemplo 3: Abordando Componentes Ausentes

Se você notar que certas partes da sua base de código não estão sendo documentadas:

{
  "repo_notes": [
    {
      "content": "O diretório testing/ contém utilitários e padrões de teste importantes que os desenvolvedores precisam conhecer. O diretório scripts/ contém scripts de deploy e manutenção essenciais para as operações."
    }
  ]
}

​

Exemplo 4: Estrutura de Documentação Hierárquica

Para repositórios complexos, organize as páginas de forma hierárquica:

{
  "repo_notes": [
    {
      "content": "Esta é uma aplicação full-stack com componentes distintos de frontend, backend e compartilhados que devem ser documentados separadamente, mas com relacionamentos claros."
    }
  ],
  "pages": [
    {
      "title": "Visão Geral da Arquitetura",
      "purpose": "Visão geral de alto nível da arquitetura da aplicação e como os componentes interagem"
    },
    {
      "title": "Frontend",
      "purpose": "Estrutura e componentes da aplicação frontend",
      "parent": "Visão Geral da Arquitetura"
    },
    {
      "title": "Componentes React",
      "purpose": "Documentação detalhada dos componentes React, suas props e uso",
      "parent": "Frontend"
    },
    {
      "title": "Gerenciamento de Estado",
      "purpose": "Como o estado da aplicação é gerenciado, incluindo stores e fluxo de dados",
      "parent": "Frontend"
    },
    {
      "title": "Backend",
      "purpose": "Serviços backend, APIs e camada de dados",
      "parent": "Visão Geral da Arquitetura"
    },
    {
      "title": "Endpoints da API",
      "purpose": "Documentação da API REST incluindo endpoints e formatos de requisição/resposta",
      "parent": "Backend"
    }
  ]
}

​

Boas práticas

​

1. Use Repo Notes de forma estratégica

• Forneça contexto sobre quais partes do seu codebase são mais importantes
• Mencione diretórios ou componentes específicos que devem ser priorizados
• Explique as relações entre diferentes partes do seu sistema

​

2. Organize as páginas de forma lógica

• Comece com páginas de visão geral de alto nível
• Use relações pai-filho para criar hierarquias claras
• Agrupe funcionalidades relacionadas

​

3. Seja específico sobre o objetivo de cada página

• Declare claramente o que cada página deve documentar
• Mencione diretórios, arquivos ou conceitos específicos em que a página deve focar
• Forneça detalhes suficientes para o sistema entender sua intenção

​

4. Aborde Lacunas Conhecidas

• Se você sabe que certas partes da sua base de código estão ficando de fora, inclua-as explicitamente
• Use títulos descritivos que deixem claro o que deve ser abrangido

​

Solução de problemas comuns

​

”Apenas algumas pastas estão sendo documentadas”

Este é o clássico problema de repositório grande.

Solução: Use .devin/wiki.json para especificar explicitamente quais partes da sua base de código devem ser documentadas.

Comece atualizando apenas repo_notes e gere a wiki novamente com esse contexto adicional para ver se a wiki atualizada incluirá as pastas ausentes. Só adicione o array pages se for necessário.

​

”Componentes importantes estão ausentes na wiki”

Adicione páginas específicas para esses componentes e use repo_notes para destacar sua importância.

Lembre-se: o DeepWiki irá gerar somente as páginas incluídas nesse array, portanto, certifique-se de que todas as páginas estejam presentes, não apenas a página ausente.

{
  "repo_notes": [
    {
      "content": "O diretório [missing-component] é essencial para a aplicação e deve ser documentado detalhadamente."
    }
  ],
  "pages": [
    {
      "title": "Nome do Componente Essencial",
      "purpose": "Documentar o diretório [missing-component] e sua funcionalidade"
    }
  ]
}

​

Primeiros passos

1. Crie .devin/wiki.json na raiz do seu repositório
2. Adicione repo_notes explicando a estrutura da sua base de código e suas prioridades
3. Se necessário, especifique todas as páginas que você quer criar, com títulos e objetivos claros
4. Faça o commit do arquivo e regenere sua wiki

O sistema agora criará documentação com base nas suas instruções explícitas, em vez de depender de análise totalmente automática, garantindo uma cobertura mais abrangente e precisa de repositórios grandes.