Moxie Docs
Living docs + MCP context for your GitHub repos
210 followers
Living docs + MCP context for your GitHub repos
210 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
Launching today
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
Moxie Docs
Moxie Docs
The PR check is the part I would lead with. Docs rot because nothing in the workflow ever tells you they rotted, so a check that fails loudly on the diff is worth more than any amount of generation quality.
One thing worth thinking about on the MCP side: how the docs get chunked matters as much as how they get written. An agent pulling repo context does much better with small single-topic sections it can retrieve precisely than with one long well written page, because a long page embeds as an average of everything in it and stops matching specific questions.
Congrats on the second launch.
Moxie Docs
@paul_crinigan Absolutely - and for the MCP when we index a repo we pull out and identify conventions (these get updated periodically as they can also change over time) and any agent requesting doc info gets the documentation that exists itself, it can provide or identify any source / cited files related to the doc (for either continued examination or for identifying if work it did may have affected a doc in the repo), and any codebase context that is relevant! You can check out more on our MCP here if you're curious: https://moxiedocs.com/mcp
This feels useful because docs are starting to serve two audiences at once: humans reading the public knowledgebase, and AI agents using repo context while work is happening.
The trust boundary I’d care about is the step before something becomes public. Temporary implementation notes are often helpful for an agent, but not always safe or polished enough for users. A clear diff/review queue for “agent-found doc drift” before publishing would make this much easier to trust.
Moxie Docs
@grace_lee26 that’s exactly what our focus is! Everything runs continuously but nothing happens automatically - the control to review and merge is 100% in your hands. Moxie Docs does the heavy lifting surfacing opportunities, creating changelog items, opening PRs updating docs, and aligning / checking engineer PRs, etc but the final step of merging is always in the hands of repo maintainers.
The only thing worse than no documentation, is incorrect documentation. We take this an extra step with the new public Knowledgebases since it’s an entry point for consumers - you first merge our proposed docs into your repo (no vendor lock in), then 1-click a button to publish them live on the knowledge base.
Fantastic idea! Wondering if there is a document update every time the repo content changes? Does it run periodically? or is it all one and done (I doubt it!)
Moxie Docs
@rachid_abadli Every opened PR triggers a pass / check! Along with any AI agent utilizing the MCP, and routine checks every few hours. If docs drift from code changes - we find, fix, and surface that!
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.