Create an interactive changes report

This skill is a completion gate for repository changes. Before the final response for any task that changed code, tests, configuration, schemas, or infrastructure, produce ONE self-contained HTML file (no CDN, works from disk). A reviewer must understand and assess the changes in ~5 minutes without first reading the source; every key number and claim is one click from evidence.

Save it under reports/ as a descriptive kebab-case *-changes.html. Make that path the primary review handoff; keep the chat summary brief.

This artifact does not replace code-review or an owning workflow's finding authority. If report preparation uncovers a new material defect, stop, return it to the owning workflow for disposition and verification, then regenerate from the resolved state.

Start from assets/report-template.html — visual system, highlighter, popover/jump JS, and one working example of every component. Copy it and replace content; do not restyle from scratch.

A candidate is the creator-QA-complete exact bytes. Any edit creates a new candidate. An owning workflow may require a fresh reviewer to read references/artifact-review.md (reviewer-only honesty/completeness/usefulness/precision contract; read when independently reviewing a candidate). Keep the review outcome outside the HTML.

The altitude rule

• The main page is a 5-minute read: what was built, how it fits, what's risky, what to decide. No exhaustive lists on it.
• Depth lives behind clicks: inventories, per-file breakdowns, and protocol details go in popovers.
• Every stat tile and load-bearing claim is clickable (data-pop or data-goto).
• At most five pre.hl snippets across Critical points plus optional Additional key code. One source of truth per excerpt; never duplicate.