Claude Code adds `frontend-slides` for HTML briefs and publishable slides

• Anthropic's Claude Code account promoted a new frontend-slides plugin with direct install commands, and paired it with Claude's existing artifact publishing flow, via claude_code's plugin post.
• The pitch is not just prettier output. Addy Osmani's reaction framed HTML as a richer human-facing canvas for plans, specs, and throwaway editors, while trq212's example gallery showed that claim with side by side plans, annotated diffs, prototypes, and SVG diagrams.
• The tradeoff is already clear in the replies. dexhorthy's thread split HTML for human leverage from markdown for model efficiency, and plannotator's token estimate put HTML at roughly 5x the tokens of markdown before optimization.
• Practitioners are converging on a mixed stack, not a clean replacement. omarsar0's stack post, kylejeong's summary, and omarsar0's artifact workflow all described markdown plus HTML, rather than HTML alone.

You can browse Thariq Shihipar's HTML examples, skim Simon Willison's writeup and prompt patterns, and inspect Anthropic's own frontend-design skill. The odd little reveal is how fast the idea jumped from a tweet debate into product surface area: claude_code pushed a marketplace install, charlieholtz said HTML preview would land in the next release of his editor, and the same Claude Code post pointed people straight at "Publish artifact."

The official post was concrete: install from the marketplace, generate an HTML brief instead of a long markdown file, and chain multiple pages into slides. The two commands were:

• /plugin marketplace add zarazhangrui/frontend-slides
• /plugin install frontend-slides@frontend-slides

The attached screenshots in claude_code's post show both halves of the workflow: a browser-rendered slide deck and the Claude UI path for sharing it through "Copy" to "Publish artifact."

That makes this less like a design demo and more like a portable reporting format. The story summary in Addy Osmani's post and the example catalog at Thariq's gallery line up with the same use case, agents generating something humans will actually click through.

The examples page is where the workflow gets specific. It groups HTML outputs into categories that markdown handles poorly in one long file:

• Exploration and planning
• Code review and understanding
• Design systems and component variants
• Prototyping and interaction flows
• Illustrations and diagrams
• Reports, decks, and custom editors

Simon Willison's response post adds the most useful prompt pattern: ask for an HTML artifact that explains a PR, renders the diff, and annotates the parts you care about. Simon Willison's exploit explanation shows the same trick on a Linux privilege escalation proof of concept, with numbered steps, a safety note, and a pattern-purpose table inside one page.

The strongest pushback was technical, not aesthetic. Dex Horthy broke the split into two jobs: markdown is a compact human summary, and it is also a compact model summary. HTML solves the first job better, but it expands the second.

Plannotator, describing an "html spec" feature under review, estimated HTML at about 5x the tokens of markdown before cleanup, and said Tailwind or CDN styles could roughly halve raw CSS overhead plannotator's token estimate. Antirez made the same objection from a different angle, arguing that moving from semantically dense markdown to semantically sparse HTML loses too much compression antirez's reply.

That is why the practical compromise keeps showing up in the evidence:

• dexhorthy said his teams use markdown for most cases, with supplemental HTML when human digestion matters.
• badlogicgames said HTML works for non-technical collaboration, while engineering work falls back to code plus annotation tools.
• kylejeong reduced it to one line: markdown for agents, HTML for humans.
• omarsar0 explicitly called the stack "Agents + MCP + Markdown + HTML."

A second workflow surfaced alongside the markdown-versus-HTML argument: teams are using HTML as a thin app layer on top of knowledge bases, not just as a prettier export format. Omar Sar0 described dynamic artifacts sitting on top of "LLM wikis," with the artifacts talking to agents and the agents talking back to artifacts omarsar0's thread. Hila Shmuel pitched Cabinet in almost the same terms, "HTML webapps Knowledge base + AI team" Hila Shmuel's post.

That is a different category from docs. The repeated use cases in omarsar0's demo, badlogicgames' reply, and Addy Osmani's summary are interactive specs, review surfaces, monitoring dashboards, and one-off editors that let a human steer an agent without editing raw prompts.

The last interesting detail is how quickly these HTML artifacts are leaking into surrounding tooling. Charlie Holtz said his editor would add HTML preview in the next release after seeing the trend charlieholtz's HTML preview post. Claude itself already exposes a publishing path in the UI screenshot from claude_code's artifact menu screenshot.

Anthropic's own frontend-design skill also suggests the company is treating browser-native output as a first-class target, not just a hacky render step. It tells Claude Code to produce production-grade HTML, CSS, and JS with a strong visual point of view. Paired with frontend-slides, that turns the HTML artifact idea into an actual distribution path: generate, preview, publish, share.