git-wherelisted

git-blame for WHY, not who — reconstructs the intent behind a line of code from commit/PR/issue/doc history and rules on whether the reason still exists. Use when asking 'why does this exist', 'why is this value 7', 'is this safe to delete/remove', 'can I remove this guard/flag/lock/retry', 'is this still needed', 'who added this and why', 'is this dead code', or before deleting any code you didn't write and don't understand. Also use when a review comment asks to justify an odd-looking line, and during refactors that would remove guards, timeouts, retries, or special cases. Not for 'who last touched this' (plain git blame) or 'what does this code do' (read it). Not for repo-level orientation. Core rule: a WHY is quoted from history or it is 'not recoverable' — never authored from plausibility.
MeeshaBear1/git-where · ★ 0 · Code & Development · score 70

Install: claude install-skill MeeshaBear1/git-where

# git-where — git blame for WHY Recovers the reason a line of code exists, cites it, and rules on whether the reason still holds. Exists because code that should be deleted survives when nobody can prove it's safe to delete, and code that must NOT be deleted dies when its reason was never written down. The failure mode this skill guards against is **fabricated intent**: a plausible-sounding invented WHY is worse than none, because it licenses a deletion (or a keep) the evidence doesn't support. The doctrine: **the model is never the source of a WHY.** The write-side companion to this read-side skill is **git-why** (the `why` CLI: https://github.com/MeeshaBear1/git-why) — record the WHY once and this skill's Step 0b finds it instantly instead of re-digging. ## When NOT to use - "Who last touched this?" → `git blame` directly, no skill needed. - "What does this code do?" → read the code. - "What is this repo / where does truth live?" → repo-level orientation, not this skill. - Code you just wrote this session → you are the provenance; write the comment now. ## A note on output-eliding wrappers If you run git through a pager or a token-reducing proxy that truncates long output, long `git log` / `git show` bodies — exactly the evidence this skill digs for — can get cut, and a subject line alone will misdescribe the birth commit. Disable the pager (`git --no-pager …`) or bypass the wrapper before concluding a message or hunk holds nothing. Likewise, prefer a literal search too