> ## Documentation Index
> Fetch the complete documentation index at: https://docs.devinenterprise.com/llms.txt
> Use this file to discover all available pages before exploring further.

# DeepWiki

> Architekturdiagramme, Dokumentation, Links zu Quellen und mehr für alle Ihre Repos

<div id="overview">
  ## Übersicht
</div>

Devin indexiert jetzt automatisch Ihre Repos und erstellt Wikis mit Architekturdiagrammen, Links zu Quellen und Zusammenfassungen Ihrer Codebasis.

Nutzen Sie es, um sich schnell in unbekannte Teile Ihrer Codebasis einzuarbeiten – schauen Sie es sich [in Ihrer Seitenleiste](https://app.devin.ai/wiki) an.

[Ask Devin](/de/work-with-devin/ask-devin) verwendet Informationen aus dem Wiki, um Ihre Codebasis besser zu verstehen und den relevanten Kontext darin zu finden. Die erweiterte Codesuche von Ask Devin in Kombination mit DeepWiki liefert detaillierte und präzise Antworten, die in Ihrem Code verankert sind.

<Tip> DeepWiki wird beim Verbinden von Repositories während des Onboardings automatisch erstellt. </Tip>

<iframe width="840" height="473" src="https://www.youtube.com/embed/lDh9rho5XW8" title="DeepWiki" className="max-w-full" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen />

<div id="for-public-repos">
  ## Für öffentliche Repos
</div>

Eine kostenlose Version von **DeepWiki** und [Ask Devin](/de/work-with-devin/ask-devin), die mit öffentlichen GitHub-Repositories funktioniert, ist jetzt verfügbar. Sie generiert automatisch Architekturdiagramme, Dokumentation und Links zum Quellcode, damit Sie unbekannte Codebasen schnell verstehen können. Sie können außerdem komplexe Fragen zur Codebasis stellen, um kontextbezogene, präzise Antworten zu erhalten.

<Note>Die vollständige Ask Devin-Erfahrung, einschließlich erweiterter Codesuche, Planung und Sitzungserstellung, ist in der [Devin-App](https://app.devin.ai) verfügbar. Öffentliches DeepWiki und die DeepWiki-MCP bieten grundlegende Dokumentations- sowie Frage-und-Antwort-Funktionen.</Note>

Besuchen Sie [deepwiki.com](https://deepwiki.com/), um beliebte Open-Source-Repositories wie React, TensorFlow, LangChain und viele weitere zu erkunden. Sie können auch die URL Ihres eigenen öffentlichen GitHub-Repositories zur Indexierung einreichen.

[DeepWiki jetzt ausprobieren →](https://deepwiki.com/)

<div id="steering-deepwiki">
  ## DeepWiki steuern
</div>

<Frame>
  <img src="https://mintcdn.com/cognitionai-enterprise/wB0NnCGoy7CGkti6/images/work-with-devin/steering-deepwiki.png?fit=max&auto=format&n=wB0NnCGoy7CGkti6&q=85&s=ea76731afe16b9a910227754dc0d80b8" alt="Steerable Wiki UI" width="2892" height="1714" data-path="images/work-with-devin/steering-deepwiki.png" />
</Frame>

Die Datei `.devin/wiki.json` ermöglicht es dir, das Standardverhalten von Devin bei der Wiki-Generierung zu steuern. Das ist besonders wichtig für große Repositories, die an integrierte Grenzwerte stoßen können.

Wenn während der Wiki-Generierung eine Datei `.devin/wiki.json` im Stammverzeichnis deines Repositories gefunden wird, verwenden wir die angegebenen `repo_notes` und `pages`, um die Wiki-Generierung zu steuern. Wenn `pages` angegeben ist, überspringen wir die standardmäßige, clusterbasierte Planung und erstellen genau die Seiten, die du angibst. So wird sichergestellt, dass die wichtigen Teile deiner Codebasis dokumentiert werden, selbst wenn das automatische System sie ansonsten überspringen würde.

<div id="configuration-format">
  ## Konfigurationsformat
</div>

Erstellen Sie im Stammverzeichnis Ihres Repositories eine Datei `.devin/wiki.json` mit der folgenden Struktur:

```json theme={null}
{
  "repo_notes": [
    {
      "content": "Dieses Repository enthält die Haupt-UI-Komponenten im cui/-Ordner, die in der Dokumentation priorisiert werden sollten",
      "author": "Team Lead"
    }
  ],
  "pages": [
    {
      "title": "CUI-Komponenten – Übersicht",
      "purpose": "Dokumentiert die cui/-Ordnerstruktur und Haupt-UI-Komponenten",
      "parent": null
    },
    {
      "title": "Authentifizierungssystem",
      "purpose": "Dokumentiert den Authentifizierungsablauf und zugehörige Komponenten",
      "parent": null
    },
    {
      "title": "Login-Komponenten",
      "purpose": "Detaillierte Dokumentation der Login-bezogenen UI-Komponenten",
      "parent": "Authentifizierungssystem"
    }
  ]
}
```

<div id="configuration-options">
  ## Konfigurationsoptionen
</div>

<div id="repo_notes-array">
  ### repo\_notes (Array)
</div>

Bietet Kontext und Hinweise, damit das Dokumentationssystem Ihr Repository besser verstehen kann.

* **content** (string, erforderlich): Der Inhalt der Notiz (max. 10.000 Zeichen)
* **author** (string, optional): Verfasser der Notiz

<div id="pages-array-optional">
  ### pages (Array, optional)
</div>

Gibt genau an, welche Seiten in deinem Wiki erstellt werden sollen.

Dieses Feld ist optional. Wenn du nur repo\_notes angibst, generiert das System trotzdem ein Wiki und nutzt deine Notizen, um Struktur und Fokus festzulegen, ohne dass du jede einzelne Seite vorgeben musst.

Wenn du pages angibst, werden sie als explizite Anweisungen behandelt. Es werden nur die Seiten generiert, die du im JSON definierst – nicht mehr und nicht weniger.

* **title** (string, required): Der Seitentitel (muss eindeutig und nicht leer sein)
* **purpose** (string, required): Was auf dieser Seite dokumentiert werden soll
* **parent** (string, optional): Titel der übergeordneten Seite zur hierarchischen Strukturierung
* **page\_notes** (array, optional): Zusätzliche Notizen, die speziell für diese Seite gelten

<div id="validation-limits">
  ### Validierungslimits
</div>

* Maximal 30 Seiten (80 im Enterprise-Plan)
* Maximal 100 Notizen insgesamt (repo\_notes + alle page\_notes zusammen)
* Maximal 10.000 Zeichen pro Notiz
* Seitentitel müssen eindeutig sein und dürfen nicht leer sein

<div id="practical-examples">
  ## Praktische Beispiele
</div>

<div id="example-1-repo-notes-to-guide-wiki-generation">
  ### Beispiel 1: Repo Notes zur Steuerung der Wiki-Generierung
</div>

Wenn Sie keine spezifischen Seiten definieren möchten, können Sie nur repo\_notes angeben, um die Wiki-Generierung zu unterstützen. Dadurch kann Devin die Dokumentationsstruktur automatisch erstellen und dabei trotzdem Ihre Prioritäten und Fokusbereiche berücksichtigen. Das ist hilfreich, wenn Sie eine bessere Abdeckung und Betonung wünschen, ohne jede Seite explizit selbst skizzieren zu müssen.

```json theme={null}
{
  "repo_notes": [
    {
      "content": "Das Repository enthält drei Hauptbereiche: den Ordner frontend/ mit React-Komponenten, den Ordner backend/ mit API-Services und den Ordner infra/ mit Deployment-Skripten. Die Dokumentation sollte die Interaktion dieser Komponenten hervorheben und die Backend-API-Schicht als höchste Priorität darstellen."
    }
  ]
}
```

<div id="example-2-ensuring-specific-folders-are-documented">
  ### Beispiel 2: Sicherstellen, dass bestimmte Ordner dokumentiert werden
</div>

Wenn Ihr umfangreiches Repository wichtige Ordner enthält, die im Wiki nicht berücksichtigt werden, führen Sie diese explizit auf:

```json theme={null}
{
  "repo_notes": [
    {
      "content": "Der cui/-Ordner enthält kritische UI-Komponenten, die dokumentiert werden müssen. Der backend/-Ordner enthält die Haupt-API-Logik. Der utils/-Ordner enthält gemeinsam genutzte Hilfsfunktionen, die in der gesamten Codebasis verwendet werden."
    }
  ]
}
```

<div id="example-3-addressing-missing-components">
  ### Beispiel 3: Umgang mit fehlenden Komponenten
</div>

Wenn Sie feststellen, dass bestimmte Teile Ihrer Codebasis nicht dokumentiert werden:

```json theme={null}
{
  "repo_notes": [
    {
      "content": "Das Verzeichnis testing/ enthält wichtige Test-Utilities und Muster, die Entwickler kennen müssen. Das Verzeichnis scripts/ enthält Deployment- und Wartungsskripte, die für den Betrieb entscheidend sind."
    }
  ]
}
```

<div id="example-4-hierarchical-documentation-structure">
  ### Beispiel 4: Hierarchische Dokumentationsstruktur
</div>

Für komplexe Repositories organisieren Sie Seiten hierarchisch:

```json theme={null}
{
  "repo_notes": [
    {
      "content": "Dies ist eine Full-Stack-Anwendung mit separaten Frontend-, Backend- und gemeinsam genutzten Komponenten, die getrennt, aber mit klaren Zusammenhängen dokumentiert werden sollten."
    }
  ],
  "pages": [
    {
      "title": "Architekturübersicht",
      "purpose": "Überblick über die Anwendungsarchitektur und die Interaktion der Komponenten auf hoher Ebene"
    },
    {
      "title": "Frontend",
      "purpose": "Struktur und Komponenten der Frontend-Anwendung",
      "parent": "Architekturübersicht"
    },
    {
      "title": "React-Komponenten",
      "purpose": "Detaillierte Dokumentation der React-Komponenten, ihrer Props und Verwendung",
      "parent": "Frontend"
    },
    {
      "title": "State Management",
      "purpose": "Verwaltung des Anwendungszustands, einschließlich Stores und Datenfluss",
      "parent": "Frontend"
    },
    {
      "title": "Backend",
      "purpose": "Backend-Services, APIs und Datenschicht",
      "parent": "Architekturübersicht"
    },
    {
      "title": "API-Endpunkte",
      "purpose": "REST-API-Dokumentation einschließlich Endpunkten sowie Request- und Response-Formaten",
      "parent": "Backend"
    }
  ]
}
```

<div id="best-practices">
  ## Bewährte Vorgehensweisen
</div>

<div id="1-use-repo-notes-strategically">
  ### 1. Repo Notes strategisch einsetzen
</div>

* Geben Sie Kontext dazu, welche Teile Ihrer Codebasis am wichtigsten sind
* Nennen Sie spezifische Ordner oder Komponenten, die priorisiert werden sollen
* Erläutern Sie die Beziehungen zwischen verschiedenen Teilen Ihres Systems

<div id="2-organize-pages-logically">
  ### 2. Seiten logisch strukturieren
</div>

* Beginnen Sie mit übergeordneten Übersichtsseiten
* Nutzen Sie über- und untergeordnete Seiten, um klare Hierarchien zu erstellen
* Fassen Sie verwandte Funktionen bzw. Funktionalitäten zusammen

<div id="3-be-specific-in-page-purposes">
  ### 3. Seien Sie konkret bei den Zwecken der Seiten
</div>

* Geben Sie klar an, was jede Seite dokumentieren soll
* Nennen Sie spezifische Verzeichnisse, Dateien oder Konzepte, auf die der Fokus liegen soll
* Geben Sie ausreichend Details an, damit das System Ihre Absicht versteht

<div id="4-address-known-gaps">
  ### 4. Bekannte Lücken gezielt angehen
</div>

* Wenn Sie wissen, dass bestimmte Teile Ihrer Codebasis übersehen werden, schließen Sie sie explizit ein
* Verwenden Sie aussagekräftige Titel, aus denen klar hervorgeht, was abgedeckt werden soll

<div id="troubleshooting-common-issues">
  ## Fehlerbehebung bei häufigen Problemen
</div>

<div id="only-certain-folders-are-being-documented">
  ### "Nur bestimmte Ordner werden dokumentiert"
</div>

Dies ist das klassische Problem großer Repositories.

**Lösung:** Verwende `.devin/wiki.json`, um explizit festzulegen, welche Teile deines Codes dokumentiert werden sollen.

<Tip>Beginne damit, nur repo\_notes zu aktualisieren, und generiere das Wiki mit diesem zusätzlichen Kontext neu, um zu prüfen, ob das aktualisierte Wiki die fehlenden Ordner enthält. Füge das pages-Array nur hinzu, wenn es wirklich nötig ist.</Tip>

<div id="important-components-are-missing-from-the-wiki">
  ### "Wichtige Komponenten fehlen im Wiki"
</div>

Fügen Sie für diese Komponenten eigene Seiten hinzu und verwenden Sie repo\_notes, um ihre Bedeutung hervorzuheben.

<Tip>Denken Sie daran: DeepWiki generiert nur die Seiten, die in diesem Array enthalten sind. Stellen Sie also sicher, dass alle Seiten vorhanden sind, nicht nur die fehlende Seite.</Tip>

```json theme={null}
{
  "repo_notes": [
    {
      "content": "Das Verzeichnis [missing-component] ist kritisch für die Anwendung und muss vollständig dokumentiert werden."
    }
  ],
  "pages": [
    {
      "title": "Name der kritischen Komponente",
      "purpose": "Dokumentiert das Verzeichnis [missing-component] und seine Funktionalität"
    }
  ]
}
```

<div id="getting-started">
  ## Erste Schritte
</div>

1. Erstelle `.devin/wiki.json` im Stammverzeichnis deines Repositories
2. Füge `repo_notes` hinzu, in denen du die Struktur und Prioritäten deiner Codebasis erläuterst
3. Gib bei Bedarf **alle** Seiten an, die erstellt werden sollen, mit klaren Titeln und Zwecken
4. Committe die Datei und generiere dein Wiki neu

Das System erstellt die Dokumentation nun auf Basis deiner expliziten Anweisungen statt durch vollständig automatische Analyse und sorgt so für eine umfassendere und genauere Abdeckung großer Repositories.