Moxie Docs: Knowledgebases - Automated documentation for developers, users, and AI Tools

Now in Beta: Public Sites! Create auto-generated, public-facing help centers and knowledgebases at . Features rich layouts, white-labelling, full search, and no vendor lock-in. Integrates directly with Changelog! Example: Also shipped: Webhooks & Slack integration for indexing/PR alerts UI/UX pagination & bulk action improvements DB/infrastructure upgrades for faster loading Continued improvements on document generation quality

Add a comment

Replies

Best
💡 Bright idea

the code-vs-docs source-of-truth question got covered for the bug scenario, but there's a different case worth asking about: forward-looking design docs or RFCs describing a feature that's planned but not built yet. since code is ground truth for drift detection, does Moxie treat a doc describing not-yet-implemented behavior as "drift" and try to flag or rewrite it toward what the code currently does, or is there a way to mark a doc as intentionally ahead of the code so it doesn't get flattened into just describing the present state?

 Great idea! We do not check for this specifically yet, but I am working on it right now 🫡 we will flag RFCs / ADRs / Plans and detect when the implementation is done, then flag them for either removal or rewrite / combine with a relevant doc surface.

The Friday Cleanup idea is nicely restrained. Batching doc drift into one reviewable PR, with nothing auto-merging, feels like a much easier habit for a team to trust.

 Exactly! I want Moxie Docs to be unobtrusive but deliver real value. The passive context + conventions & doc actions our MCP gives agents means docs are also being improved / maintained passively during the week by anyone using AI tools, the Friday Recap is the last line defense closing that gap.

What could you build with GPT-5.6 that wasn’t practical before?
GPT-5.6 made both our development speed significantly faster and with higher confidence in code correctness via Codex, but also directly integrates into the core of Moxie Docs to allow us to generate, analyze, organize, and produce rich and useful documentation for all types of repos users connect, giving us the versatility and robustness that any non-AI solution would struggle with greatly.

This is interesting. What's the indexing latency on a large monorepo with frequent commits?

 indexing starts immediately and begins surfacing insights / opportunities immediately! Within minutes the MCP will have codebase context and conventions start getting populated.

For a full index depending on repo size could be up to 5/10 minutes - but the value is that it’s never a one time thing, we continually improve / re scan over time - code changes faster than ever with AI tooling so we directly connect to the tools where they work (AGENTS.md, skills, MCP, etc) so our detection has to keep up pace with any repos development speed.

Is this a kind of protection against accidental changes made by the AI?

 we don’t make any changes on your codebase! All documentation updates, changelog entries, and public knowledgebase pages are opened via a PR request to your connected codebase, or require a user to 1-click to publish (for changelog / knowledge bases).

We understand AI can make mistakes and the only thing worse than no docs is wrong docs. We surface suggestions but leave the power to decide when they ship in the hands of maintainers.

the PR check that keeps docs honest is the part that would actually get me to adopt this - every docs tool I've tried eventually goes stale because nothing forces the update at merge time. does it block the PR outright when docs drift too far from the code change, or just flag it as a warning someone can ignore?

 We run via the checks in GitHub as well as leave comments in the PR - so from the GitHub side you can configure a passing moxie docs check to be required. But our Friday recap is meant to solve that directly as well, every Friday we open a PR automatically that fixes, deletes, updates, etc any docs that may have drifted from recent changes or weren’t already documented.

The PR check is the real forcing function here. Quick question—when an agent hits undocumented code through the MCP, does it try to fill the gap or just work around it? That behavior probably determines whether this compounds your docs problem or solves it.

 We add guidance to the for any repo connected (we propose the changes via PR - you merge), expose MCP tools, and an agent skill to instruct agents to update any docs in the repo that they changed the behavior of, or to add new docs (or remove) if they add new features or fully remove described ones!

The PR checks that keep docs honest caught my eye. I've tried repo docs that looked great for a week and then drifted immediately. Does the MCP context use only generated docs, or can it fall back to code/recent PRs when the docs are stale?

 it will cite both in-repo docs - as well as the conventions & context moxie docs generates / identifies from the codebase directly

Documentation becomes much more valuable when people trust it's always current.

Curious—do teams adopt Moxie Docs to save documentation effort, or because it reduces the friction of sharing reliable knowledge?