Image: init-co-jp
Why it mattersReviewing a change the model wrote is where mistakes slip past a tired reader, and a tool that walks the reviewer through the risky parts of a diff shortens the time that step takes.
Reviewing a long pull request usually means reading the first file carefully, reading the third file more quickly, and signing off anyway.
diff-tour, released on 10 October 2026 by init-co-jp in Japan, turns a git change into a guided tour a reviewer steps through with the arrow keys. The repository has 120 stars seven days after its first push, is MIT-licensed, and is written in Go. It runs on top of a coding agent the reader already uses: Claude Code, Codex CLI or Gemini CLI, signed in to that account.
What it shows
The tour is a sequence of screens the developer walks through with the right and left arrows. Each screen names one thing a senior reviewer would do with the diff, with code shown as it exists in git at that commit rather than copied by the model. The author groups the questions on the README into four kinds:
- How a reviewer reads it: what the change is for, where to spend time, which files to open next, and which untouched files still matter.
- What a reviewer asks: whether the change keeps the promises the old code kept, what happens on a retry or at a hundred times the data, who can call the new path and with what input.
- How a reviewer judges: what must be fixed, what only looks risky, what is done well, and whether the codebase gets better overall.
- Where a reviewer stops: questions the reader is meant to answer in their head before pressing the right arrow for the model's answer.
The questions themselves are not generated by the model each time. They come from a corpus of code-review notes written in Japanese and shipped inside the repository under internal/generate/lessons. The model reads them before writing the tour.
How it runs
The author describes the pipeline in the README. diff-tour copies the two commits with git archive, writes the diff and git log to a cache directory, and starts the chosen coding agent in that directory under read-only flags. Nothing from the home directory, .git or any ignored file is sent. The model writes the tour as JSON that points at files and line numbers; diff-tour then checks each pointer against the real repository and asks the model to fix the mismatches up to two more times.
Claude Code is called with --tools Read,Grep,Glob, --strict-mcp-config and --permission-mode dontAsk, which the author argues enforces the sandbox at the flag level rather than only in the prompt. Codex is run under a custom permission profile with the network off. Writing a tour takes two to five minutes according to the README.
What a reader does differently
Code review is where mistakes get caught, and it is also where attention runs out before the diff does. Shifting that work into a short, keyed walk through the places a reviewer should actually look is a direct answer to the complaint that an AI-written change can slip past a tired reader. The caveat is in the README too: the lessons that drive the questions are in one person's voice, in Japanese, and still an early release.
Source
init-co-jp/diff-tour, MIT license.
This item was written by an AI system from the linked source. Reveneau is responsible for what it publishes.
Get AI News in your inbox
New developer tools, model and agent releases, and how teams are actually using them to release software. Short, and only when there is something worth reading.