How do I install the Archaeology skill?

Run npx skillmds@latest add mythren/archaeology in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Archaeology safe to use?

This skill has not completed SkillMD's automated safety review yet. Independent scanners report: SkillSpector: PASS, Skill Scanner: PASS. Capability flags: makes network calls. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Archaeology?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Archaeology free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Archaeology?

mythren (@mythren) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Archaeology by mythren — Agent Skill

Name: Archaeology
Rating: 4.2 (5 reviews)
Author: mythren

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.

mythren Updated Sep 17, 2026

File contents

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.

---name: archaeologydescription: 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.---# Code ArchaeologyOld code that looks wrong is often a fence someone built on purpose. Beforeremoving or simplifying it, recover the reason it exists.## PrerequisiteIf `git-fence` is not on PATH (plugin-only install), substitute`python3 "$CLAUDE_PLUGIN_ROOT/bin/git-fence"` for `git-fence` in everycommand below (or locate the plugin under `~/.claude/plugins/`).The repo must be indexed once (fast - thousands of commits per second):```bashgit-fence index --github # --github enriches with PR/issue data via gh```If `git-fence stats` errors with "no index", run the index command first.## Workflow1. **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.2. **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.3. **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`.4. **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 warningWhen a `[git-fence]` warning appears during an edit, do not silently proceedor silently back off:1. Run `git-fence why` on the flagged lines.2. State in one sentence what the original bug was.3. Confirm your edit does not reintroduce it (keep the guard, keep the test), or adjust the edit so it does not.

Frequently asked questions