That's commit review not semantic diff, and "why" some changes happened should be in the commit body (some will argue should be in code comments too) rather try

That's commit review not semantic diff, and "why" some changes happened should be in the commit body (some will argue should be in code comments too) rather try figure it out after the fact, which won't even work. E.g. https://github.com/tkenaz/semantic_diff/blob/main/semantic_diff_reports/cdf9fa8a_20260121_093440.md https://github.com/tkenaz/semantic_diff/blob/main/semantic_d... The Intent in this report just paraphrases the well-written commit message. But what about things not written? Funnily the tool catches up the drifts: 2. Why was 196 lines of CLAUDE_NOTES.md removed? Was this intentional cleanup or accidental deletion of important project context? The diff shows massive content reduction in project documentation with no explanation in the commit message. This could represent loss of architectural decisions, bug tracking, or development history. So... why? No answer is given because not possible. 6. Why skip dependabot PRs specifically? Shouldn't dependabot updates also be semantically analyzed to catch breaking changes in dependencies? Dependabot PRs could introduce security vulnerabilities or breaking API changes that semantic analysis would catch. Skipping them entirely might miss important issues. Good question. But, again, no answer. Also maybe have an option on analysis extend, sections to see, and perhaps prompt to lessen the redundant information. E.g. in previous report, the "CLAUDE_NOTES.md massive content reduction" appears in Impact Map, Risk Assessment, Review Questions. Plus the entire sentence "Massive reduction in file size (212 lines removed, 16 added) suggests project documentation/status was significantly refactored or cleaned up" simply states what is obvious from the deleted lines in Files Changed. Some may like this, other (incl. me) won't. Personally will've preferred overall report be shorter. The indirect impacts section seems interesting. There're cases that one may want to see modules impacted by a change, e.g. a function changing the result, making another function fail. But this is probably doable heuristically rather requiring an LLM to read the codebase.