review-walkthrough

Review Walkthrough

Generate a self-contained HTML walkthrough of the current branch, with the final diff split into logical steps, explanations, and critical review findings. Choose the grouping and reading order for comprehension; commit order need not dictate either. Invoke as /review-walkthrough:review-walkthrough in Claude Code or $review-walkthrough in Codex.

Capture the branch diff

Respect a user-specified base. Otherwise, use the current open PR's base when PR metadata is available. Without a PR, discover the repository's default branch from git symbolic-ref --quiet --short refs/remotes/origin/HEAD or the configured remote's equivalent. Do not assume it is main. If the selected base is missing or ambiguous, ask for it rather than silently choosing another branch.

Resolve the base and HEAD to commit IDs with git rev-parse --verify --end-of-options "${ref}^{commit}", then compute their merge base with git merge-base. Capture the complete patch using git diff --no-ext-diff --no-textconv --no-color --src-prefix=a/ --dst-prefix=b/ "$merge_base" "$head_sha" --. Initialize variables and run the commands that consume them in the same shell invocation; shell variables do not persist between tool calls. Save the patch to a temporary file outside the checkout and retain its actual path. Stop on a Git error or an empty patch and explain the result.

This scope includes committed changes through the captured HEAD. Mention any uncommitted work that is excluded. Do not change branches, reset the checkout, or alter source files to prepare the review. Keep generated data and HTML outside the checkout unless the user requests a particular output location; generated review artifacts never belong in the captured patch.

For a GitHub PR, collect owner, repo, pr_number, and head_sha from its metadata. Include them only when the PR head matches the captured HEAD and the chosen base matches the PR base. Otherwise use null and explain why comment export is unavailable. A failed authentication or network request is not evidence that no PR exists; report the failure and ask for the base if it cannot be determined. GitHub access is optional when the user supplies the base or confirms there is no PR.

Shape the review

Read the changed files and the surrounding source, tests, configuration, and dependency metadata needed to judge them. Keep the review read-only; do not run the project's tests or install its dependencies merely to build the walkthrough.

Group related files into steps covering one concept each. Put definitions before their consumers, wiring after the components it connects, and tests after or beside their subjects. Copy each complete per-file diff from the captured patch verbatim into exactly one step. Reordering files between steps is allowed; splitting, rewriting, omitting, or inventing their patches is not. Preserve rename, binary, and mode-change entries even when they have no text hunks. Binary summaries identify changed files; their payloads are outside this review.

Write one explanation per step, usually 50–150 words, covering the change's purpose, design choices, trade-offs, and connections to other steps. Refer to actual identifiers. Write one review list per step covering bugs, security, validation, API design, or performance issues supported by the code. Report findings with severity rather than suppressing minor issues. Use an empty list for a step with no findings.

Explanations and review bodies are HTML fragments. Use <p>, <strong>, <em>, <code>, <pre>, and <ul>/<li> for structure. Write literal < and > in prose or snippets as < and >. Backticks and Markdown fences are literal text here. Supported inline tags also include <sup>, <sub>, <kbd>, <del>, and <a href="https://…">. The page sanitizes fragments and converts them to Markdown when preparing a PR comment. Only safe link targets survive; arbitrary attributes, scripts, and images do not. Tables export as text rows with cell separators; captions and row order are preserved. Prefer prose, lists, and code blocks when their structure is sufficient.

Anchor findings to a file in the same step and a line in that file's displayed diff. Use side: "RIGHT" for additions or new-file context and side: "LEFT" for deletions or old-file context. For a range, line and end_line use that same side within one hunk. A finding spanning multiple steps belongs with the file it addresses, or remains unanchored. An unanchored finding is still displayed but cannot become an inline PR comment.

Render the artifact

Use a file-writing tool to create a JSON object with the fields below. Preserve the literal patch as JSON string data, with no shell expansion.

An anchored finding also has file, line, and side, plus optional end_line. The three arrays have equal lengths and corresponding entries. File paths match the diff headers without their a/ or b/ prefix; a renamed file uses its new path. Set side explicitly so lines that occur on both sides are unambiguous.

Run the bundled renderer with the actual paths created for this review:

uv run --no-project {baseDir}/scripts/render_walkthrough.py \
  --input /tmp/data.json \
  --diff /tmp/captured.patch \
  --output /tmp/walkthrough.html

The renderer validates the data, compares every step's patches with the complete captured diff, checks anchors, and safely embeds the result in the bundled template. Fix reported input errors rather than bypassing the renderer or generating an alternative page.

Open the output with open on macOS or xdg-open on Linux when a browser is available, and tell the user its path. In a headless run, report the file without opening it. When PR metadata is present, the page lets the user copy a gh api command for their selected comments. It does not execute the command or post anything to GitHub. Comment and Request Changes require a review summary before the command can be copied; the summary is optional for Approve.