Source profileQuality 89/100

testdouble/han/han-reporting/skills/html-summary/SKILL.md

html-summary

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 n

Source repository stars
181
Declared platforms
0
Static risk flags
2
Last source update
2026-08-06
Source checked
2026-08-06

Decision brief

What it does—and where it fits

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.m…

Best for

  • 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.

Not for

  • Tasks that require unconfirmed production actions or broad system permissions.
  • Environments where the pinned source and install steps cannot be inspected.

Compatibility matrix

Platform support, with evidence labels

PlatformStatusEvidenceWhat to check
CodexNot declaredNo explicit evidencePortability before use
Claude CodeNot declaredNo explicit evidencePortability before use
CursorNot declaredNo explicit evidencePortability before use
Gemini CLINot declaredNo explicit evidencePortability before use
Open the compatibility checker

Installation

Inspect first. Install second.

The source command is displayed only when detected. A safe inspection prompt is always available so your agent can explain every action before execution.

Source-detected install commandSource
npx skills add https://github.com/testdouble/han --skill "han-reporting/skills/html-summary"
Safe inspection promptEditorial

Inspect the Agent Skill "html-summary" from https://github.com/testdouble/han/blob/55e15f752b12f6f90923eb38f7cd25e8e51bf07b/han-reporting/skills/html-summary/SKILL.md at commit 55e15f752b12f6f90923eb38f7cd25e8e51bf07b. List every install step, command, network request, credential, file read/write, external action, and rollback step. Explain whether it fits my task. Do not install or execute anything until I approve.

Workflow

What the source asks the agent to do

  1. 01

    Process

    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.

    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
  2. 02

    Project Context

    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.m…

    personal config directory: !echo "${CLAUDECONFIGDIR:-$HOME/.claude}"project .han/config.md: !cat .han/config.md 2/dev/null || echo ""- personal config directory: !echo "${CLAUDECONFIGDIR:-$HOME/.claude}" - project .han/config.md: !cat .han/config.md 2/dev/null || echo ""
  3. 03

    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…

    Source markdown file — usually a stakeholder-summary.md inside a planning folder. If the user does not name one,HTML sibling file — written next to the source markdown, same basename, .html extension. Example:Single file, no external network resources. No , no pointing at a CDN,
  4. 04

    Inputs

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

    Source markdown file — usually a stakeholder-summary.md inside a planning folder. If the user does not name one,- Source markdown file — usually a stakeholder-summary.md inside a planning folder. If the user does not name one, ask. Do not guess.
  5. 05

    Output

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

    HTML sibling file — written next to the source markdown, same basename, .html extension. Example:- 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 art…

Permission review

Static risk signals and limitations

Reads files

low · line 63

The documentation asks the agent to read local files, directories, or repositories.

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

Writes files

medium · line 90

The documentation asks the agent to create, modify, or delete local files.

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

Reads files

low · line 146

The documentation asks the agent to read local files, directories, or repositories.

Open the file you just wrote and confirm:

Evidence record

Why each signal appears

EvidenceSourceComputedTestedEditorial
SignalValueEvidence typeMeaning
Quality score89/100ComputedDocumentation, specificity, maintenance, and trust rules
Repository stars181SourceRepository attention, not individual Skill quality
Compatibility0 platformsSourceDeclared in the catalog source record
Usage guideautomated source guideEditorialGenerated or reviewed according to the visible evidence level

Pinned source

Provenance and original SKILL.md

Repository
testdouble/han
Skill path
han-reporting/skills/html-summary/SKILL.md
Commit
55e15f752b12f6f90923eb38f7cd25e8e51bf07b
License
MIT
Collected
2026-08-06
Default branch
main
View the original SKILL.md

Project Context

  • personal config directory: !echo "${CLAUDE_CONFIG_DIR:-$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, 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.mdfilters-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:

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 <span class="highlight">; .subtitle set to the literal string Han: Stakeholder Summary. No brand mark.
  2. Bottom line card — purple accent strip; one-sentence lead in larger type; 4–8 outcome bullets in a two-column list.
  3. Stakeholder asks card — orange accent strip; numbered list of decisions the team needs from stakeholders. Each ask has a short title and a one-paragraph question ending with **Confirm ...?**. If the source has no asks section, omit this card entirely — do not invent decisions.
  4. Problem statement section.
  5. What this opens up section — outcome bullets.
  6. User experience walkthrough section — numbered walk list.
  7. Data flow sectiontoday and after cards stacked one per row, each card spanning the page wrap's content width. Do not place data-flow cards side-by-side in a .grid-2 wrapper. Each card contains a <pre class="mermaid"> block with the source's mermaid syntax preserved (branching, decision diamonds, labeled edges). Normalize style directives to the report palette per references/report-style.md.
  8. Intentionally not in scope sectionout-of-scope list.

