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
Moxie Docs
Moxie Docs
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?
Moxie Docs
@galdayan 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 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.
The “living docs + MCP context for your GitHub repos” line is interesting. How does Moxie Docs decide what repo context is safe or relevant to expose through MCP? For example, can teams scope it to specific folders, branches, or docs, or is the context built from the whole repo by default?
Moxie Docs
@ivory_xuxuxu We index & analyze the entire repo by default, but agents get a citation-backed packet (conventions, docs, gaps, commands, and team notes) we filter out anything in .gitignore by default (as well as some known folders like build/dist outputs, temp files, etc.) and agents can pull path-relevant context directly, like "I am about to touch these files, what docs do those impact?" (simplified but the general idea via the MCP).
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!