diff-tour

diff-tour is a command line tool that turns a git diff into a tour you step through with the → and ← keys. Point it at a branch in any git repository and the AI coding CLI you already use writes a guided walkthrough of the change, covering what the change is for, which files to read next — including files that did not change — what a senior engineer would ask about it, what must be fixed versus what is only a nit, and where an experienced reviewer would stop and say "wait". It is built for engineers who want to keep understanding code as AI writes more of it, and it runs on your own AI coding CLI, read-only and open source. The tool starts from a question its maker kept hearing from people who teach software engineering: now that AI writes the code, what should engineers learn? People rarely write code by hand anymore, AI often reviews it too, and software moves so fast that reading every line is hard. diff-tour's answer is that understanding code matters as much as ever, and that understanding code means learning how a senior engineer thinks. That thinking is what lets an engineer give AI the right instructions, notice what really matters in a problem, design well, and keep a project moving in the right direction. Rather than teaching those habits in the abstract, diff-tour teaches them on real changes in a real repository. The core of the product is the tour itself. Each step is navigated with the → and ← keys, so a reviewer moves through the change one question at a time instead of scrolling through a wall of diff. Every step opens with what the change is for, then points to where to look next — and that includes files that did not change, which, as reviewers on the launch noted, is often where the real risk is hiding. Because the experience is a sequence rather than a summary, you work through the change in the order a careful reviewer would, rather than skimming until something looks off. diff-tour frames each step around the questions a senior engineer asks about a change: What if this runs twice? Can it be rolled back? Would the tests fail if the code broke? Those questions are asked explicitly rather than left implicit, so a reviewer has a checklist grounded in the actual diff. The tour also separates what must be fixed from what is only a nit, and calls out what looks risky but is actually fine, so attention goes to the parts that deserve it. Beyond correctness, the tour asks design questions too: does this belong here, and does it make the next change easier or harder? A distinctive part of the format is that the moments where a senior engineer would stop and say "wait" are asked as questions, so you guess first and then see the answer. Committing to an answer before seeing it is what makes the lesson stick, and it turns the diff from something you passively read into something you actively reason about. The tour also stops at risky schema changes, flagging them as deserving extra care, though the maker notes that it does not yet walk you through what is stored and how it connects — an acknowledged gap that is open for improvement through the project's issue tracker. Several design choices are about trust. diff-tour is read-only: the AI gets a copy of the files git tracks plus read-only tools, and that restriction is enforced by command-line flags rather than only by the prompt. The code on screen is read from git at the right commit and is never copied from the AI's reply, so what you see is the actual change. There is no server and no telemetry, it is MIT licensed, and it saves nothing between runs — which also means it does not track your guesses over time. It runs on your own Claude Code, Codex, Gemini, OpenCode or Copilot plan. Getting started takes one line: install with the one-line script in the README, then run `tour` in any git repository. The first run asks for a language and an AI CLI, with recommended choices already selected — pressing Enter three times starts the tour being written. There is no separate account, dashboard, or approval workflow to learn. The product is explicit that it is not for approving a change; it is for learning how a senior engineer reads one, and because it is open source you can see how those perspectives are written in internal/generate/lessons. The outcome diff-tour aims at is a reader who can look at a change and know where to look, what to ask, and what to ignore. Instead of skimming a large diff produced by an agent and waiting for something to look off, an engineer works through the runs-twice, can-it-roll-back and would-the-tests-fail questions up front. Because the questions come before the code, and because the reader guesses first, the habits of a senior reviewer get practiced rather than merely explained. Over time that is what supports giving AI better instructions, spotting what matters in a problem, and keeping a project pointed in the right direction. Typical use cases follow from that. When an agent hands back a large diff, diff-tour gives you a structured way to read it instead of skimming. When a tour reaches a risky schema change, it stops and asks for extra care, which is useful for the data-model-sensitive reviews reviewers on the launch said they still watch closely. When you are learning, the tour is practice on a real change rather than a toy example, and the design questions it raises — does this belong here, will the next change be easier or harder — give you a vocabulary for architectural discussion. The maker also agrees that reviewing AI-written changes is not only an engineer's job anymore, so the same walkthrough can be used by managers who need to follow what a change actually does. diff-tour is aimed at software engineers, at people who teach software engineering, and at anyone who needs to read AI-written changes rather than only write them. It does not ship its own model: it plugs into the AI coding CLI you already use, including Claude Code, Gemini CLI and OpenAI Codex CLI, and the launch also lists OpenCode and Copilot plans. It is a command line tool distributed under the MIT license, free to use, with installation through a one-line script and no server component. Everything it shows is read from git at the correct commit, and nothing is stored between runs. The takeaway is simple: as writing code gets cheaper, reading it well still matters, and diff-tour teaches that reading on the real changes in front of you. It turns a git diff into a short, navigable tour built around a senior engineer's questions, keeps the experience read-only and local, and asks you to guess the answer before you see it — so the habit of understanding a change is practiced, not just described.