Write, structure, and publish technical documentation in a visual editor with Markdown mode, AI-assisted edits, reusable components, and version history.
Hey Product Hunt, I’m Faizan, the founder of DocsAlot.
Almost everything in software is being rebuilt for agents right now. We’re doing that too: DocsAlot gives agents access to documentation through the CLI and MCP, and AI can help create and update the content.
But we kept running into one important truth: a human still needs to make the final call before documentation becomes public.
That is why we built this editor.
The technically difficult part wasn’t putting a text box in a browser. It was building a visual editing experience without breaking the underlying Markdown. A page can move between visual and source mode while preserving its frontmatter, tables, code, links, and structure.
We also separated editing from publishing. Changes live in a working draft. A human deliberately saves a version, can return to an earlier version, and chooses exactly when that version becomes the public site.
The navigation is treated as real site data too, so moving pages and groups updates the same structure used by the published documentation.
The result is a workflow where agents can do more of the work, but people remain in control of what readers actually see.
We’re launching the first complete version of that workflow today: pull, edit, save, and publish, from the visual editor, CLI, or MCP.
I’d love to hear how your team thinks about this balance. If an agent updates your docs, what would you need to see before you feel comfortable publishing the change?
this is a pretty timely product. docs getting out of sync is already annoying , but having AI agents pull outdated or random context makes it even worse.
loved the idea of having the hosted docs, llms.txt, skill.md and MCP all coming from the same source instead of maintaining a bunch of separate layers.
the human-approval gate before publishing makes sense. what happens on the other side of that though - if an agent proposes a doc update through the CLI/MCP and a human edits or rejects most of it before saving, does the agent see what changed and why, or does it just try again from scratch next time with no memory of the correction?
@new_user_2790a57d4d that covers the "what changed" half nicely. still curious about the "why" - does the diff carry any signal about the reason for the edit, or is it just the raw before/after text, so the agent has to infer intent on its own next time?
the markdown-preserving part is what I'd actually worry about breaking, tried building something similar once and the visual mode always mangled frontmatter or code blocks eventually. curious how long you've been dogfooding this on your own docs
@wwenioaguiar for almost a year, this is indeed one of the most complex feature we have released. Do give it a shot, let me know if anything feels off.
Report
A human gate catches formatting, it doesn't catch the failure that actually costs you, which is an agent writing a code sample that reads perfectly and doesn't run. Nobody rejects a diff that looks right. You already have the CLI, so the review step I'd want is mechanical: compile the snippets, check every endpoint mentioned against the OpenAPI spec, then show the human only the pages that failed. Approving 40 pages of prose is theatre, approving the 3 flagged ones isn't.
@asadmalik901 love the idea asad, have you explored any solutions to these problems, what does your current workflow look like for this problem
Report
@new_user_2790a57d4d Not solved, just contained. Every code sample in our docs is a real file in the repo with a test that runs it in CI, so a broken snippet fails the build instead of a reader. Prose is still unguarded and that's where the rot lives, renamed endpoints and screenshots from two versions ago. The check I actually want is docs diffed against the OpenAPI spec on every merge, and we haven't built it.
Replies
DocsAlot
Hey Product Hunt, I’m Faizan, the founder of DocsAlot.
Almost everything in software is being rebuilt for agents right now. We’re doing that too: DocsAlot gives agents access to documentation through the CLI and MCP, and AI can help create and update the content.
But we kept running into one important truth: a human still needs to make the final call before documentation becomes public.
That is why we built this editor.
The technically difficult part wasn’t putting a text box in a browser. It was building a visual editing experience without breaking the underlying Markdown. A page can move between visual and source mode while preserving its frontmatter, tables, code, links, and structure.
We also separated editing from publishing. Changes live in a working draft. A human deliberately saves a version, can return to an earlier version, and chooses exactly when that version becomes the public site.
The navigation is treated as real site data too, so moving pages and groups updates the same structure used by the published documentation.
The result is a workflow where agents can do more of the work, but people remain in control of what readers actually see.
We’re launching the first complete version of that workflow today: pull, edit, save, and publish, from the visual editor, CLI, or MCP.
I’d love to hear how your team thinks about this balance. If an agent updates your docs, what would you need to see before you feel comfortable publishing the change?
Sourclip — Gemini Notebook Workspace
this is a pretty timely product. docs getting out of sync is already annoying , but having AI agents pull outdated or random context makes it even worse.
loved the idea of having the hosted docs, llms.txt, skill.md and MCP all coming from the same source instead of maintaining a bunch of separate layers.
HarnessRouter
@new_user_2790a57d4d Congratulations. And happy product launch.
Greplica
Totally what's needed.
How do you ensure stale context is not read?
Being able to review changes before publishing feels key for trust. Amazing work!
Dial
the human-approval gate before publishing makes sense. what happens on the other side of that though - if an agent proposes a doc update through the CLI/MCP and a human edits or rejects most of it before saving, does the agent see what changed and why, or does it just try again from scratch next time with no memory of the correction?
DocsAlot
@galdayan everything is version controlled, so the agent will see that a new version was created by a human or even another agent.
Dial
@new_user_2790a57d4d that covers the "what changed" half nicely. still curious about the "why" - does the diff carry any signal about the reason for the edit, or is it just the raw before/after text, so the agent has to infer intent on its own next time?
DocsAlot
@galdayan oh right, yes you are correct. It doesn't communicate the reasoning back to the agent. That is actually a really good feature.
We have to ask for the humans, the reasons for rejection that can be propagated back towards the agent.
Let me think of a good UX for this. Thanks again.
Feel free to dm, me on linkedin if you have any more thoughts about this. https://www.linkedin.com/in/eff-kay/
Softorino 💻📲
Writing help docs, the useful bit is the step someone got stuck on. Typing it yourself is the only way that detail survives into the page.
DocsAlot
@yelyzaveta_kibets thanks lisa, appreciate it.
the markdown-preserving part is what I'd actually worry about breaking, tried building something similar once and the visual mode always mangled frontmatter or code blocks eventually. curious how long you've been dogfooding this on your own docs
DocsAlot
@wwenioaguiar for almost a year, this is indeed one of the most complex feature we have released. Do give it a shot, let me know if anything feels off.
A human gate catches formatting, it doesn't catch the failure that actually costs you, which is an agent writing a code sample that reads perfectly and doesn't run. Nobody rejects a diff that looks right. You already have the CLI, so the review step I'd want is mechanical: compile the snippets, check every endpoint mentioned against the OpenAPI spec, then show the human only the pages that failed. Approving 40 pages of prose is theatre, approving the 3 flagged ones isn't.
DocsAlot
@asadmalik901 love the idea asad, have you explored any solutions to these problems, what does your current workflow look like for this problem
@new_user_2790a57d4d Not solved, just contained. Every code sample in our docs is a real file in the repo with a test that runs it in CI, so a broken snippet fails the build instead of a reader. Prose is still unguarded and that's where the rot lives, renamed endpoints and screenshots from two versions ago. The check I actually want is docs diffed against the OpenAPI spec on every merge, and we haven't built it.
DocsAlot
@asadmalik901 we have an OpenAPI spec checker integrated into the dashboard, happy to give you a demo,
https://cal.com/faizan-khan-18shuq/30min