CodeWiki produces high-quality documentation. Its coverage of business flows and implementation details is much more useful than a simple code summary.
Currently, the generated Markdown files are mostly stored in a flat directory. For large repositories, this makes it harder for an agent to navigate by business area and find the relevant documents. Would you consider an optional hierarchical output structure, with an index at each level?
Would an Open Knowledge Format (OKF)–compatible export also be worth exploring? Structured metadata such as document type, related modules, and source-code references might help agents select the right documents without loading unrelated content. The potential improvements in token usage and context quality are a hypothesis that could be evaluated against real retrieval tasks.
I’d suggest keeping the current output as the default, with hierarchical output or OKF export as optional features. Any new structure would need to keep file paths, internal links, module_tree.json, incremental updates, and the existing viewer consistent. I’d also be interested to know whether CodeWiki’s current MCP capabilities already address part of this use case.
CodeWiki produces high-quality documentation. Its coverage of business flows and implementation details is much more useful than a simple code summary.
Currently, the generated Markdown files are mostly stored in a flat directory. For large repositories, this makes it harder for an agent to navigate by business area and find the relevant documents. Would you consider an optional hierarchical output structure, with an index at each level?
Would an Open Knowledge Format (OKF)–compatible export also be worth exploring? Structured metadata such as document type, related modules, and source-code references might help agents select the right documents without loading unrelated content. The potential improvements in token usage and context quality are a hypothesis that could be evaluated against real retrieval tasks.
I’d suggest keeping the current output as the default, with hierarchical output or OKF export as optional features. Any new structure would need to keep file paths, internal links, module_tree.json, incremental updates, and the existing viewer consistent. I’d also be interested to know whether CodeWiki’s current MCP capabilities already address part of this use case.