Saltar al contenido principal

Descripción general

Devin ahora indexa automáticamente tus repositorios y genera wikis con diagramas de arquitectura, enlaces a fuentes y resúmenes de tu base de código. Úsalo para ponerte al día con las partes de tu base de código que no conozcas. Échale un vistazo en tu barra lateral. Ask Devin utilizará la información de la wiki para comprender mejor tu código y encontrar el contexto relevante en tu base de código.
DeepWiki se autogenerará al conectar repositorios durante el proceso de incorporación.

Para repositorios públicos

Ya está disponible una versión gratuita de DeepWiki y Ask Devin que funciona con repositorios públicos de GitHub. Genera automáticamente diagramas de arquitectura, documentación y enlaces al código fuente para ayudarte a comprender rápidamente bases de código desconocidas. También puedes hacer preguntas complejas sobre la base de código para obtener respuestas específicas basadas en el contexto. Visita deepwiki.com para empezar a explorar repositorios de código abierto populares como React, TensorFlow, LangChain y muchos más. También puedes enviar la URL de tu propio repositorio público de GitHub para su indexación. Prueba DeepWiki ahora →

Controlar DeepWiki

Steerable Wiki UI El archivo .devin/wiki.json te permite controlar el comportamiento predeterminado de generación de wikis de Devin, lo cual es especialmente importante para repositorios grandes que pueden alcanzar los límites incorporados. Si se encuentra un archivo .devin/wiki.json en el directorio raíz de tu repositorio durante la generación del wiki, usaremos los repo_notes y pages proporcionados para orientar la generación del wiki. Si se proporciona pages, omitiremos la planificación predeterminada basada en clústeres y crearemos exactamente las páginas que especifiques. Esto garantiza que las partes importantes de tu base de código queden documentadas incluso cuando el sistema automático, de otro modo, las omitiría.

Formato de la configuración

Crea un archivo .devin/wiki.json en la raíz del repositorio con la siguiente estructura:
{
  "repo_notes": [
    {
      "content": "Este repositorio contiene los componentes principales de UI en la carpeta cui/, los cuales deben priorizarse en la documentación",
      "author": "Team Lead"
    }
  ],
  "pages": [
    {
      "title": "Resumen de Componentes CUI",
      "purpose": "Documentar la estructura de la carpeta cui/ y los componentes principales de UI",
      "parent": null
    },
    {
      "title": "Sistema de Autenticación",
      "purpose": "Documentar el flujo de autenticación y componentes relacionados",
      "parent": null
    },
    {
      "title": "Componentes de Login",
      "purpose": "Documentación detallada de componentes de UI relacionados con login",
      "parent": "Authentication System"
    }
  ]
}

Opciones de configuración

repo_notes (Array)

Proporciona contexto y orientación para ayudar al sistema de documentación a comprender mejor tu repositorio.
  • content (string, obligatorio): El contenido de la nota (máx. 10 000 caracteres)
  • author (string, opcional): Quién escribió la nota

pages (Array, opcional)

Especifica exactamente qué páginas se deben crear en tu wiki. Este campo es opcional. Si solo incluyes repo_notes, el sistema de todos modos generará una wiki, usando tus notas para guiar la estructura y el enfoque sin requerir que definas cada página. Cuando proporcionas pages, se tratan como instrucciones explícitas. Solo se generarán las páginas que definas en el JSON, ni más ni menos.
  • title (string, obligatorio): El título de la página (debe ser único y no puede estar vacío)
  • purpose (string, obligatorio): Lo que esta página debe documentar
  • parent (string, opcional): Título de la página principal para la organización jerárquica
  • page_notes (array, opcional): Notas adicionales específicas de esta página

Límites de validación

  • Máximo 30 páginas (80 para Enterprise)
  • Máximo 100 notas en total (repo_notes + todas las page_notes combinadas)
  • Máximo 10.000 caracteres por nota
  • Los títulos de las páginas deben ser únicos y no estar vacíos

Ejemplos prácticos

Ejemplo 1: Notas del repositorio para guiar la generación del wiki

Si prefieres no definir páginas específicas, puedes proporcionar solo repo_notes para ayudar a guiar la generación del wiki. Esto le permite a Devin crear la estructura de la documentación automáticamente, teniendo en cuenta tus prioridades y áreas de enfoque. Esto es útil cuando quieres una mejor cobertura y mayor énfasis sin tener que definir explícitamente cada página tú mismo.
{
  "repo_notes": [
    {
      "content": "El repositorio contiene tres áreas principales: la carpeta frontend/ con componentes de React, la carpeta backend/ con servicios de API, y la carpeta infra/ con scripts de implementación. La documentación debe enfatizar cómo interactúan estas partes y destacar la capa de API del backend como la prioridad más alta."
    }
  ]
}

