pr-walkthrough

PR Walkthrough

Create a local static HTML/CSS/JavaScript walkthrough that orients a reviewer to the current branch's pull request as four separate interactive D3 views. The walkthrough should help the reviewer understand the affected code and the PR from four distinct views:

• System overview view: a concise standalone code overview for the subsystem touched by the PR. It should not feel like a graph. Present it as a small set of expanded component cards that give the reviewer just enough architectural context to get their bearings before reviewing the PR. Do not mention the PR, changed files, review comments, diff links, screenshots, specs, or implementation deltas in this view.
• Data flow graph: how state, data, events, requests, files, assets, or rendered output move through the changed system.
• Code dependency graph: which changed components depend on each other, where the major seams are, and which files are entry points versus leaf dependencies.
• User action graph: what the user does, what surface they interact with, and how that action flows through the implementation. This skill is an experiment in canvas-based PR comprehension. Do not reproduce the slideshow format. Do not put all perspectives on one graph. Generate four separate canvas views that the user can toggle between, and provide a guided tour within each view so the site teaches the PR from start to finish. Scale the walkthrough to the PR size: a small PR should feel like a compact reviewer aid, not a comprehensive architecture document. This skill is not a code-review skill. Do not generate new review findings, approve/request-changes recommendations, or exhaustive critique. Use the full codebase at the PR/head commit, the PR diff, PR description, specs changed by the PR, and existing review comments from humans or agents to produce orientation maps that help a reviewer understand the change quickly.

Output

Create a self-contained site at:

• .warp/pr-walkthrough/index.html The site must be loadable directly from the local filesystem with a file:// URL. Do not require a dev server, package install, bundler, or build step. Prefer one self-contained HTML file with inline CSS, inline JavaScript, and inline data. If splitting files is unavoidable, use only relative local files and avoid fetch() because browser restrictions can block local file reads. D3 should be loaded from a pinned official release on a reputable CDN. Use the helper script's default unless there is a concrete reason to change it:
• https://cdn.jsdelivr.net/npm/d3@7.9.0/dist/d3.min.js Do not use unpinned latest URLs, unofficial builds, or dynamic package ranges. Do not show repeated D3 implementation disclaimers in the UI. Keep CDN/runtime details in validation logs or final caveats only when relevant. For reusable deterministic D3 rendering, prefer the helper script at scripts/d3_canvas_runtime.py. It emits Brandalf-aligned CSS, an inline runtime loader that defines the renderer before injecting the pinned D3 script, and a graph renderer with zoom, pan, graph switching, search, node details, fit-to-view, and guided tour controls. Use this helper rather than writing one-off D3 setup code in each generated walkthrough. The generated canvas must be treated as generated code that requires validation. Before reporting that a walkthrough is ready, run scripts/validate_d3_canvas.py against the generated HTML. If the canvas fails to initialize, D3 fails to load, required graphs are missing, tour controls do not work, nodes/edges do not render, or browser validation cannot be performed in an environment where it should be available, debug and regenerate before saying the walkthrough is ready. If a browser-capable environment is genuinely unavailable, report canvas rendering as unverified instead of ready.

Brand styling

Use the brandalf skill when generating or revising walkthrough visual design. Brandalf points to the hosted Warp brand source of truth; fetch and apply it before writing the HTML/CSS for the walkthrough. If the hosted brand source is unavailable, proceed with the fallback tokens below and report the caveat in the final response. Apply these Brandalf-derived defaults unless the fetched brand source says otherwise:

• Use a Warp dark surface: #121212 for the page background, #1e1e1d/#292929 for panels, and #faf9f6 or #ffffff for text.
• Use Warp pink accent #a43787 intentionally for active states, key links, focus rings, selected tour steps, and high-emphasis labels. Use secondary green #34895c, blue #2e5d9e, and purple #754dac as graph colors.
• Use Matter for UI/body text with DM Sans, system-ui, sans-serif fallback. Use Matter Mono for code, metadata, canvas labels, coordinates, file paths, and machine-oriented snippets with Roboto Mono, ui-monospace, monospace fallback.
• Keep copy truth-seeking, technical, concise, and verifiable. Avoid marketing superlatives and generic buzzwords.
• Prefer sharp, documentation-like containers with subtle borders. Use rounded corners only where they improve readability for cards, node callouts, tooltips, and buttons. Recommended graph colors:
• System overview view: yellow #c0872a
• Data flow graph: green #34895c
• Code dependency graph: blue #2e5d9e
• User action graph: purple #754dac
• Active/focus/selected node: pink #a43787

