Commit Archaeologist

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:

bashCopy code
python3 scripts/archaeologist.py /path/to/repo src/cache.py --lines 40-72 --json

For the complete history of a file, omit --lines:

bashCopy code
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:

1. Bottom line. One or two sentences with the most likely explanation and a confidence label: high, medium, or low.
2. Origin. Introducing hash, date, author, subject, and the neighboring files that make the initial purpose clearer.
3. Timeline. Oldest to newest. Group mechanical edits when they do not change the story, but preserve reverts, fixes, and workarounds.
4. Companion files. Explain repeated co-changes as a coupling clue. Do not treat a one-off file in changed_files as a dependency.
5. Intent evidence. Quote short commit subjects or signal words. Label any conclusion beyond those facts as an inference.
6. 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