Ejemplo 2: Garantizar que determinadas carpetas queden documentadas

Si tu repositorio de gran tamaño tiene carpetas importantes que no se están incluyendo en la wiki, especifícalas explícitamente:
{
  "repo_notes": [
    {
      "content": "La carpeta cui/ contiene componentes de interfaz de usuario críticos que deben documentarse. La carpeta backend/ contiene la lógica principal de la API. La carpeta utils/ contiene utilidades compartidas utilizadas en todo el código base."
    }
  ]
}

Ejemplo 3: Cómo abordar componentes que faltan

Si notas que ciertas partes de tu base de código no están siendo documentadas:
{
  "repo_notes": [
    {
      "content": "El directorio testing/ contiene utilidades y patrones de prueba importantes que los desarrolladores deben comprender. El directorio scripts/ contiene scripts de despliegue y mantenimiento cruciales para las operaciones."
    }
  ]
}

Ejemplo 4: Estructura jerárquica de la documentación

Para repositorios complejos, organiza las páginas de forma jerárquica:
{
  "repo_notes": [
    {
      "content": "Esta es una aplicación full-stack con componentes diferenciados de frontend, backend y compartidos que deben documentarse por separado pero con relaciones claras."
    }
  ],
  "pages": [
    {
      "title": "Descripción General de la Arquitectura",
      "purpose": "Descripción general de alto nivel de la arquitectura de la aplicación y cómo interactúan los componentes"
    },
    {
      "title": "Frontend",
      "purpose": "Estructura y componentes de la aplicación frontend",
      "parent": "Architecture Overview"
    },
    {
      "title": "Componentes de React",
      "purpose": "Documentación detallada de los componentes de React, sus props y uso",
      "parent": "Frontend"
    },
    {
      "title": "Gestión de Estado",
      "purpose": "Cómo se gestiona el estado de la aplicación, incluyendo stores y flujo de datos",
      "parent": "Frontend"
    },
    {
      "title": "Backend",
      "purpose": "Servicios de backend, APIs y capa de datos",
      "parent": "Architecture Overview"
    },
    {
      "title": "Endpoints de API",
      "purpose": "Documentación de la API REST que incluye endpoints y formatos de solicitud/respuesta",
      "parent": "Backend"
    }
  ]
}

Prácticas recomendadas

1. Usa Repo Notes de forma estratégica

  • Proporciona contexto sobre qué partes de tu código son más importantes
  • Menciona carpetas o componentes específicos que deban priorizarse
  • Explica las relaciones entre las diferentes partes de tu sistema

2. Organizar páginas lógicamente

  • Comienza con páginas de alto nivel de descripción general
  • Usa relaciones padre-hijo para crear jerarquías claras
  • Agrupa las funcionalidades relacionadas

3. Sé específico con los objetivos de cada página

  • Indica claramente qué debe documentar cada página
  • Menciona los directorios, archivos o conceptos específicos en los que deba centrarse
  • Proporciona suficiente detalle para que el sistema comprenda tu intención

4. Aborda las lagunas conocidas

  • Si sabes que hay ciertas partes de tu base de código que se están pasando por alto, inclúyelas explícitamente
  • Usa títulos descriptivos que dejen claro qué se debe cubrir

Solución de problemas frecuentes

”Solo se documentan ciertas carpetas”

Este es el clásico problema de los repositorios grandes. Solución: Usa .devin/wiki.json para especificar explícitamente qué partes de tu código base deben documentarse.
Comienza actualizando solo repo_notes y regenera la wiki con ese contexto adicional para ver si la wiki actualizada incluye las carpetas que faltan. Solo agrega el array pages si es necesario.

”Faltan componentes importantes en la wiki”

Añade páginas específicas para estos componentes y usa repo_notes para resaltar su importancia.
Recuerda: DeepWiki solo generará las páginas incluidas en este array, así que asegúrate de que todas las páginas estén presentes, no solo la que falta.
{
  "repo_notes": [
    {
      "content": "El directorio [missing-component] es fundamental para la aplicación y debe estar completamente documentado."
    }
  ],
  "pages": [
    {
      "title": "Nombre del Componente Crítico",
      "purpose": "Documentar el directorio [missing-component] y su funcionalidad"
    }
  ]
}

Primeros pasos

  1. Crea .devin/wiki.json en la raíz de tu repositorio
  2. Agrega repo_notes que expliquen la estructura de tu código base y las prioridades
  3. Si es necesario, especifica todas las páginas que quieres que se creen, con títulos y propósitos claros
  4. Haz commit del archivo y regenera tu wiki
El sistema ahora generará documentación en función de tus instrucciones explícitas, en lugar de un análisis completamente automático, lo que garantiza una cobertura más completa y precisa de repositorios grandes.