html-summary

Name: html-summary
Author: testdouble

122stars12forks

How to install html-summary?

testdouble/han/html-summary

$npx -y skills add testdouble/han --skill html-summary

Installs into the current project.

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 stak

Files · 1

View on GitHub

SKILL.md

1	# HTML Summary
2
3	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.
4
5	## Inputs
6
7	- Source markdown file — usually a `stakeholder-summary.md` inside a planning folder. If the user does not name one, ask. Do not guess.
8
9	## Output
10
11	- 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.
12
13	## Hard rules
14
15	- 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.
16	- Inline all CSS in a `<style>` block in `<head>`. The file must render correctly offline.
17	- Do not modify the source markdown. This skill is one-way: markdown in, HTML out.
18	- 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.
19	- 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`.
20	- Use the report palette only. Colors, typography, spacing, and component patterns come from `references/report-style.md`. Do not invent new accent colors.
21	- 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.
22	- No superlatives in user-visible text. Banned word lists and rewrite patterns live in `references/writing-conventions.md`. Verify before finishing.
23	- Apply the shared readability standard to prose. Load and apply `../../references/readability-rule.md` 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`.
24	- 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.
25
26	## Process
27
28	### 1. Locate the source markdown
29
30	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`.
31
32	### 2. Read the source end-to-end
33
34	Read the entire markdown file. Identify which of these sections (or equivalents) are present, in any order:
35
36	- The bottom line / executive summary / TL;DR (sometimes implicit — derive from the opening paragraph)
37	- The stakeholder asks / open decisions (sometimes titled "What we are asking stakeholders" or similar)
38	- The problem statement
39	- What the change opens up / outcomes
40	- User experience walkthrough
41	- Today-vs-after data flow comparisons (sometimes with mermaid diagrams)
42	- What is intentionally not in scope
43
44	Section titles in the source may not match these names exactly — map by content, not heading text.
45
46	### 3. Load the references
47
48	Read all references before producing HTML:
49
50	- [references/report-style.md](./references/report-style.md) — palette, typography, mermaid theming, component patterns, accessibility notes.
51	- [references/layout-principles.md](./references/layout-principles.md) — executive ordering, what hoists to the top, full-width data-flow rule, mermaid diagram preservation rules.
52	- [references/writing-conventions.md](./references/writing-conventions.md) — banned words (no superlatives), rewrite patterns, tone signals.
53	- [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.
54
55	### 4. Produce the HT

People who liked this also viewed

6 picks

Type

html-summary

122stars12forks

View on GitHub

How to install html-summary?

testdouble/han/html-summary

$npx -y skills add testdouble/han --skill html-summary

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# HTML Summary
2
3	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.
4
5	## Inputs
6
7	- Source markdown file — usually a `stakeholder-summary.md` inside a planning folder. If the user does not name one, ask. Do not guess.
8
9	## Output
10
11	- 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.
12
13	## Hard rules
14
15	- 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.
16	- Inline all CSS in a `<style>` block in `<head>`. The file must render correctly offline.
17	- Do not modify the source markdown. This skill is one-way: markdown in, HTML out.
18	- 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.
19	- 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`.
20	- Use the report palette only. Colors, typography, spacing, and component patterns come from `references/report-style.md`. Do not invent new accent colors.
21	- 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.
22	- No superlatives in user-visible text. Banned word lists and rewrite patterns live in `references/writing-conventions.md`. Verify before finishing.
23	- Apply the shared readability standard to prose. Load and apply `../../references/readability-rule.md` 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`.
24	- 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.
25
26	## Process
27
28	### 1. Locate the source markdown
29
30	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`.
31
32	### 2. Read the source end-to-end
33
34	Read the entire markdown file. Identify which of these sections (or equivalents) are present, in any order:
35
36	- The bottom line / executive summary / TL;DR (sometimes implicit — derive from the opening paragraph)
37	- The stakeholder asks / open decisions (sometimes titled "What we are asking stakeholders" or similar)
38	- The problem statement
39	- What the change opens up / outcomes
40	- User experience walkthrough
41	- Today-vs-after data flow comparisons (sometimes with mermaid diagrams)
42	- What is intentionally not in scope
43
44	Section titles in the source may not match these names exactly — map by content, not heading text.
45
46	### 3. Load the references
47
48	Read all references before producing HTML:
49
50	- [references/report-style.md](./references/report-style.md) — palette, typography, mermaid theming, component patterns, accessibility notes.
51	- [references/layout-principles.md](./references/layout-principles.md) — executive ordering, what hoists to the top, full-width data-flow rule, mermaid diagram preservation rules.
52	- [references/writing-conventions.md](./references/writing-conventions.md) — banned words (no superlatives), rewrite patterns, tone signals.
53	- [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.
54
55	### 4. Produce the HT

People who liked this also viewed

6 picks

Type