Readability of the prose. Invoke han-communication:readability-guidance to surface the shared readability standard into your context; the text in these sections follows that standard — do not duplicate its text, apply it. Lead with the main point (bottom line up front, which the executive ordering already enforces), give each heading a descriptive name rather than a generic label, keep one idea per paragraph with the first sentence carrying it, number sequential steps and bullet non-sequential items, and reveal detail in layers. This governs the prose only; the visual layout stays governed by the layout conventions above.

The template includes a mermaid bundle placeholder near the end of <body>:

<script id="mermaid-bundle">
  <!-- MERMAID_BUNDLE_INLINE_HERE -->
</script>
<script>
  mermaid.initialize({ ... });
</script>

Leave the placeholder string <!-- MERMAID_BUNDLE_INLINE_HERE --> exactly as written. The inliner script in Step 6 replaces it with the vendored mermaid.min.js bundle. The mermaid initialization block (with the report palette theme variables) is also part of the template — paste it verbatim.

Section omission rules:

  • Omit any section the source markdown does not address. Do not invent content to fill a section.
  • The bottom line card is the only required section other than the header — if the source has no explicit TL;DR, derive one from the opening paragraph and clearly mark it as such in your work notes.

Markup rules:

  • Use the entity &mdash; not for em-dashes in HTML body content (the template does this consistently).
  • Use the entity &rarr; for arrows in flow diagrams.
  • Apply class names verbatim from the template — tldr, ask-block, ask, walk, flow, node, node.good, node.bad, node.start, out-of-scope, chip, chip.good, chip.bad.
  • Wrap the feature-name portion of the <h1> in <span class="highlight"> for the green background.

5. Verify the HTML

Open the file you just wrote and confirm:

  • The <style> block exists in <head> and contains the :root palette variables from references/report-style.md.
  • There are no <link>, <script src=...>, or external url(...) references in <head> or <body>.
  • The <h1> is the summary subject and the .subtitle reads Han: Stakeholder Summary.
  • Every section that exists in the source markdown has a corresponding section in the HTML.
  • The bottom-line card and asks card (if present) appear before any other content section.
  • No banned superlatives appear in user-visible text (see references/writing-conventions.md).

Then run the standardized readability self-check (the shared standard is in your context from han-communication:readability-guidance) over the report's PROSE content only — never inside HTML tags, attributes, class names, mermaid/diagram bodies, or code. The visual layout stays governed by the existing layout conventions. This skill runs no rewrite pass, so this self-check is the fidelity guard on the prose; criterion 6 is not optional. Confirm each criterion and fix any failure before finalizing:

Run the readability rule's standardized six-point self-check, which is already in your context from the readability-guidance invocation above. Correct every failure before Step 6. Its fidelity criterion is not optional: the standard governs how the content is said, never whether a required fact appears.

The vocabulary blocklist for this skill is the shared one plus its supplementary domain terms in writing-conventions.md.

If any check fails, fix it before Step 6.

6. Inline the mermaid bundle

Make the file self-contained by inlining the vendored mermaid bundle in place of the placeholder:

${CLAUDE_SKILL_DIR}/scripts/inline-mermaid.sh <path-to-html-file>

The script is idempotent: it replaces the <!-- MERMAID_BUNDLE_INLINE_HERE --> placeholder with the contents of assets/mermaid.min.js. If the report has no diagrams (no placeholder), it leaves the file untouched and exits cleanly. If the script exits non-zero, surface the error to the user; do not retry blindly — read the error.

7. Report

Tell the user:

  • The output file path.
  • That the diagrams were inlined (or that the report had no diagrams to inline).

If you had to derive the bottom line because the source had no explicit TL;DR, mention that so the user can review the framing.

Alternatives

Compare before choosing

Computed 9532,785

K-Dense-AI/scientific-agent-skills

simpy

Build, inspect, test, and analyze bounded process-based discrete-event simulations with SimPy, including events, resources, interrupts, monitoring, replications, warm-up, and reproducible output analysis.

Computed 9483

aAAaqwq/AGI-Super-Team

trade-prediction-markets

Build and test Polymarket prediction market trading strategies for YES/NO token trading. Provides 6 tools: get_all_prediction_events (browse markets, $0.001), get_prediction_market_data (analyze price history, $0.001), create_prediction_market_strategy (generate code, $1-$4.50), run_prediction_market_backtest (test performance, $0.001). Trade on real-world events (politics, economics, sports, crypto). Currently simulation only (live deployment coming soon).

Computed 9467

simota/agent-skills

vigil

Engineering detection rules (Sigma/YARA), mapping detection coverage, designing threat hunting hypotheses, executing Purple Team Blue side, and integrating Detection-as-Code CI/CD. Use when defensive security verification is needed.

Computed 9367

simota/agent-skills

matrix

Controlling combinatorial explosion across multi-dimensional axes via universal combinatorial analysis. Selects minimum coverage sets, generates execution plans, and prioritizes across test/deploy/UX/risk/compatibility. No code. Use when scoping multi-axis combinations or selecting minimum-coverage subsets under combinatorial explosion.