Publish a report as an Artifact

When an analysis produces something colleagues will read — a data audit, an incident timeline, a reconciliation report, a comparison — the deliverable is a link to a readable page, not a wall of terminal markdown. Claude Code's Artifact tool publishes a self-contained HTML file to a private claude.ai URL; the user shares it from the page's share menu.

Proactively offer this whenever the output is a shareable table or report. Don't wait to be asked.

Workflow

1. Build the page as a single HTML file in the session scratchpad directory (never in the user's repo).
2. Publish with the Artifact tool: set a stable emoji favicon, a one-sentence description, and a <title> in the HTML.
3. Reply with the link plus a 3–5 line summary of what's inside. The artifact is private by default — mention that sharing is done from the page itself.
4. Updates: republish the same file path in the same conversation (keeps the URL); from another conversation pass the original URL as url. Keep the favicon stable across updates — people find their tab by its icon.

No Artifact tool in your harness? Write the same HTML file and give the user its path instead.

Page structure (in this order)

1. Header — eyebrow label (AREA · SYSTEM · internal), H1 with the subject and the as-of date, short lede: what the data is, where it came from, what the reader should do with it.
2. Stat tiles — 2–4 headline numbers with one-line explanations. This is what management reads; make the numbers carry the story.
3. Key-insight callout — the one paragraph you'd say out loud in a meeting (root cause, "it is NOT caused by X", decision needed).
4. Detail table(s) — the full data, one row per entity, with status chips for anomalies (mixed values, placeholder image, all empty, …).
5. Footer — data source, scan date/method, caveats, how to reproduce.

Content rules

• Write in the reader's language, for non-developers. Name things by what people recognize (mailing, contact, editor), not by API nouns.
• Aggregates only, never PII. No e-mail addresses, tokens, or per-person rows with identifying data — values + counts, or hashes where correlation is needed. Say so on the page ("Data is aggregated — no personal addresses").
• Use the reader's locale for numbers (thousands separator, % spacing) and tabular-nums wherever digits align.
• Flag anomalies visually (chips), don't bury them in prose.

House style

Start from references/report-template.html (proven skeleton — token-based palette, both themes, sticky table header, chips, stat tiles) and replace the content. The palette is brand-neutral by design — swap --accent (and, if you have them, the semantic tokens) for your brand's values:

Technical constraints that will bite you if ignored:

• CSP blocks all external resources — no webfonts, CDN scripts, or remote images (external <a href> links are fine). System font stack only, or inline a face as a data URI.
• Both themes: define tokens on :root, override in @media (prefers-color-scheme: dark) AND in :root[data-theme="dark"] / :root[data-theme="light"] — the viewer's toggle must win in both directions.
• Wide tables go inside a div with overflow-x: auto; the page body must never scroll horizontally.
• Don't emit <!DOCTYPE>, <html>, <head>, <body> — the publisher wraps the file; start with <title> + <style> + content.