Someone trying PR Tour, the pull request walkthrough tool I'm building, suggested a useful next step: let readers comment on the code, then copy the comments and their source lines into an AI coding tool.
The guide already showed real diffs, explanations, and clickable definitions in one standalone HTML file. But when a reader had a question, they still had to carry it elsewhere and explain which part of the code they meant.
PR Tour 0.6.0 now lets readers select a line or range, write a comment, and copy or download JSON containing the feedback and its source context. The same JSON can be imported back into a matching guide.
Here is the comment editor at a mobile viewport size, using the public Starlette PR #2041 demo. The question is an example comment, not feedback submitted to Starlette.
A line number needs a version
“Check line 211” is incomplete context. It could refer to the old file, the new file, or a newer checkout where line 211 has moved.
The export includes the PR and repository URLs, pinned head/base/merge-base commits, and a record for each comment:
- A stable comment ID.
- The file path, diff side, and commit for that side.
- The inclusive start and end lines.
- The exact selected source text, without diff markers.
- The comment body and timestamps.
For a renamed file, a comment on the old side keeps the old path. Selected source is exported as text; syntax colors and clickable definition markup stay in the UI.
The Copy for AI button copies this JSON. It does not call a model or publish a GitHub review. Whoever uses the export still needs to check the pinned commit against their checkout and evaluate the comment against the code.
Browser storage is convenient; JSON makes it portable
Saved comments stay in browser storage, grouped by PR and source snapshot. Reloading the same guide can restore them, and changing the reading step or UI language does not create a different comment collection.
That storage has limits. Clearing browser data removes it, another device does not have it, and a local-file or embedded viewer may restrict it. The interface shows storage failures and keeps current-session comments available for export.
Download JSON provides a backup that the reader can carry to another browser. The HTML itself is unchanged, so sharing only the HTML does not share the comments.
Import is deliberately strict. It checks the PR, repository, pinned commits, file side, line range, and exact selected source before applying anything. One invalid record rejects the whole file. There is no attempt to guess where an old comment belongs in a newer revision.
Before import, a preview shows additions, duplicates, and conflicting edits. Existing comments win by default; replacing conflicts requires an explicit choice. Re-importing an unchanged comment with the same ID skips it. Different IDs remain separate, and imports do not propagate deletions.
The bug hiding behind a second tab
During pre-release review, we caught a problem in the first storage implementation. Each tab loaded the comment collection once and later saved the whole collection back.
Consider two tabs that both start with no comments:
- Tab A adds a comment and saves
[A]. - Tab B, still holding its original empty collection, adds another and saves
[B]. - A's comment disappears from storage.
No network or database was involved. The stale copy in the second tab was enough.
The fix uses Web Locks, when available, to serialize saves for that snapshot. Inside the lock, a save reads the latest stored collection and merges the current tab's additions, edits, and deletions by ID. Unrelated comments survive.
If another tab has changed the same comment incompatibly, the save preserves the stored version, keeps the current tab's edits in memory, and asks the reader to download JSON before reloading.
Without Web Locks, the fallback refuses a save when it detects that storage changed. That fallback does not guarantee atomic writes from simultaneously saving tabs. Open comment lists also do not live-sync across tabs.
Keeping the code reachable on a phone-sized screen
The other recent feedback was about navigation: moving to the next explanation left too much scrolling to reach the relevant code.
The mobile Code view now has previous/next controls that follow individual code notes across reading steps and scroll to their lines. It stays in the Code tab. An expanded reading view makes more room for the diff, and the comment editor opens as a bottom sheet with larger line-selection targets.
I checked these flows at mobile viewport sizes in Chromium and WebKit, including export/import, offline files, reload persistence, and the two-tab save cases. I have not verified them on physical phones or inside Orca's artifact viewer yet.
The biggest design change was deciding what travels with a comment: enough source context to identify what the reader saw, and a portable copy the reader can keep outside browser storage.
You can try the English demo, browse the source and installation instructions, or read the JSON format and storage behavior. I'm the creator of PR Tour. Existing guides need to be regenerated with the updated skill to get these features.
Written with AI assistance from Codex.
Top comments (0)