commit-archaeologist

name commit-archaeologist description Reconstructs why code exists from local git history, including the introducing commit, later changes, current authors, repeated companion files, and likely intent. Use when the user asks "why does this code exist", "who wrote this function and why", or to "explain the history of this function" before a rewrite, refactor, or risky edit. Runs entirely locally. license Apache-2.0 metadata {"author":"Matt Van Horn","version":"1.0.0","source":"https://github.com/Shubhamsaboo/awesome-llm-apps"} Commit Archaeologist git blame names the last person to touch a line. This skill reconstructs the reason the line exists. It traces a file or current line range through local git history, identifies its origin and later edits, finds files that repeatedly changed beside it, and extracts intent clues from commit messages. Everything runs locally. No network calls, API keys, or repository writes. When to use The user asks why a block, function, or file exists The user wants to know who introduced code and what changed afterward A rewrite or refactor needs historical constraints and change risks A workaround, temporary branch, or surprising design choice needs context When not to use The user only wants raw blame output or a commit list The task is to squash, delete, or rewrite git history The repository is remote and has not been cloned locally The question is about project-wide architecture rather than one file or region Gather the target Get the repository path and tracked file path. Use a line range when the user names a current block or function. If either path is missing, ask only for the missing value. Do not scan sibling repositories. Paths should be relative to the repository and use forward slashes. Line ranges use inclusive current line numbers such as 40-72 . Run the dig From this skill directory: python3 scripts/archaeologist.py /path/to/repo src/cache.py --lines 40-72 --json For the complete history of a file, omit --lines : python3 scripts/archaeologist.py /path/to/repo src/cache.py --json The script is read-only. With a range it uses git line-log; without one it uses file history with rename following. It also reads current authorship with blame. If it rejects a path or range, report that error and ask for a corrected target. Before interpreting the JSON, read references/reading-git-history.md . Its confidence rules prevent blame ownership, correlation, and commit-message hints from becoming false certainty. Read the JSON region : normalized repository, current and historical paths, mode, range, and co-change threshold introduced_by : oldest commit in the selected history timeline : commits ordered oldest to newest, with category, changed files, and detected renames co_changed : files present beside the target in enough selected commits authors : current blamed lines and historical commit counts, kept separate intent_signals : issue references, reverts, workarounds, temporary markers, and unfinished-work markers found in commit messages An empty signal list means the messages do not say why. It does not mean the change had no reason. Write the report Turn the JSON into a short "why this code exists" report: Bottom line. One or two sentences with the most likely explanation and a confidence label: high, medium, or low. Origin. Introducing hash, date, author, subject, and the neighboring files that make the initial purpose clearer. Timeline. Oldest to newest. Group mechanical edits when they do not change the story, but preserve reverts, fixes, and workarounds. Companion files. Explain repeated co-changes as a coupling clue. Do not treat a one-off file in changed_files as a dependency. Intent evidence. Quote short commit subjects or signal words. Label any conclusion beyond those facts as an inference. Change risk. Name the constraints, companion files, and unresolved temporary choices worth checking before an edit. Keep hashes short in prose, but preserve enough characters to identify them. Do not dump the full JSON unless the user asks. Evidence rules Current blame ownership is not proof of original authorship. The oldest selected commit is the region's introduction, not always the file's first commit. Repeated co-change suggests coupling; it does not prove a dependency. Commit categories are message heuristics, not verified issue types. "Temporary" and "workaround" are strong intent clues, but only the message author or linked discussion can confirm whether the constraint still applies. If the history is thin or messages are vague, say "the history shows" and "likely" instead of inventing a design rationale. Follow-ups End by offering one relevant follow-up, such as: "Want me to assess whether this looks deliberate or accidental?" "Want me to map what could break if this region changes?" For a deliberate-choice question, weigh repeated edits, issue references, reverts, and explicit constraint words. For a change-risk question, inspect the repeated co-change files and the last behavior-changing commits before proposing edits. Do not modify code until the user asks. Files scripts/archaeologist.py : offline git history walker and JSON report builder references/reading-git-history.md : interpretation and confidence guide