DocsAlot Visual Editor

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.

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

You know this really addresses a genuine issue. its such a hassle to keep documents updated in multiple locations and the fact that they can alsoo be useful for AI agents is a huge bonus. i absolutely love the concept of having a single source of truth.

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.

Totally what's needed.How do you ensure stale context is not read?

@new_user_2790a57d4d Congratulations. And happy product launch.

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.

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?

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?