init-co-jp / diff-tour

# diff-tour
Walk through a diff the way a senior engineer reads it.
**English** | 日本語
 A tour of a branch that adds coupons : what the change is for, how the usage limit is enforced, a question to think about, and the answer: applying a coupon twice to one order uses it up twice. 
> [!NOTE]
> diff-tour is an early release. The tour format and the screens may still change.
## Quick start
You need git and one of Claude Code, Codex CLI, Gemini CLI, OpenCode 2 or Copilot CLI, signed in.
 [code] 
Then it goes like this:
1. **Setup** (first time only): choose the display language and the LLM that writes the tour. Both have a recommended choice selected, so press Enter twice.
2. **Pick a change**: the changes you can tour are listed, with your current branch selected. Press Enter.
3. **Writing**: the LLM writes the tour. This takes 2 to 5 minutes.
4. **The tour**: **→** goes forward, **←** goes back, **q** quits.
If `tour` is not found, add the line the install script printed to your shell profile.
Other ways to install are in Install, and an example repository to try is in First run.
## What it is
AI can write code that works. It does not teach you *why* the code is written that way, or what a reviewer would worry about.
`tour` turns a git change into a guided tour you step through with two keys, **→** and **←**. The tour shows what a senior engineer looks at when they read the change:
- **How they read it.** What the change is for, where to spend time, and which files to jump to next, including files that did not change.
- **What they ask.** Does it keep the promises the old code kept? What happens when something fails, or runs twice? Can it be rolled out and rolled back safely? Who can call it, and with what input? What happens at 100 times the data? Is the next change easier or harder? Would the tests fail if the code broke?
- **How they judge.** Which findings must be fixed and which are only suggestions or nits, what looks risky but is fine and why, what is done well, and whether the change makes the codebase better overall.
- **Where they stop and say "wait".** These come as questions, so you can predict the answer before you see it.
This view comes from what experienced engineers have written down about reading and reviewing code, collected in `internal/generate/lessons` (in Japanese). The LLM reads it before every tour.
The tour is written by an LLM you already use: Claude Code, Codex CLI, Gemini CLI, OpenCode or Copilot CLI. `tour` is read-only. It never changes your files or your repository.
## How it works
 [code] 
1. **Export.** `tour` reads your repository with `git archive`, `git diff` and `git log`, and writes the files into a new directory in your cache. Only files that git tracks are exported. When you tour uncommitted changes, untracked files that are not ignored are exported too. Files in `.gitignore`, such as `.env`, are never exported.
2. **Write.** `tour` starts the LLM's command-line tool in that directory with a fixed prompt and