Firstly I think this is a super interesting approach to a real problem. I think it offers a lot. I wonder about frustrations around consistency etc though. Have you had any?

I have been building a slightly different solution to the same problem. So far I’m pretty happy with the results and I have enough returning users that I think others are too (https://sdocs.dev/analytics).

I’ve built SmallDocs (https://sdocs.dev; Show HN: https://news.ycombinator.com/item?id=47777633).

SDocs is cli (`sdoc file.md`) -> instantly rendered Markdown file in the browser

When you install the cli it gives you the option to add a note in your base agent file (`~/.claude/CLAUDE.md`, etc.). This means every agent chat knows about SDocs and you can say “sdoc me the plan when you’re done with it” and the file will pop open instead of you having to find that terminal session to know it’s done.

Going browser first means you’re not required to install anything to get a great experience.

Despite being in the browser, the content of SDocs rendered Markdown files remain entirely local to you. SDoc urls contain your markdown document's content in compressed base64 in the url fragment (the bit after the `#`):

https://sdocs.dev/#md=GzcFAMT...(this is the contents of your document)...

The url fragment is never sent to the server (see https://developer.mozilla.org/en-US/docs/Web/URI/Reference/F...: "The fragment is not sent to the server when the URI is requested; it is processed by the client").

The sdocs.dev webapp is purely a client side decoding and rendering engine for the content stored in the url fragment.

This also means you can share your .md files privately by sharing the url.

To go a bit deeper towards the HTML side of things I’ve added tagged code blocks that the agent is given documentation on how to use. Eg ```chart or ```mermaid (for mermaid diagrams). These then become interactive elements on the page (mermaid is best example of this currently)