code-review-reportlisted

# 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 onl