/html-summary

name: html-summary
description: >
  Convert a stakeholder summary markdown file into a single self-contained HTML executive report — bottom line and
  decision asks up front, supporting detail later — styled with a Test Double-derived palette and self-contained mermaid
  diagrams. Use when the user wants to turn a stakeholder summary, executive summary, or business summary into an HTML
  report, generate an HTML version of a summary doc, or produce a shareable HTML file from a summary markdown. Produces
  an HTML sibling file only; does not publish anything.
argument-hint: "[path to stakeholder-summary.md]"
allowed-tools: Read, Write, Bash(bash "${CLAUDE_PLUGIN_ROOT}/scripts/han-config-dir.sh")

Project Context

• personal config directory: !`bash "${CLAUDE_PLUGIN_ROOT}/scripts/han-config-dir.sh" 2>/dev/null || echo "$HOME/.claude"`
• project .han/config.md: !`cat .han/config.md 2>/dev/null || echo ""`

As your first action, use the Read tool on `.han/config.md` inside the `personal config directory` path above. A read that returns no file is no personal configuration: continue silently. When that file or the `project .han/config.md` probe supplies content, apply it per [config-rule.md](../../references/config-rule.md), which governs precedence between the two files, relative-path resolution, and what to do with a file that reads but cannot be used.

HTML Summary

Convert a stakeholder summary markdown file into a single self-contained HTML report tailored for executive readers — bottom line and decision asks up front, supporting detail later — styled with a Test Double-derived palette. The skill produces one HTML file next to the source markdown and stops there.

Inputs

• **Source markdown file** — usually a `stakeholder-summary.md` inside a planning folder. If the user does not name one,

ask. Do not guess.

Output

• **HTML sibling file** — written next to the source markdown, same basename, `.html` extension. Example:

`filters-and-saved-views/stakeholder-summary.md` → `filters-and-saved-views/stakeholder-summary.html`. This is the only artifact the skill produces.

Hard rules

• **Single file, no external network resources.** No `<link rel="stylesheet">`, no `<script src=...>` pointing at a CDN,

no remote font loading, no remote images. Inlined JavaScript libraries (such as mermaid.js) are allowed and expected — they keep the file self-contained.

• **Inline all CSS** in a `<style>` block in `<head>`. The file must render correctly offline.
• **Do not modify the source markdown.** This skill is one-way: markdown in, HTML out.
• **Do not commit, push, or publish.** The skill writes the HTML file to disk and reports its path. Sharing the file is

the user's call, outside this skill.

• **Executive ordering is non-negotiable.** Bottom line (TL;DR) and the stakeholder asks appear before any other

content, in that order. Restructure if the source markdown puts them later. See `references/layout-principles.md`.

• **Use the report palette only.** Colors, typography, spacing, and component patterns come from

`references/report-style.md`. Do not invent new accent colors.

• **Header: subject as the title, fixed subtitle, no brand mark.** The `<h1>` is the summary subject (the feature name).

The `.subtitle` beneath it is the literal string `Han: Stakeholder Summary` on every report. The header carries no logo or brand mark.

• **No superlatives in user-visible text.** Banned word lists and rewrite patterns live in

`references/writing-conventions.md`. Verify before finishing.

• **Apply the shared readability standard to prose.** Source the standard by invoking

`han-communication:readability-guidance` and apply it to the prose content this skill writes or transfers, holding the named audience — the non-technical stakeholder. The report's visual layout stays governed by `references/layout-principles.md` and `references/report-style.md`.

• **Preserve the source's plain-language framing.** Do not rewrite content to be more technical or more abstract. Keep

the source's wording where it works; tighten only when restructuring for the executive layout.

Process

1. Locate the source markdown

If the source path is not in the conversation, ask for it. Resolve to an absolute path and confirm it exists. The output HTML path is the source path with `.md` replaced by `.html`.

2. Read the source end-to-end

Read the entire markdown file. Identify which of these sections (or equivalents) are present, in any order:

• The bottom line / executive summary / TL;DR (sometimes implicit — derive from the opening paragraph)
• The stakeholder asks / open decisions (sometimes titled "What we are asking stakeholders" or similar)
• The problem statement
• What the change opens up / outcomes
• User experience walkthrough
• Today-vs-after data flow comparisons (sometimes with mermaid diagrams)
• What is intentionally not in scope

Section titles in the source may not match these names exactly — map by content, not heading text.

3. Load the references

Read all references before producing HTML:

• [references/report-style.md](./references/report-style.md) — palette, typography, mermaid theming, component patterns,

accessibility notes.

• [references/layout-principles.md](./references/layout-principles.md) — executive ordering, what hoists to the top,

full-width data-flow rule, mermaid diagram preservation rules.

• [references/writing-conventions.md](./references/writing-conventions.md) — banned words (no superlatives), rewrite

patterns, tone signals.

• [references/html-template.html](./references/html-template.html) — the canonical reference HTML. Use its structure,

class names, and CSS verbatim. Adapt content; do not invent new styles.

4. Produce the HTML

Write the HTML file to the output path. Required structure, in order:

1. **Header** — `<h1>` set to the summary subject (the feature name) with the most evocative noun phrase wrapped in `<spa