Skip to main content

1. Broad wiki for the whole project

If you initialized Davia with your coding agent (for example davia init --agent=cursor), the agent already knows it should use Davia to generate the wiki.
In that case, even a very broad prompt like this will work:
Document this project.
Your agent will use its tooling to scan the project, generate an initial wiki, and create interactive docs and whiteboards.
If you did not run davia init —agent=<your-agent>, make sure your prompt explicitly mentions Davia and that you want a local wiki. For example: Use Davia to generate a local wiki that documents this project.

Ask your agent for a broad wiki over the whole project

2. Focused wiki for a specific part (e.g. schemas)

You can also guide your agent to document only a specific area of the codebase and structure the output in a particular way.
For example, to document only your schemas/classes and organize them in a table:
Using Davia, generate a wiki page that documents only the schemas/classes
in this project. For each schema, include a row in a table with:
- the schema name
- a short description
- its main fields and relationships.
This kind of prompt narrows the scope and gives your agent a clear output structure, resulting in a more targeted, immediately useful wiki page.

Ask your agent for a focused wiki on schemas, structured as a table

3. API spec wiki with custom components

You can also ask your agent to use custom UI components when generating documentation.
For example, to turn an API spec into a browsable gallery of endpoints using your own card and modal components:
I want to create a wiki for my API spec using a custom component. 
The UI should display each API endpoint as a card, grouped by category. 
Each card should show a short title and a concise description. 
When a user clicks a card, it should open a modal or dialog that displays the endpoint’s full details. 
The design should be clean, minimal, and readable.
Behind the scenes, Davia’s custom bundler lets your agent wire these prompts into real components, so your API documentation becomes an interactive interface instead of a static list.

Use custom components to render an API spec as interactive cards with details in a modal

4. Authentication flow architecture diagram

You can also use Davia to generate clean architecture diagrams for critical flows like authentication:
I want to document this project's authentication flow and I need a clean architecture diagram that visually explains it. 
The diagram should show the interactions between: Client → API Server → Auth Service → Database, 
including steps like credential submission, verification, token creation, and token validation. 
The final output should be visually clear, standard, and easy to understand in one glance.
Your agent will produce a visual, end‑to‑end diagram of the auth flow (client, API server, auth service, and database), which you can refine directly in Davia’s interactive canvas.

Ask your agent for a clear, end-to-end authentication flow diagram