I agree with others this seems somewhat over-engineered; you can get similar results with a good prompt/skill; I guess the rest of the implementation here is intended as an agent-maintainer.
We need to make an effort to distinguish “this is a thing for humans” vs “this is a thing for bots” in our naming IMHO. In that respect, “open wiki” is not such a great name. “Agent Wiki” or similar would be better.
Without such a qualifier, “wiki” carries a strong connotation of (usually collaborative) human involvement. That’s literally what it’s famous for.
Thats just my $0.02 on the naming. I definitely think it’s a worthwhile idea. All the best.
maintaining an LLM wiki has been a lot more effort than I thought, at least if we are trying to maintain a high quality in structure and writing comprehension (for easier lookups both for the agent and human). Are people just shotgunning their agent wikis or how
> maintaining an LLM wiki has been a lot more effort than I thought
Same here. Wikis start out good, but either devolve in a journal-y mess after a while and many updates, or require constant expensive rewrites. (I didn't use the software of the OP.)
Wikis start out good, but get stale too quick and become useless or worse confusing.
I’ve experienced this over and over again to strongly believe it.
I genuinely wonder if throwing LLMs at this problem would solve it at least to some extent. Make a LLM agent whose sole purpose is to act as a librarian. It periodically reviews _all_ of the wiki and validates them against codebases, newer docs, anything. Whatever it finds, it should be allowed to intelligently quiz the team/dev whether something is right/stale/wrong and updated it accordingly.
If one tolerates that toil - answering questions of a library bot, would it result in a usable wiki base?
I think writing the instructions for such an agent would be almost as much work as maintaining the wiki and learning your preferences yourself (and both may be coupled intrinsically unless you already manage a large enough notes system). The crucial problem is that the agents lack 1. taste and 2. the ability to know what is good for them. I've bounced off trying these like three times over the last couple of years, twice after Feb 2026, simply because it requires way too much toil that would be better (IMO) put into maintaining your own knowledge base, where at least that toil would result in learning
Have a look at the prompts in the GitHub [0]. It defines a System Prompt and specifies the documentation structure. This would allow you to switch coding agents, instead of relying on how your coding agent interprets the command "write docs".
I've had a number of people send me tools like this at work, and easily 50% of them can't answer basic questions like "what's the reason someone would adopt this tool" or "how do you know that it will achieve its stated goals". Agents are good at reading code, I can't imagine what the point of autogenerating agent context could be if it's not showing demonstrable cost benefits.
Unless it's about motivation and other things that can't be inferred from the code (and comments on such are missing), just ask the agent. Give it an LSP or code intel MCP to do it better.
I think it's own sub-dir OpenWiki serves as an example of the sort of output you might get:
https://github.com/langchain-ai/openwiki/blob/main/openwiki/...
I agree with others this seems somewhat over-engineered; you can get similar results with a good prompt/skill; I guess the rest of the implementation here is intended as an agent-maintainer.
We need to make an effort to distinguish “this is a thing for humans” vs “this is a thing for bots” in our naming IMHO. In that respect, “open wiki” is not such a great name. “Agent Wiki” or similar would be better.
Without such a qualifier, “wiki” carries a strong connotation of (usually collaborative) human involvement. That’s literally what it’s famous for.
Thats just my $0.02 on the naming. I definitely think it’s a worthwhile idea. All the best.
This is mostly a thin clintypescript wrapper around the prompts.
This could have been a SKILL
Yeah I went looking: https://github.com/langchain-ai/openwiki/blob/main/src/agent...
maintaining an LLM wiki has been a lot more effort than I thought, at least if we are trying to maintain a high quality in structure and writing comprehension (for easier lookups both for the agent and human). Are people just shotgunning their agent wikis or how
> maintaining an LLM wiki has been a lot more effort than I thought
Same here. Wikis start out good, but either devolve in a journal-y mess after a while and many updates, or require constant expensive rewrites. (I didn't use the software of the OP.)
Wikis start out good, but get stale too quick and become useless or worse confusing.
I’ve experienced this over and over again to strongly believe it.
I genuinely wonder if throwing LLMs at this problem would solve it at least to some extent. Make a LLM agent whose sole purpose is to act as a librarian. It periodically reviews _all_ of the wiki and validates them against codebases, newer docs, anything. Whatever it finds, it should be allowed to intelligently quiz the team/dev whether something is right/stale/wrong and updated it accordingly.
If one tolerates that toil - answering questions of a library bot, would it result in a usable wiki base?
I think writing the instructions for such an agent would be almost as much work as maintaining the wiki and learning your preferences yourself (and both may be coupled intrinsically unless you already manage a large enough notes system). The crucial problem is that the agents lack 1. taste and 2. the ability to know what is good for them. I've bounced off trying these like three times over the last couple of years, twice after Feb 2026, simply because it requires way too much toil that would be better (IMO) put into maintaining your own knowledge base, where at least that toil would result in learning
What does this do better than just asking your agent to "write docs" or a more robustly defined prompt/skill?
Have a look at the prompts in the GitHub [0]. It defines a System Prompt and specifies the documentation structure. This would allow you to switch coding agents, instead of relying on how your coding agent interprets the command "write docs".
[0]: https://github.com/langchain-ai/openwiki/blob/main/src/agent...
I swear most of these tools are made for the sake of it…
While good old prompting is often better than plan mode or superpower skills.
I've had a number of people send me tools like this at work, and easily 50% of them can't answer basic questions like "what's the reason someone would adopt this tool" or "how do you know that it will achieve its stated goals". Agents are good at reading code, I can't imagine what the point of autogenerating agent context could be if it's not showing demonstrable cost benefits.
This is what we do. The same agent writing the code can also write the docs.
How does the ability to search code snippets and symbols compare to Codegraph?
Unless it's about motivation and other things that can't be inferred from the code (and comments on such are missing), just ask the agent. Give it an LSP or code intel MCP to do it better.