git-blame-investigatorlisted

`git blame` tells you *who* last touched a line, which is almost never the question you actually have. The real question — "why is this here, and what breaks if I remove it?" — lives in the commit *message*, the surrounding diff, and the PR that shipped it. This skill does code archaeology: it walks from a suspicious line back to the commit that introduced the *logic* (not the one that reindented it), reads the intent, and returns a verdict on whether the code is a dead artifact or a Chesterton's fence guarding a bug you can't see. ## When to use this skill - A line looks redundant, wrong, or pointless and you're about to delete or "simplify" it. - You're tracing a regression and need the exact commit that changed the behavior. - You're onboarding to unfamiliar code and need to reconstruct *why* it was written this way. - A workaround, magic constant, or odd conditional has no comment explaining it. - blame keeps pointing at a formatting, rename, or merge commit that obviously isn't the real author. ## Instructions 1. **Locate the line precisely, then blame with context.** Run `git blame -L <start>,<end> <path>` on the suspicious range (not the whole file) and note the commit SHA, not the author name. Add `-w` to ignore whitespace-only changes and `-C -C -M` to follow lines that were moved or copied in from other files — without these, blame stops at the refactor that relocated the code and you lose its true origin. 2. **Distrust the first SHA — it's usually noise.** If the