Developers launch Markdown Experience Guidelines and HTML explainer tools for agent output
Independent builders shipped new specs and tools for richer agent output, including Markdown Experience Guidelines and Plannotator’s HTML render-and-annotate flow, while practitioners shared repeatable HTML explainer workflows. The cluster matters because teams are moving beyond raw Markdown toward output surfaces that can carry charts, interaction, review context, and persistent knowledge-base structure.

TL;DR
- ctatedev's spec announcement introduced Markdown Experience Guidelines, a proposal for giving plain
.mdfiles virtual pages, navigation, search, and theming, with a public spec site and GitHub repo. - plannotator's 0.19.14 release post shipped a concrete HTML review loop: Visual Explainer, browser-based render-and-annotate mode, line-range hover previews, and planning hooks, all backed by release notes.
- The strongest consensus in the thread cluster came from people like dexhorthy, omarsar0, and HilaShmuel, who framed Markdown as the compact data layer and HTML as the richer UI layer, not a clean replacement.
- Token cost stayed the main objection, because kimmonismus highlighted a 2x to 4x token penalty from the original HTML push while dexhorthy argued Markdown still wins when the goal is model efficiency.
- The other quiet shift is renderer quality: Warp's product update added tables, Mermaid, and images directly inside agent responses, which narrows the gap between raw Markdown and full HTML canvases.
You can browse the spec, inspect the reference repo, and read Plannotator's release notes. the Claude Code plugin post points to slide-style HTML briefs and a "Publish artifact" flow, while doodlestein's documentation screenshot shows a separate pattern entirely: multi-agent doc generation that already outputs 130-plus pages and deploy checks. The interesting bit is not one winner in the Markdown-versus-HTML fight. It is that builders are now shipping the missing surfaces around both.
Markdown Experience Guidelines
What shipped is unusually concrete for a format debate. ctatedev's post describes a spec for presenting Markdown with virtual pages, navigation, search, and theming, while the follow-up link post points directly to the GitHub implementation.
The pitch is narrow and pragmatic: keep "any .md file" unchanged, then add the reading affordances people normally associate with a docs app. That lands closer to a rendering contract than a markup replacement.
Community reaction immediately split three ways:
- Keep Markdown, upgrade the experience, as nummanali's reply put it, "A unified MD experience like HTML."
- Use MDX as the compromise layer, according to jxnlco's short reply and dexhorthy's MDX comment.
- Treat Markdown and HTML as separate layers in one knowledge base, the framing HilaShmuel's demo post and HilaShmuel's follow-up both used.
Plannotator's render-and-annotate loop
Plannotator turned the argument into product surface. In its feature announcement, the team said an agent can create an explainer document, open it in a browser, and let the user annotate directly over the rendered result.
The 0.19.14 release broke that into shippable parts:
- Visual Explainer skill plus HTML render-and-annotate mode, per the release summary
- Code-file line range hover previews like
file.ts:10-20, again from the release summary - Planning hooks that tell the agent about GFM syntax and let users customize planning instructions, according to the hooks follow-up
- A
/plannotator-compoundflow for auto-creating instructions, linked in the same thread - Rendering optimizations and diff-view upgrades, listed in the release notes
The notable design choice is that the original post says model invocation is turned off for the annotation step. The review surface is richer, but the expensive part does not need to stay in the loop while a human marks up the page.
HTML for humans, Markdown for models
The thread that kicked this up a notch came from karpathy, who said asking an LLM to "structure your response as HTML" works well for learning and explanation, then argued that AI output is likely to move from raw text to Markdown to HTML and eventually to more interactive visual media.
That claim spread because it matched existing workflows. Yuchenj_UW's reply described generating HTML to study papers and iterating it into a personal knowledge base. the Claude Code account suggested HTML briefs and slide decks, then pointed to Claude's artifact publishing flow for sharing them.
The pushback was just as specific:
- kimmonismus zeroed in on the 2x to 4x token overhead.
- antirez argued that moving from Markdown to HTML loses semantic density right when token efficiency matters more.
- zeeg objected to dumping HTML files into repositories as a new default.
- rabi_guha's follow-up argued the real problem is generative UI at scale, where latency and token counts become infrastructure constraints, not cosmetic tradeoffs.
The most durable synthesis came from dexhorthy, who split the job in two: Markdown is a compact summary format for humans and models, HTML is a better surface when the priority is human comprehension. omarsar0 and badlogicgames landed in roughly the same place from different angles: use both, and choose by task.
Markdown renderers are getting more ambitious
One reason the debate got blurrier this week is that Markdown surfaces are changing underneath it. Warp's product post said all agent responses now render Markdown tables, Mermaid diagrams, and images inline.
That matters because several complaints about Markdown were really complaints about weak renderers. If a terminal or agent client can already display structured tables, diagrams, and images, the gap between "Markdown output" and "HTML output" starts to look more like interactivity and layout than basic readability.
Plannotator made the same argument from the opposite side. its planning-session post said a better rendering engine can integrate Markdown directly with a codebase and agents without cluttering the source text or increasing token cost.
Docs generation is now part of the same story
The most concrete downstream example came from doodlestein's documentation-skill post, which included a screenshot of a 10-phase run over a 600,000 line monorepo. The run used 14 parallel research agents, produced 130-plus pages of MDX drafts, ran multiple polish and fresh-eyes passes, caught factual errors and contradictions, then deployed and smoke-tested the site.
That screenshot adds a different angle to the Markdown-versus-HTML argument:
- Research and drafting already happen in Markdown or MDX.
- Review quality now depends on richer docs surfaces, consistency passes, and browser delivery.
- The output is no longer a single response blob. It is a generated documentation system.
That is why nummanali's post said the discussion had already spilled past 8.1 million views. The format fight is turning into an interface stack fight, and this week produced both a spec for upgraded Markdown and tools that make HTML explainers reviewable instead of disposable.