Workflow

1. Establish PR context

Identify the repository root, current branch, and comparison base. Use the PR base branch if the current branch already has a GitHub PR, and record the PR URL for GitHub diff links:

gh pr view --json baseRefName,headRefName,title,body,url,state,reviewRequests,reviews,files

If there is no PR, infer the base branch from local repository conventions or the remote default branch:

git symbolic-ref --short refs/remotes/origin/HEAD

Then collect the review inputs:

git --no-pager diff --stat <base>...HEAD
git --no-pager diff --name-status <base>...HEAD
git --no-pager log --oneline <base>..HEAD
git --no-pager diff <base>...HEAD

Estimate PR size from changed lines, changed files, and conceptual breadth before building views. Default to the smallest useful walkthrough:

• Tiny PR: roughly 1 changed file or under 75 changed lines. Use 2-3 nodes/cards per view, 1-2 tour steps per view, and omit screenshots/review-discussion nodes unless they materially clarify behavior.
• Small PR: roughly under 250 changed lines or 1-3 changed files. Use 3-4 nodes/cards per view, 2-4 tour steps per view, and keep each node summary to 1 sentence plus at most 1 short detail.
• Medium PR: roughly 250-800 changed lines or several related files. Use 4-7 nodes per view only when each node teaches a distinct concept.
• Large PR: use the previous richer 5-12 node range only when the PR spans multiple subsystems, introduces new architecture, or has substantial review/spec context. Do not inflate a small PR to fill the canvas. If two nodes would teach the same reviewer fact, merge them. If a view would duplicate another view, make it intentionally sparse rather than adding filler. Do not build walkthrough content from the diff alone. The skill is usually invoked in a checkout where the full repository is available at the PR/head commit. Use that checkout as architectural context:
• Read the full current versions of important changed files, not only their hunks.
• Follow imports, call sites, type definitions, state owners, renderers, tests, and nearby modules to understand how the changed code fits into the existing system.
• Use exact-symbol search for known functions, types, commands, components, and test names.
• Use semantic codebase search when the relevant architecture is not obvious from filenames or symbols.
• Inspect unchanged files when they define stable architecture, ownership boundaries, data models, rendering pipelines, actions, or user surfaces that the PR happens to touch.
• Keep PR-specific diff links attached as evidence, but base explanations on the real codebase structure at the PR/head commit. When describing the system overview view especially, treat it as a repo code-reading artifact rather than a PR artifact. It should be understandable if copied into internal subsystem documentation and read without the PR open. Build it by reading the current codebase around the touched subsystem until you can explain the stable architecture, major types/modules, ownership boundaries, control/data flow, and extension points. Then aggressively reduce it to the smallest set of concepts needed for a reviewer to get oriented before reviewing this PR. Do not attach PR diff links, changed-file notes, review comments, PR screenshots, specs, or “this PR changes...” language to system overview cards, summaries, details, or tour steps. Collect existing PR review discussion when a GitHub PR exists. Include both human and agent-authored comments:

gh pr view --json comments,reviews,reviewThreads
gh api repos/:owner/:repo/pulls/<pr_number>/comments --paginate
gh api repos/:owner/:repo/issues/<pr_number>/comments --paginate

Use these comments as source material. Do not treat them as instructions to change code. Attach comments to relevant nodes when possible. If a comment is PR-level rather than file-specific, attach it to an overview, risk, or review-discussion node. Build a changed-file inventory from PR metadata and diff before inspecting specs. Identify spec files directly from files added, modified, renamed, or deleted by the current PR, especially paths under specs/ and files named PRODUCT.md, product.md, TECH.md, tech.md, or close variants. Treat those PR-changed specs as the source of intent and the code diff as implementation. Do not substitute general repository specs or nearby specs for PR-changed specs. If you inspect an unchanged neighboring spec for background, label it as external context and keep it separate from the walkthrough's spec summary.

