> ## Documentation Index
> Fetch the complete documentation index at: https://docs.devin.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# DeepWiki repository wikis
> DeepWiki auto-generates architecture diagrams, documentation, and source links for every repo, configured with a .devin/wiki.json file.
## Overview
Devin now automatically indexes your repos and produces wikis with architecture diagrams, links to sources, and summaries of your codebase.
Use it to get up to speed on unfamiliar parts of your codebase - check it out [in your sidebar](https://app.devin.ai/wiki).
[Ask Devin](/work-with-devin/ask-devin) will use information in the Wiki to better understand and find the relevant context in your codebase. Ask Devin's advanced code search capabilities, combined with DeepWiki, produce detailed and accurate answers grounded in your code.
DeepWiki will be autogenerated when connecting repositories during onboarding.
## For Public Repos
A free version of **DeepWiki** and [Ask Devin](/work-with-devin/ask-devin) that works with public GitHub repositories is now available. It automatically generates architecture diagrams, documentation, and links to source code to help you understand unfamiliar codebases quickly. You can also ask complex questions about the codebase to get context-grounded specific answers.
The full Ask Devin experience, including advanced code search, planning, and session creation, is available in the [Devin app](https://app.devin.ai). Public DeepWiki and the DeepWiki MCP provide basic documentation and Q\&A capabilities.
Visit [deepwiki.com](https://deepwiki.com/) to start exploring popular open-source repositories like React, TensorFlow, LangChain, and many more. You can also submit your own public GitHub repository URL for indexing.
[Try DeepWiki Now →](https://deepwiki.com/)
## Effort levels and cost
Wiki generation runs at one of three effort levels, configurable per org (and overridable per repo) from the wiki page:
| Effort level | Approximate cost | Requirements |
| ------------- | --------------------- | ---------------------------------------- |
| Low (default) | Free | None |
| Medium | \~5-10 ACUs per wiki | Active subscription or available credits |
| High | \~20-40 ACUs per wiki | Active subscription or available credits |
Medium and high effort wikis are billed against your team's ACU usage, so they require an active subscription or a positive credit balance. If your team has neither, generation is rejected and no wiki is produced — add credits or switch the effort level to low.
Enterprise orgs always run at low effort; the setting is not configurable for them.
## Steering DeepWiki
The `.devin/wiki.json` file allows you to steer Devin's default wiki generation behavior, which is especially important for large repositories that may hit built-in limits.
If a `.devin/wiki.json` file is found in your repository's root directory during wiki generation, we'll use the provided `repo_notes` and `pages` to steer wiki generation. Both fields are required, and `pages` must list at least one page. When a config file is present, we bypass the default cluster-based planning and create exactly the pages you specify — so list every page you want. This ensures that the important parts of your codebase are documented even when the automatic system would otherwise skip them.
## Configuration Format
Create a `.devin/wiki.json` file in your repository root with the following structure:
```json theme={null}
{
"repo_notes": [
{
"content": "This repository contains the main UI components in the cui/ folder, which should be prioritized in documentation",
"author": "Team Lead"
}
],
"pages": [
{
"title": "CUI Components Overview",
"purpose": "Document the cui/ folder structure and main UI components",
"parent": null
},
{
"title": "Authentication System",
"purpose": "Document the authentication flow and related components",
"parent": null
},
{
"title": "Login Components",
"purpose": "Detailed documentation of login-related UI components",
"parent": "Authentication System"
}
]
}
```
## Configuration Options
### repo\_notes (Array, required)
Provides context and guidance to help the documentation system understand your repository better. Include the `repo_notes` key even if you have no notes to add — use an empty array (`[]`).
* **content** (string, required): The note content (max 10,000 characters)
* **author** (string, optional): Who wrote the note
### pages (Array, required)
Specifies exactly which pages should be created in your wiki.
This field is required and must contain at least one page. Pages are treated as explicit instructions: only the pages you define in the JSON will be generated, no more, no less. A `.devin/wiki.json` that omits `pages` (or leaves it empty) is rejected, so list every page you want created.
* **title** (string, required): The page title (must be unique and non-empty)
* **purpose** (string, required): What this page should document
* **parent** (string, optional): Title of the parent page for hierarchical organization
* **page\_notes** (array, optional): Additional notes specific to this page
### Validation Limits
* Maximum 30 pages (80 for enterprise)
* Maximum 100 total notes (repo\_notes + all page\_notes combined)
* Maximum 10,000 characters per note
* Page titles must be unique and non-empty
## Practical Examples
### Example 1: Use Repo Notes to Emphasize Priorities
Use `repo_notes` to tell Devin what to emphasize, and list the `pages` you want alongside them. Notes guide *how* each page is written; `pages` determines *which* pages are created.
```json theme={null}
{
"repo_notes": [
{
"content": "The repository contains three main areas: the frontend/ folder with React components, the backend/ folder with API services, and the infra/ folder with deployment scripts. Documentation should emphasize how these parts interact and highlight the backend API layer as the highest priority."
}
],
"pages": [
{
"title": "Backend API Layer",
"purpose": "Document the backend/ API services and how the frontend and infra interact with them"
},
{
"title": "Frontend Overview",
"purpose": "Document the frontend/ React components and how they consume the backend API"
}
]
}
```
### Example 2: Ensuring Specific Folders Are Documented
If your large repository has important folders that aren't being included in the wiki, add a page for each one and use `repo_notes` to explain why they matter:
```json theme={null}
{
"repo_notes": [
{
"content": "The cui/ folder contains critical UI components that must be documented. The backend/ folder contains the main API logic. The utils/ folder has shared utilities used throughout the codebase."
}
],
"pages": [
{
"title": "CUI Components",
"purpose": "Document the cui/ folder and its critical UI components"
},
{
"title": "Backend API Logic",
"purpose": "Document the main API logic in the backend/ folder"
},
{
"title": "Shared Utilities",
"purpose": "Document the shared utilities in the utils/ folder"
}
]
}
```
### Example 3: Addressing Missing Components
If you notice certain parts of your codebase aren't being documented, add a page for each and emphasize them in `repo_notes`:
```json theme={null}
{
"repo_notes": [
{
"content": "The testing/ directory contains important test utilities and patterns that developers need to understand. The scripts/ directory has deployment and maintenance scripts that are crucial for operations."
}
],
"pages": [
{
"title": "Testing Utilities and Patterns",
"purpose": "Document the test utilities and patterns in the testing/ directory"
},
{
"title": "Operational Scripts",
"purpose": "Document the deployment and maintenance scripts in the scripts/ directory"
}
]
}
```
### Example 4: Hierarchical Documentation Structure
For complex repositories, organize pages hierarchically:
```json theme={null}
{
"repo_notes": [
{
"content": "This is a full-stack application with distinct frontend, backend, and shared components that should be documented separately but with clear relationships."
}
],
"pages": [
{
"title": "Architecture Overview",
"purpose": "High-level overview of the application architecture and how components interact"
},
{
"title": "Frontend",
"purpose": "Frontend application structure and components",
"parent": "Architecture Overview"
},
{
"title": "React Components",
"purpose": "Detailed documentation of React components, their props, and usage",
"parent": "Frontend"
},
{
"title": "State Management",
"purpose": "How application state is managed, including stores and data flow",
"parent": "Frontend"
},
{
"title": "Backend",
"purpose": "Backend services, APIs, and data layer",
"parent": "Architecture Overview"
},
{
"title": "API Endpoints",
"purpose": "REST API documentation including endpoints, request/response formats",
"parent": "Backend"
}
]
}
```
## Best Practices
### 1. Use Repo Notes Strategically
* Provide context about which parts of your codebase are most important
* Mention specific folders or components that should be prioritized
* Explain relationships between different parts of your system
### 2. Organize Pages Logically
* Start with high-level overview pages
* Use parent-child relationships to create clear hierarchies
* Group related functionality together
### 3. Be Specific in Page Purposes
* Clearly state what each page should document
* Mention specific directories, files, or concepts to focus on
* Provide enough detail for the system to understand your intent
### 4. Address Known Gaps
* If you know certain parts of your codebase are being missed, explicitly include them
* Use descriptive titles that make it clear what should be covered
## Troubleshooting Common Issues
### "Only certain folders are being documented"
This is the classic large repository problem.
**Solution:** Use `.devin/wiki.json` to explicitly specify which parts of your codebase should be documented.
Add a page to the `pages` array for each folder you want covered, and use `repo_notes` to explain why they matter. The wiki generates only the pages you list, so any folder without a page won't appear.
### "Important components are missing from the wiki"
Add specific pages for these components and use repo\_notes to emphasize their importance.
Remember: The DeepWiki will generate only the pages included in this array, so ensure all pages are present, not just the missing page.
```json theme={null}
{
"repo_notes": [
{
"content": "The [missing-component] directory is critical to the application and must be documented thoroughly."
}
],
"pages": [
{
"title": "Critical Component Name",
"purpose": "Document the [missing-component] directory and its functionality"
}
]
}
```
## Getting Started
1. Create `.devin/wiki.json` in your repository root
2. Add repo\_notes explaining your codebase structure and priorities
3. Specify **all** pages you want created, with clear titles and purposes (at least one page is required)
4. Commit the file and regenerate your wiki
The system will now create documentation based on your explicit instructions rather than fully automatic analysis, ensuring comprehensive and more accurate coverage of large repositories.
The `.devin/wiki.json` file allows you to steer Devin's default wiki generation behavior, which is especially important for large repositories that may hit built-in limits.
If a `.devin/wiki.json` file is found in your repository's root directory during wiki generation, we'll use the provided `repo_notes` and `pages` to steer wiki generation. Both fields are required, and `pages` must list at least one page. When a config file is present, we bypass the default cluster-based planning and create exactly the pages you specify — so list every page you want. This ensures that the important parts of your codebase are documented even when the automatic system would otherwise skip them.
## Configuration Format
Create a `.devin/wiki.json` file in your repository root with the following structure:
```json theme={null}
{
"repo_notes": [
{
"content": "This repository contains the main UI components in the cui/ folder, which should be prioritized in documentation",
"author": "Team Lead"
}
],
"pages": [
{
"title": "CUI Components Overview",
"purpose": "Document the cui/ folder structure and main UI components",
"parent": null
},
{
"title": "Authentication System",
"purpose": "Document the authentication flow and related components",
"parent": null
},
{
"title": "Login Components",
"purpose": "Detailed documentation of login-related UI components",
"parent": "Authentication System"
}
]
}
```
## Configuration Options
### repo\_notes (Array, required)
Provides context and guidance to help the documentation system understand your repository better. Include the `repo_notes` key even if you have no notes to add — use an empty array (`[]`).
* **content** (string, required): The note content (max 10,000 characters)
* **author** (string, optional): Who wrote the note
### pages (Array, required)
Specifies exactly which pages should be created in your wiki.
This field is required and must contain at least one page. Pages are treated as explicit instructions: only the pages you define in the JSON will be generated, no more, no less. A `.devin/wiki.json` that omits `pages` (or leaves it empty) is rejected, so list every page you want created.
* **title** (string, required): The page title (must be unique and non-empty)
* **purpose** (string, required): What this page should document
* **parent** (string, optional): Title of the parent page for hierarchical organization
* **page\_notes** (array, optional): Additional notes specific to this page
### Validation Limits
* Maximum 30 pages (80 for enterprise)
* Maximum 100 total notes (repo\_notes + all page\_notes combined)
* Maximum 10,000 characters per note
* Page titles must be unique and non-empty
## Practical Examples
### Example 1: Use Repo Notes to Emphasize Priorities
Use `repo_notes` to tell Devin what to emphasize, and list the `pages` you want alongside them. Notes guide *how* each page is written; `pages` determines *which* pages are created.
```json theme={null}
{
"repo_notes": [
{
"content": "The repository contains three main areas: the frontend/ folder with React components, the backend/ folder with API services, and the infra/ folder with deployment scripts. Documentation should emphasize how these parts interact and highlight the backend API layer as the highest priority."
}
],
"pages": [
{
"title": "Backend API Layer",
"purpose": "Document the backend/ API services and how the frontend and infra interact with them"
},
{
"title": "Frontend Overview",
"purpose": "Document the frontend/ React components and how they consume the backend API"
}
]
}
```
### Example 2: Ensuring Specific Folders Are Documented
If your large repository has important folders that aren't being included in the wiki, add a page for each one and use `repo_notes` to explain why they matter:
```json theme={null}
{
"repo_notes": [
{
"content": "The cui/ folder contains critical UI components that must be documented. The backend/ folder contains the main API logic. The utils/ folder has shared utilities used throughout the codebase."
}
],
"pages": [
{
"title": "CUI Components",
"purpose": "Document the cui/ folder and its critical UI components"
},
{
"title": "Backend API Logic",
"purpose": "Document the main API logic in the backend/ folder"
},
{
"title": "Shared Utilities",
"purpose": "Document the shared utilities in the utils/ folder"
}
]
}
```
### Example 3: Addressing Missing Components
If you notice certain parts of your codebase aren't being documented, add a page for each and emphasize them in `repo_notes`:
```json theme={null}
{
"repo_notes": [
{
"content": "The testing/ directory contains important test utilities and patterns that developers need to understand. The scripts/ directory has deployment and maintenance scripts that are crucial for operations."
}
],
"pages": [
{
"title": "Testing Utilities and Patterns",
"purpose": "Document the test utilities and patterns in the testing/ directory"
},
{
"title": "Operational Scripts",
"purpose": "Document the deployment and maintenance scripts in the scripts/ directory"
}
]
}
```
### Example 4: Hierarchical Documentation Structure
For complex repositories, organize pages hierarchically:
```json theme={null}
{
"repo_notes": [
{
"content": "This is a full-stack application with distinct frontend, backend, and shared components that should be documented separately but with clear relationships."
}
],
"pages": [
{
"title": "Architecture Overview",
"purpose": "High-level overview of the application architecture and how components interact"
},
{
"title": "Frontend",
"purpose": "Frontend application structure and components",
"parent": "Architecture Overview"
},
{
"title": "React Components",
"purpose": "Detailed documentation of React components, their props, and usage",
"parent": "Frontend"
},
{
"title": "State Management",
"purpose": "How application state is managed, including stores and data flow",
"parent": "Frontend"
},
{
"title": "Backend",
"purpose": "Backend services, APIs, and data layer",
"parent": "Architecture Overview"
},
{
"title": "API Endpoints",
"purpose": "REST API documentation including endpoints, request/response formats",
"parent": "Backend"
}
]
}
```
## Best Practices
### 1. Use Repo Notes Strategically
* Provide context about which parts of your codebase are most important
* Mention specific folders or components that should be prioritized
* Explain relationships between different parts of your system
### 2. Organize Pages Logically
* Start with high-level overview pages
* Use parent-child relationships to create clear hierarchies
* Group related functionality together
### 3. Be Specific in Page Purposes
* Clearly state what each page should document
* Mention specific directories, files, or concepts to focus on
* Provide enough detail for the system to understand your intent
### 4. Address Known Gaps
* If you know certain parts of your codebase are being missed, explicitly include them
* Use descriptive titles that make it clear what should be covered
## Troubleshooting Common Issues
### "Only certain folders are being documented"
This is the classic large repository problem.
**Solution:** Use `.devin/wiki.json` to explicitly specify which parts of your codebase should be documented.