/html-over-markdown

name: html-over-markdown
description: Generate rich, self-contained HTML documents instead of Markdown when output needs visual hierarchy, diagrams, or interactivity. Use for specs, implementation plans, side-by-side design comparisons, PR writeups and code explainers, research and status and incident reports, slide decks, SVG flowcharts, and throwaway editors like triage boards, feature-flag editors, and prompt tuners. Prefer this skill whenever the user asks for a report, plan, or explainer they'll actually want to read — even if they don't explicitly say "HTML".

HTML Over Markdown

Produce a single self-contained `.html` file as the primary output format instead of Markdown.

Why this exists

Markdown flattens spatial information — diffs, dependency graphs, side-by-side comparisons — into linear text. It has no color, no diagrams, no interaction, and people rarely read past ~100 lines. HTML trades a document the user would skim for one they would actually read.

Concrete wins over Markdown:

• **Information density**: tables, SVG, CSS, scripts, images — all in one file
• **Visual clarity**: tabs, collapsible sections, responsive layout, typographic hierarchy
• **Sharing**: one link, any browser, no special viewer
• **Two-way interaction**: sliders, toggles, editors, and a copy-back-to-prompt loop
• **Expressiveness**: no more ASCII diagrams or unicode color approximations

When to use vs. skip

Use this skill when the user asks for:

• A spec, plan, proposal, brainstorm, or multi-option exploration
• A PR writeup, code review, or code/feature explainer
• A report — status, research, incident, weekly
• A side-by-side comparison of designs, approaches, or benchmarks
• A slide deck or visual walkthrough
• A throwaway interactive editor (triage board, feature flags, prompt tuner)
• Anything they'd "actually want to read" — even without the word HTML

Do NOT use this skill when:

• The deliverable is a real `.pdf` / `.docx` / `.pptx` / `.xlsx` file → use those skills
• The user wants a production web app (multi-file React/Vue/Next) → use `frontend-design` or `artifacts-builder`
• The spec is Git-tracked and teammates need clean diffs → keep Markdown
• The user wants a poster or visual artwork → use `canvas-design`
• The answer is a one-paragraph reply → just answer

If unsure, read `references/principles.md` → "What this skill is NOT for".

Workflow

1. **Identify the scenario** from the 5 families in the table below. 2. **Read the matching section in `references/playbook.md`** for patterns and a prompt template. 3. **Pull reusable snippets from `references/snippets.md`** (grids, diffs, SVG, sliders, export buttons). 4. **Start from `assets/base-template.html`** — it has the default style already wired up. Copy it, then fill in. 5. **Write the result to `./outputs/<descriptive-kebab-case>.html`** and declare it in the `<attachments>` block as `<file type="static">outputs/<name>.html</file>`. 6. **Only if the HTML needs a real server** (e.g., `fetch`, complex event handlers that fail on `file://`), run `python -m http.server 8080 --directory outputs` and `/app/export-port.sh 8080`. For plain static pages, skip this.

The 5 scenarios

| # | Scenario | Typical trigger | Signature patterns | |---|---|---|---| | 1 | **Spec, Planning & Exploration** | "Help me plan…", "explore approaches…", "compare options" | Side-by-side grid, labeled tradeoffs, mockups, data-flow SVG | | 2 | **Code Review & PR** | "Explain this PR", "review this code", "help onboard a reviewer" | Annotated diff with margin notes, severity chips, module graph | | 3 | **Design & Prototype** | "Design system", "component variants", "prototype an animation" | Variant matrix, color swatches, tunable sliders + Copy-as-CSS | | 4 | **Report, Research & Explainer** | "Status report", "explain how X works", "incident writeup" | TL;DR, collapsible sections, tabbed samples, SVG diagrams, timeline | | 5 | **Custom Editor** | "Let me reorder…", "tune this config", "edit this prompt with live preview" | Drag-drop or forms, live preview, **required**: Copy-as-{JSON,Prompt,Markdown} button |

Open `references/playbook.md` and jump to the matching scenario for full patterns, structural templates, and prompt seeds.

The 5 principles (keep these in mind throughout)

1. **Self-contained**: one `.html`, all CSS/JS/SVG inline. CDN links are OK; build steps are not. 2. **SVG, never ASCII**: any diagram — flow, sequence, architecture, dependency — must be SVG. 3. **Spatial, not linear**: if you'd use a bullet list for it in Markdown, think again. Options go in a grid, diffs go inline with margins, dependencies go in a graph. 4. **Export-to-prompt**: any interactive control must have a button that writes something to the clipboard (JSON, Markdown, or a natural-language prompt) so the loop closes back into Claude Code. 5. **Readable at a glance**: responsive, quiet palette, obvious hierarchy. Optimize for "opens file → understands in 10 seconds".

Full rationale, reasoning, and the default style blueprint are in `references/principles.md`.

Default style and output conventions

The default aesthetic is **Anthropic warm-editorial** — ivory `#FAF9F5` background, clay `#D97757` as the single accent, serif headings with mono uppercase eyebrows, 1.5px warm-gray borders. Full tokens, typography, and signature patterns live in **`references/design-language.md`** — read it before producing output.

The starter template in `assets/base-template.html` has the full palette wired up (`--ivory`, `--clay`, `--oat`, `--olive`, `--rust`, warm grays `--g100…--g700`, serif/sans/mono stacks, h1 with `<em>` in clay, callouts with clay stripe, mono chips).

Prefer adapting this template over writing new CSS from scratch. If the user references a design system of their own, mirror its tokens. If they ask explicitly for Anthropic brand styling, optionally combine with `brand-guidelines`.

File naming: `./outputs/<descriptive-kebab-case>.html`. Pick