Archaeology

Skill mythren/git-fence/skills/archaeology

Investigate why code exists before changing it, using indexed git history (commit -> PR -> issue). Use when a git-fence warning fires, when the user asks why code exists or whether it is safe to delete, before removing a check/workaround/special case that looks unnecessary, or when simplifying old code.From its SKILL.md

Install

npx -y skills add mythren/git-fence --skill archaeology

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

27 days oldThe repository was created 27 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

2.5 KB, 574 tokens by cl100k_base, as published. Nobody here has run it

Code Archaeology

Old code that looks wrong is often a fence someone built on purpose. Before removing or simplifying it, recover the reason it exists.

Prerequisite

If git-fence is not on PATH (plugin-only install), substitute python3 "$CLAUDE_PLUGIN_ROOT/bin/git-fence" for git-fence in every command below (or locate the plugin under ~/.claude/plugins/).

The repo must be indexed once (fast - thousands of commits per second):

git-fence index --github   # --github enriches with PR/issue data via gh

If git-fence stats errors with "no index", run the index command first.

Workflow

Ask the index first.
- git-fence why <file> <line> - full provenance of one line: commit, PR, linked issues.
- git-fence why <file> - all fix-linked commits that touched the file.
- git-fence check <file> <start> <end> - load-bearing commits in a line range.
Read the actual discussion when stakes are high. The index gives you PR and issue URLs. For security fixes, regressions, or anything you plan to delete, fetch the PR/issue with gh pr view <n> / gh issue view <n> and read why the change was made and what alternatives were rejected.
Dig deeper when the index has no answer.
- git log -L <start>,<end>:<file> - full evolution of a line range, including commits that predate squash merges.
- git log --follow --oneline -- <file> - history across renames.
- A test added in the same commit is the best spec for what the code protects. Check with git show <sha> --stat.
Decide with evidence. Only after you can state what bug the code prevents decide whether removal is safe. If the original bug can no longer occur (dependency removed, API changed), say so explicitly and delete with confidence. If you cannot reconstruct the reason, keep the code and say why.

Responding to a git-fence hook warning

When a [git-fence] warning appears during an edit, do not silently proceed or silently back off:

Run git-fence why on the flagged lines.
State in one sentence what the original bug was.
Confirm your edit does not reintroduce it (keep the guard, keep the test), or adjust the edit so it does not.

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.