anthropics/html-effectiveness: 20 standalone HTML examples for agent output

What the gallery is for, and who it is aimed at

The README describes this repository as a gallery of standalone HTML examples that accompany a blog post on using HTML as a flexible output format. That framing matters: this is not a tool, a library or a rendering engine. It is a set of twenty numbered pages, each a single .html file, each meant to be opened directly in a browser. The audience is anyone who produces structured output from a model or a script and is weighing HTML against Markdown, plain text or a bespoke UI. The categories in the README map to that audience: exploration, code, prototyping, communication, diagrams and research, and custom editing UIs. A reviewer who wants to see what a code review page could look like opens 03-code-review-pr.html; someone designing an internal triage flow opens 18-editor-triage-board.html. The repository solves a demonstration problem, not an engineering one. There is no runtime to evaluate, so the decision it informs is a format decision: is a single self-contained page a better carrier for this output than a Markdown document or a chat message?

How a self-contained page works here

The mechanism is deliberately thin. Each file is a complete HTML document with its styles and scripts inline, so the browser needs no network fetch beyond the file itself. The README states there is no build step and no dependencies, and the top-level listing supports that: there is no package.json, no bundler config, no asset directory. The data flow is one-directional. A person or a model writes the markup, the file is saved, and the browser renders it. Nothing persists state between files, and the index page is just a categorized list of links to the numbered pages. That constraint is the point of the format: an output artefact that can be attached, opened offline and read without a server. It also means every example duplicates its own styling, which is fine for twenty illustrations and would not scale to a hundred. Where a page needs interactivity, the README places those cases in the prototyping and custom editing UI categories, so the scripts live inside the same file as the markup they manipulate.

Opening the examples: no install, one command

The README is explicit that there is nothing to install or build. The instruction is to clone the repository and open index.html, or any individual file, in a web browser. Cloning is the only command involved.

git clone https://github.com/anthropics/html-effectiveness.git
cd html-effectiveness

After that, open the index in a browser. On macOS the shell can do it directly; on other systems open the file through the browser's file menu or pass the path to the browser binary.

open index.html

What you should see is a categorized index linking to the twenty numbered pages. From there, open a file that matches your use case rather than reading them in order. If you are assessing code review output, start with 03-code-review-pr.html; if you are assessing status communication, start with 11-status-report.html. The README notes that all product names, data and scenarios are fictional and that the placeholder brand Acme and any figures shown are not real, so do not read the numbers in the status or incident reports as benchmarks.

The limitation: examples, not components

The repository does not ship reusable pieces. There is no shared stylesheet, no component file, no schema for the data a page expects. If you want the triage board from 18-editor-triage-board.html in your own pipeline, you copy the file and edit it, and you own the result. That is a real cost once you have more than a handful of output types, because improvements to one page do not propagate. The security posture is also out of scope here. The README points to SECURITY.md for reporting a vulnerability, but it does not describe how a rendered page should treat untrusted content, and an HTML output format that embeds model-generated text inherits every injection question that comes with it. Treat the gallery as a source of shapes and arguments, not as a hardened renderer. Finally, the examples are static illustrations. Nothing in the README suggests they are tested against browsers, and no release has been published, so there is no version to pin.

HTML output versus Markdown output

The natural alternative is Markdown, which is what most agent and documentation pipelines emit today. The difference in approach is structural. Markdown is a text format that a renderer later turns into a document; the output carries no layout, so every reader sees whatever their renderer decides. The examples here invert that: the file is the document, with layout, colour and interaction decided at write time. That buys you things Markdown cannot express without extensions, such as a flowchart drawn inline, a component variant grid, or a prompt tuner with controls. It costs you portability and diffability. A Markdown file is readable in a terminal, in a chat window and in a code review; an HTML page is readable in a browser and awkward everywhere else. For a status report that a manager will skim once, the HTML version is the better artefact. For a changelog that lives in git and is reviewed line by line, Markdown wins. The gallery is most useful as evidence in that argument, not as a replacement for the text formats you already emit.

Maintenance, licence and what a fork inherits

The repository is not archived, and the last push was on 2026-07-03. It is MIT licensed, which is permissive and places few obligations on a fork beyond retaining the licence notice; the LICENSE file is at the top level. Because there is no package and no release, upgrade cost is close to zero in the dependency sense and close to manual in the content sense: pulling new commits means re-reading changed files and deciding which of your copies to update by hand. If you fork the gallery as the basis for an internal output format, budget for that divergence. The MIT grant covers the example code, but the fictional product names and the Acme placeholder are illustrative content, and the README treats them as such. Nothing in the repository addresses trademark or attribution beyond the licence itself, so treat those questions as outside what it answers.

Editorial conclusion

Use it if you are evaluating HTML as an output format for an agent and want concrete, openable artefacts to react to, or if you need a starting shape for a review page, status report or triage board. Do not use it as a library, a template engine or a component set; nothing here is packaged for reuse and all data is fictional. Before adopting the pattern in production, open index.html and check which examples match your case, then read CONTRIBUTING.md and SECURITY.md, because the README does not document how examples are validated or how a rendered page handles untrusted data.

Frequently asked questions

Official sources

1. anthropics/html-effectiveness on GitHub
2. Issues
3. License: MIT
4. README