Skill81 estrellas del repoactualizado today

html-summary

Instalar en Claude Code

Copiar

git clone --depth 1 https://github.com/testdouble/han /tmp/html-summary && cp -r /tmp/html-summary/han.reporting/skills/html-summary ~/.claude/skills/html-summary

Después abre una sesión nueva de Claude Code; el skill carga automáticamente.

Definición

SKILL.md

# 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.
- **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 `<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 section** — `today` 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 section** — `out-of-scope` list.

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

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

Leave the placeholder string `` 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

Del mismo repositorio

han-releaseSkill

han-update-documentationSkill

markdown-to-confluenceSkill

plan-a-feature-to-confluenceSkill

project-documentation-to-confluenceSkill

work-items-to-jiraSkill

architectural-analysisSkill

Performs deep architectural analysis of a specified module, directory, or feature area by examining structural coupling, data flow, concurrency patterns, risk, and SOLID alignment. Use when the user wants to assess, evaluate, or review the architecture, design quality, dependency structure, coupling, cohesion, or technical debt of an existing part of the codebase. Not for investigating specific bugs, runtime errors, or failures — use investigate. Not for test planning — use test-planning. Not for file-level code review — use code-review. Not for researching open-ended options, prior art, or how something works — use research. Not for writing documentation or architectural decision records.

code-reviewSkill

Run a comprehensive code review on local source files. Use this skill when the user asks to review, audit, inspect, evaluate, or check code, even if they never use the word \"review.\" Does not post comments to GitHub pull requests — use post-code-review-to-pr for that. Does not analyze architectural structure or module boundaries — use architectural-analysis for that. Does not capture feedback on Han's own skills — use han-feedback for that.