` tags.
## Content — distill, don't just reformat
- **Header** (top of ``): the report title, one line on what it is, and a generation timestamp. Compute the timestamp in **UTC** at write time — run `date -u +%Y-%m-%dT%H:%M:%SZ` in the shell and embed that exact ISO string in a `data-utc` attribute — then render it in the **viewer's local time**, down to hour:minute:second and with the zone, via a tiny inline script (e.g. `el.textContent = new Date(el.dataset.utc).toLocaleString()`). Never hard-code a local time: the file may be opened on a machine in a different timezone than where it was generated.
- **Table of contents** (directly under the header): a compact TOC listing every section as anchor links. Give each section a stable `id` (``) so the links jump to it. Keep it small and dense — a single row of links or a narrow box, never a full-height sidebar.
- Sections matching the natural structure of the analysis already discussed — one section per investigation area, one table per checklist, one card per open question/decision point. Each section carries the `id` that its TOC entry targets.
- Status/severity color-coding wherever the content has state — this is the main value-add over plain chat text, so don't skip it even under time pressure.
- **Evaluation reports only** — when the source is a *discussion or assessment* (a refactor, a code review, a strategy, or an idea — the Module 5 cases), surface each item's **side effects** and **edge cases** as a first-class element (its own column, chip, or card), never buried in prose, and separate what can be decided autonomously from what needs the user's call. Keep the MVP / main recommendation the headline and let SFX/EC support it — but if one is a blocker (severe enough to change the recommendation), flag it prominently as such, not as a footnote. Do NOT add this scaffolding to reports that aren't evaluations (status, investigation, test plans) — that would be over-fitting.
- Code/log excerpts go in ``/`` blocks with their own scroll container, never inlined into prose paragraphs.
- **Preserve every concrete fact, file path, line reference, and command from the original discussion** — this is an extraction, not a re-summary. Do not drop detail to make it shorter; the whole point of a wide/dense layout is that it can hold more, not less.
- **A final summary is mandatory**: the closing takeaway section is always a short, plain-language bottom line — the decision, the outcome, or the single thing to remember — even when the body is exhaustive. It comes last, or immediately above the glossary appendix when one is present. Give it an `id` and a TOC entry like any other section.
- **Glossary / notes appendix (when needed)**: if the report leans on abbreviations, shortened forms, special jargon that could be misread, or even basic terms used without inline explanation, add a compact term → meaning table as the very last section, after the summary. Include it only when there is genuinely something to clarify — skip it entirely otherwise, and do not repeat terms already explained inline. Give it an `id` and a TOC entry.
## Pairs naturally with `/akithink`
A `/akithink` Phase 5 convergence (decision + rationale + rejected alternatives + assumptions to monitor) is a common source of exactly the kind of dense, multi-part material this skill exists to visualize — the docs file stays the source of truth, `/akihtmlreport` just gives it a scannable view.
## After writing
After writing the file, open it locally: `open REPORT.html` on macOS, falling back to `xdg-open` on Linux. If opening fails (headless environment, no `xdg-open`, etc.), just tell the user the file's path instead of failing the skill. Never publish or host it anywhere — if the user separately asks for a hosted, shareable version, that is a different request (the `Artifact` tool), not part of this skill.