MCP.Market

commit-archaeologist skill

by Shubhamsaboo·Shubhamsaboo/awesome-llm-apps·145k stars·Apache-2.0

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.

A100/100content scan

Is the commit-archaeologist skill safe?

Clean: nothing in its files matched our rules. We read 4 files in the folder on 2026-10-25.

No findings.

Install the commit-archaeologist skill

A skill is a folder. Copy it into your agent's skills folder and the agent loads it when the task matches its description. 

git clone --depth 1 https://github.com/Shubhamsaboo/awesome-llm-apps.git /tmp/awesome-llm-apps
mkdir -p ~/.claude/skills
cp -r /tmp/awesome-llm-apps/agent_skills/commit-archaeologist ~/.claude/skills/commit-archaeologist
available in every project

In the Claude apps, zip the folder and upload it from the Skills settings. The folder on GitHub

The instructions your agent would load

SKILL.md as published, without the frontmatter. Read it on GitHub

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

and co-change threshold

  • region: normalized repository, current and historical paths, mode, range,

and detected renames

  • introduced_by: oldest commit in the selected history
  • timeline: commits ordered oldest to newest, with category, changed files,

and unfinished-work markers found in commit messages

  • 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,

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:

a confidence label: high, medium, or low.

  1. Bottom line. One or two sentences with the most likely explanation and

files that make the initial purpose clearer.

  1. Origin. Introducing hash, date, author, subject, and the neighboring

change the story, but preserve reverts, fixes, and workarounds.

  1. Timeline. Oldest to newest. Group mechanical edits when they do not

treat a one-off file in changed_files as a dependency.

  1. Companion files. Explain repeated co-changes as a coupling clue. Do not

conclusion beyond those facts as an inference.

  1. Intent evidence. Quote short commit subjects or signal words. Label any

temporary choices worth checking before an edit.

  1. Change risk. Name the constraints, companion files, and unresolved

Keep hashes short in prose, but preserve enough characters to identify them. Do not dump the full JSON unless the user asks.

Evidence rules

file's first commit.

  • Current blame ownership is not proof of original authorship.
  • The oldest selected commit is the region's introduction, not always the

author or linked discussion can confirm whether the constraint still applies.

  • 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

"likely" instead of inventing a design rationale.

  • If the history is thin or messages are vague, say "the history shows" and

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

More skills from Shubhamsaboo/awesome-llm-apps

  • Aadvisor-orchestrator-workerUse when a task is too large for one model pass, needs parallel research or generation across many subtasks (like researching a dozen competitors at once), or the user asks to orchestrate multiple models, split work across a model team, run an advisor-worker loop, have a stronger model review the plan while cheap workers execute, or says "too big for one model" or "fan this out". Not for single-file edits or tasks one model handles in one pass.
  • Achatgpt-app-builderDEPRECATED: This skill has been replaced by `mcp-app-builder`. Check if `mcp-app-builder` is available in the skills folder. If not, install it: `npx skills install mcp-use/mcp-use --skill mcp-app-builder` Use `mcp-app-builder` instead of this skill.
  • Adependency-doctorChecks requirements.txt, pyproject.toml, and package.json dependency manifests for surface-level direct-dependency footguns: standard-library shadowing pins, abandoned backports, unpinned dependencies, and obvious intra-manifest conflicts, plus opt-in PyPI yanked releases. Use when the user asks to check a manifest for dependency problems, asks why dependencies won't install or whether anything is wrong with their dependencies, wants a dependency autopsy, or suspects dependency manifest rot. Runs offline by default as a local tool for the user's own project, not repository CI.
  • Afirst-readerBeta readers for any draft, run by simulating how a real reader experiences it, moment by moment. A skim gate, a no-lookahead timed read producing an attention transcript with quit points, a recall test of what a reader remembers the next day, and a trust ledger of the implied author. Use when the user asks for a beta read, beta readers, test readers, human review, reader review, to read something like a human, to be a first reader, whether a piece holds attention or will actually get read, for a quick read of whether a busy skimmer would even open a post, what readers will remember or take away tomorrow, where readers stop reading or bounce, or why a draft still feels off or hollow after anti-slop or humanizer edits. Final gate before publishing; reports where the reading broke; never rewrites.
  • Amcp-apps-builder**MANDATORY for ALL MCP server work** - mcp-use framework best practices and patterns.
  • Amcp-builderDEPRECATED: This skill has been replaced by `mcp-app-builder`. Check if `mcp-app-builder` is available in the skills folder. If not, install it: `npx skills install mcp-use/mcp-use --skill mcp-app-builder` Use `mcp-app-builder` instead of this skill.
  • Aproject-graveyardScans the developer's machine for dead side projects, autopsies each one from its git history (died at the payments wall, killed by a newer project, finished but never shipped), surfaces their personal death patterns, and picks the corpse most worth resurrecting — then helps ship it. Use when the user mentions abandoned, unfinished, or old side projects, asks "what should I finish", wants to revive or resurrect a project, says "run the graveyard", wonders why they never finish anything, or is about to start a new project that sounds like one they already built. Runs entirely locally.
  • Ascope-creep-detectorAnalyzes git diffs against a stated intent to detect scope creep, unrelated files, broad pull requests, changes that grew beyond a fix, dependency additions, public API renames, config or CI edits, oversized hunks, and formatting-only files. Use when the user asks whether a change grew beyond the fix, a PR is too broad, or what unrelated stuff they touched, and wants keep, split, or justify guidance. Operates locally and offline.
  • Athinking-out-loudA contract for what the agent does when a long, messy, stream-of-consciousness ramble arrives (usually voice dictation): act on nothing until the echo brief is approved. The echo audits the entire transfer, mission, locked decisions and constraints, open questions, flips and parked tangents, with the model's inferences and guesses quarantined away from the user's own phrasing, so the user verifies what the model believes, not just what it doubts. Use when the user says "let me think out loud" or wants to ramble a bit before building anything, when a message opens with a speech-to-text preamble like "switching to voice, sorry for typos", when input is a long weakly punctuated stream with restarts and mid-message reversals ("actually no, wait, scrap that idea entirely"), or when the user asks to be interviewed about a fuzzy half-formed idea. Includes an optional capture mode for rambles spread across several messages and an optional targeted interview.

All agent skills → · MCP servers