akihtmlreport

akihtmlreport — single-file visual report extraction

Invoke with /akihtmlreport, or when the user asks in their own words to extract the discussion into a visual file ("trích xuất ra html", "xuất báo cáo trực quan", "làm file report", "export this to html"). Its purpose is single and narrow: turn a complex analysis or report that already exists in this conversation into one self-contained HTML file for dense, at-a-glance reading — nothing else, no new analysis. Not a replacement for chat responses, and not something to reach for by default.

When this skill actually applies

This is for content that has already gotten too dense to stay legible as chat text: a multi-part investigation report, a root-cause writeup with several code/log excerpts, a checklist spanning many items each with its own status, a comparison across several options, a Mac/manual test plan with many steps and expected results. The content must already exist in the conversation — this skill distills and formats, it does not originate new analysis.

Do not use this skill for:

• a short answer, a single fix explanation, or anything that already reads fine as chat text
• routine status updates or one-off command output
• anything the user hasn't actually asked to have extracted — only trigger on an explicit request, never proactively just because a response got long

If invoked on content that turns out not to be dense/complex enough to justify a visual file, say so and ask whether the user still wants one, instead of silently producing a thin HTML wrapper around a two-line answer.

Target file — default path and the single-file rule

• Default output: project root, filename REPORT.html (uppercase, no variant names, no topic/version suffix).
• Exactly one REPORT.html exists per project at a time. This is deliberate: the point is to keep attention on ONE complex task at a time, not to accumulate a pile of past reports. Never create REPORT-2.html, REPORT-v2.html, REPORT-<topic>.html, and never move a prior one aside automatically to make room for a new one.
• Before writing, handle any existing REPORT.html cheaply — never Read it. A finished REPORT.html is large, dense HTML; reading it back burns tokens for nothing, since this skill always regenerates the file wholesale and never edits it in place. Inspect only its metadata with a shell one-liner (ls -la REPORT.html, or find REPORT.html -mmin +720 — 720 min = 12 h):
  • Does not exist → write directly.
  • Exists but stale (last modified more than ~12 h ago) → a leftover from an unrelated past task. Delete it (rm REPORT.html) and write fresh — no read, no prompt. Deleting first also clears the read-before-write step, since the file no longer pre-exists. State in one line which stale file you removed.
  • Exists and recent (≤ ~12 h) → probably tied to the current or a closely related task. Still do not read it; stop and ask the user (overwrite, or skip). On overwrite, rm it first, then write. Never auto-rename to dodge the collision — that defeats the single-file rule.
• If the user explicitly names a different path or filename in their request, honor that instead — the default only applies when they haven't specified one.
• Git-ignore it. REPORT.html is a disposable visual export, not a doc source of truth (that's docs/arch/docs/plan) — it gets fully overwritten every time this skill runs, so tracking it in git only produces noise diffs unrelated to real code changes. If the target project is a git repo and its .gitignore doesn't already exclude REPORT.html, add an entry for it (with a one-line comment explaining why) the first time this skill writes the file there.