code-review-report

# Code Review Report Build a single-file HTML report a reviewer reads before digging through the raw diff. A diff shows what changed; it doesn't show why, what was rejected, or what's still missing. Filling that gap with the context accumulated in this conversation is what separates this from a diff viewer. ## 1. Collect the change Check the change with `git status` and `git diff`. Default scope: current branch vs the default branch, plus the uncommitted working tree. - `git diff <base>...HEAD` (committed), `git diff HEAD` (uncommitted) - Untracked files don't appear in diffs — find them with `git status` and read them directly. If the scope is mixed or contains unrelated changes, ask the user. Exclude unrelated changes or mark them separately. ## 2. Collect the working context Gather from this conversation the things a diff never records: - What was changed and why - Design decisions and their reasons, rejected alternatives, tradeoffs - Unfinished work and next steps - Concerns raised and reversals made along the way If the conversation lacks this (e.g., the skill was invoked fresh), reconstruct from `git log`, commit messages, PRs, and related docs. If still empty, ask the user. ## 3. Extract review points Hand the changed code and the working context to subagents, and collect what they flag as P1–P3 findings. Read `references/review-perspectives.md` for the perspective list and the subagent prompt skeleton. The context injection is the point — without it you only get surface-level remarks, not findings like spec mismatches or contradictions between decisions. For large changes, run one subagent per perspective in parallel. ## 4. Write the HTML Start from `assets/template.html`. Follow `references/report-structure.md` for sections and `references/style-guide.md` for visual rules. Two things are non-negotiable: - Syntax highlighting on code blocks (add `language-*` classes) - Bidirectional anchors between change details and the review checklist Write the report in the language the user works in: translate the template's headings and set `<html lang>`. Keep code as-is. Before finalizing, run the self-check at the end of `references/report-structure.md`. ## 5. Finalize 1. Save to the project root as `<task-slug>-review-report.html` (kebab-case task name). 2. Inline the vendored highlight.js — replaces the template's placeholder, keeps the report self-contained and offline-friendly: `python3 <skill-dir>/scripts/inline_hljs.py <report-path>` 3. Open it for the user: `open <report-path>` (macOS), `xdg-open` (Linux), `start` (Windows). ## Principles - State tradeoffs, limitations, and unfinished work plainly. - Every change gets a "why", not just a "what". - Quote code; show before→after where possible. - Hierarchy through typography and spacing, not color.