Moxie Docs
Living docs + MCP context for your GitHub repos
286 followers
Living docs + MCP context for your GitHub repos
286 followers
Moxie Docs indexes your GitHub repo once, then puts that understanding where the work happens: repo context inside your AI agents over MCP, a searchable docs workspace, and PR checks that keep documentation honest.
This is the 2nd launch from Moxie Docs. View more
Moxie Docs: Knowledgebases
Launched this week
Now in Beta: Public Sites!
Create auto-generated, public-facing help centers and knowledgebases at https://moxiedocs.app. Features rich layouts, white-labelling, full search, and no vendor lock-in. Integrates directly with Changelog! Example: https://docs.moxiedocs.app
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
Free Options
Launch Team / Built With
Really keen to test this out and see how it differs from using pre-commit documentation update hooks, which is my current setup. One quick question for ya - how do you handle the case where the docs are right and the code is wrong? On a bad merge, "sync to code" would happily overwrite the doc that describes the intended behavior. Does drift detection ever flag the code side, or is source always treated as ground truth?
Moxie Docs
@aidan_codefox really love this question! Moxie Docs doesn’t propose code changes so at this time we scan and index code only to understand conventions, overall context / behaviors, and capabilities (which get fed into documentation generation and our MCP), and since code is what’s running - that’s the source of truth for docs. I personally use & suggest code review tools that would catch (probably in the same PR as a doc update) that the code may have bugs or be incorrect.
What we would help with though is that reverse side - if you have your agent fix a bug, a normal flow would mean it fetches codebase context and scans similar files and tries to figure out conventions (all token burn) but then fixes the bug - maybe after some follow up prompts. With our MCP it gets your conventions and context upfront, when it fixes the bug it can automatically fetch what docs already exists, scan those only to identify if it needs to update them, and then update them for you in the same session.
Congrats on the launch! On the PR checks that keep docs honest, does it block the merge if docs go stale, or just leave a comment flagging what needs updating?
Moxie Docs
@irahimiam We run checks as GH native tie-ins so you can set it as a requirement they pass! Otherwise it will flag via comment + the failing check with details.
Moxie Docs can also be configured to automatically rewrite any PR description to match a standardized format so it’s easier for humans to review / orient any PR.
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?
Moxie Docs
@omri_ben_shoham1 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.
Moxie Docs
@nextmark We add guidance to the AGENTS.md 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!
Congrats on the launch. Living docs plus an MCP server for the same repo is a smart pairing, most tools solve doc-drift or agent-context but not both from one source of truth. Before I'd point Public Sites at a client's docs: is there a filter step before publishing that catches anything meant to stay internal, a staging URL or an internal-only heading written into the markdown, or does that rely on the team keeping the source clean themselves?
Moxie Docs
@vollos You can choose what repo docs get written to (where we open the PRs to) and that can be either public or private - and separate from the main repo or alongside your code. From there we have a layer of publishing before the doc goes live.
So the workflow is we propose a doc, you review / approve, any approved you click a button and we open a PR adding them, once you merge the last step is just clicking publish. At any time you can revoke published docs (they’d still be in your codebase though, just taken off the site).
@cadenjs Appreciate the walkthrough - the propose, approve, merge, publish chain is basically the filter step I was asking about. One follow-up on revoke: when you pull a doc off Public Sites, does that unpublish hit instantly at the edge/cache too, or can the old URL still resolve for a bit until it catches up?
Moxie Docs
@vollos Instantly updates! You can also "Pin" a public site doc so you can change it in-code / repo as much as you want and then the public site retains the stored version until you un pin it again.
@cadenjs Good to know it's instant. One more on Pin: when you unpin a doc, does that re-trigger the review/approve step, or does it just swap straight to whatever's currently in the repo?
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.
Moxie Docs
@adriancia 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.
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?
Moxie Docs
@xiaosong001 it will cite both in-repo docs - as well as the conventions & context moxie docs generates / identifies from the codebase directly