html-code-review

这段内容是审核时保存的快照。外部来源才是完整且最新的版本。

---
name: html-code-review
description: Generate HTML artifacts for code review, PR explanation, and codebase understanding — rendered diffs with inline annotations, severity-coded findings, refactor risk maps, before/after migration views, and subsystem walkthroughs. Use whenever the user wants to review, explain, or understand a PR, refactor, codebase area, or subsystem — especially before merging, when onboarding others to a change, or when the GitHub diff view doesn't show enough context. Default to attaching an HTML explainer to every non-trivial PR.
metadata:
  version: "1.2.1"
---

# HTML Code Review & Understanding

The default GitHub diff view is fine for tiny PRs and useless for anything that touches multiple files, has subtle ordering, or involves a refactor. HTML lets you render the actual diff with margin annotations, severity tags, flowcharts of what changed, and risk maps showing which areas to look at hardest.

## When to use this skill

- "Review this PR / explain this change / write up this refactor"
- "I just made a change to X — generate an explainer to attach to the PR"
- "Help someone unfamiliar with X understand this code"
- "Walk me through how Y works in this codebase"
- "Map the risk of this refactor"
- Before merging any PR that touches more than one subsystem, has subtle ordering effects, or that a non-author needs to understand

## Output requirements

Render diffs as real HTML so reviewers can copy lines. Use a monospace font for code and a readable serif or sans for prose. Reviewers will open this on a phone during a commute, so the responsive collapse from the foundation block is load-bearing here.

Include a header with: PR title, author, branch, and a one-sentence summary. End with a "what to look at hardest" section that ranks the diff by reviewer attention required.

## HTML output foundation

These defaults apply to **every** artifact this skill produces, on top of the requirements above. If a rule above conflicts with this list, the rule above wins; otherwise these are non-negotiable.

- **Output a real `.html` file the user opens in a browser — never inline-render in chat.** Every artifact this skill produces is a file on disk (`<topic>-<kind>.html`), not an HTML block embedded in the agent's chat surface (claude.ai artifact/canvas widgets, fenced ```html``` blocks, custom rendered iframes, etc.). Inline rendering strips features, themes unpredictably against the surrounding chat (often unreadable in dark mode), and lacks the stable origin and clipboard/network access the submit handler needs. Always write the file. The file itself must be self-contained: no build step, no external runtime, inline CSS and JS. Google Fonts via `<link>` is fine; otherwise nothing loaded from npm or a CDN unless this skill explicitly calls for it.
- **Mobile-responsive.** Collapse cleanly to a single column under ~700px so the artifact opens on a phone — including during incidents, commutes, and link-shares to non-laptop reviewers.
- **No `localStorage` / `sessionStorage` / `IndexedDB`.** Claude.ai artifacts can't use browser storage. State lives in JS memory; the export / copy button is the persistence layer.
- **Real semantic HTML, not screenshots.** Code goes in `<pre><code>` (selectable, copyable). Tabular data goes in `<table>`. Diagrams are inline `<svg>` with real `<g>` and `<path>` elements, not embedded PNGs. The reader should be able to copy any value, line, or label out of the artifact.
- **Build DOM safely; don't sling strings.** Use `textContent` for text and `document.createElement` + `appendChild` for structure. **Never** set `innerHTML` from a string that includes a variable, user input, computed value, or imported data — it's an XSS vector and many agent harnesses (including Claude Code) block it via security hooks. Static literal markup inline in your script is fine.
- **SVG text doesn't wrap — size the shape to the label, or use `<foreignObject>`.** Plain SVG `<text>` overflows silently wh