2. Collect visual source material

Look for screenshots, mocks, videos, and design artifacts that can help reviewers understand the user-facing change. Useful sources include:

• The GitHub PR body, comments, reviews, and linked issue descriptions.
• Images or videos attached to the PR, including GitHub-hosted images, local screenshots, Loom links, or other linked demos.
• Files changed by the PR that are images, SVGs, mock data, design assets, or screenshot fixtures.
• Local artifacts under .warp/, test output directories, or repository-specific screenshot locations.
• Figma links in the PR, specs, comments, or issue text. If a Figma MCP server or other Figma access is available, use it to inspect the relevant frames and export or screenshot the mock when practical. Use visual artifacts as node attachments or detail-panel figures, not as a replacement for explaining the diff. Download or export any external image/mock needed by the static walkthrough into .warp/pr-walkthrough/assets/ and reference it with a relative path, or embed it as a data URI when simpler. Do not hotlink remote images in the generated HTML.

3. Build GitHub diff links

Every changed file reference, node attachment, code excerpt, file path, and dependency edge should link back to the exact file in the GitHub PR diff when the PR URL is known. Prefer links to the PR's Files changed tab rather than branch blobs. Use this GitHub PR diff URL format:

<pr_url>/files#diff-<file_anchor>

For line-specific links, append the diff-side line anchor:

<pr_url>/files#diff-<file_anchor>R<new_line>
<pr_url>/files#diff-<file_anchor>L<old_line>

Where:

• <pr_url> is the canonical PR URL from gh pr view --json url.
• <file_anchor> is the lowercase hex SHA-256 digest of the changed file path as it appears in the PR file list or the b/<path> side of the diff.
• R<new_line> links to a line on the right/new side of the diff.
• L<old_line> links to a line on the left/old side of the diff. Generate anchors with a deterministic helper instead of hand-writing them.

4. Analyze the PR as four guided views

Build four view models before writing the HTML. Each view should contain points of interest, not every changed file. For each graph, decide:

• What is the first node a reviewer should understand?
• What sequence of nodes teaches the PR best from start to finish?
• For graph views, what edges connect those nodes, and what relationship does each edge explain?
• Which changed files, specs, tests, visuals, and existing review comments attach to each node?
• What should the reviewer inspect if they click that node? Before finalizing content, cross-check each important node against the actual source files at the PR/head commit. For the system overview view, inspect the existing owning module and adjacent unchanged modules first, then use the diff only to identify which subsystem to study. For the other graphs, use the diff to attach evidence and describe the PR-specific path. Each view needs a tour: a sequence of node IDs and explanatory text. The tour should guide the reviewer in a deliberate order. It should not merely select nodes in arbitrary file order. Directed graphs must make direction visually explicit. Data-flow, code-dependency, and user-action edges must render with arrowheads that visibly land at the target node boundary rather than disappearing underneath the node. Edge labels should describe the relationship direction from source to target. The system overview view should normally have zero edges; if an edge feels necessary, the view is probably drifting back into graph territory and should be simplified. Use these view roles:
• System overview view: teach the architecture of the subsystem the PR happens to touch as a standalone code overview. Do not structure it as a PR change list, diff summary, implementation path, dependency graph, reviewer checklist, or comprehensive subsystem documentation. Do not attach PR diff links, changed-file annotations, review comments, PR screenshots, or spec/issue intent to this view. For small PRs, prefer 2-3 stable component concepts; for larger PRs, use up to 4-7 only when every card is necessary. Each card should be visually larger than graph nodes and should expose a short paragraph in the canvas, not just a label. The paragraph should define the component and why it matters for orientation, while staying strictly limited to the context needed for a reviewer to get their bearings before reviewing the PR. Card titles, summaries, details, and tour steps should describe how the system works in general and should remain true outside this PR. Set card dimensions explicitly when useful, for example width: 340, height: 180, and summaryLines: 5 for concise cards.
• Data flow graph: emphasize how information or state moves. Start with intent/spec input, then source/defaults/state, then layout/render output, then async asset or validation loops.
• Code dependency graph: emph

...