git-analysis

# Read the history, not just the tree Git already knows most of what a reviewer wants to ask. Use it before reading code, and cite commits. ## Techniques - **What changed between X and Y**: `git_diff_range`, then group by module; summarize behavior changes, not file lists. - **Why does this line exist**: `git blame -L` through `run_command`, then `git show` the commit and read its message and the surrounding diff. - **When did it break**: find the last known good and first known bad, then narrow with `git bisect run <test command>` when a test exists; otherwise bisect by hand on the commits touching the area (`git log -- <path>`). - **Who owns this area**: `git shortlog -sn -- <path>` and recent authors. - **What is risky in this release**: largest diffs, files with many recent touches, changes without tests, dependency bumps. - **Branch relationships**: `git log --oneline --graph`, merge bases, commits not yet in main. ## Rules - Quote commit hashes and dates; never paraphrase a commit message as fact without showing it. - Read-only by default. Do not rebase, reset, or rewrite history unless the user asks for that specific operation and confirms. - Large histories: bound queries with paths, `--since`, and `-n`. ## Output A short narrative with the commits that matter, then a table of commit, date, author, summary, and the evidence line for each claim. End with the open questions the history cannot answer.