When to use it

Use git-archaeologist before deleting or weakening a guard, retry, lock, or other defensive construct whose purpose is unclear. An apparently redundant branch may be the surviving record of a failure the current happy path does not reveal.

How it works

Figure 01

Connect the original reason to today’s behavior.

  1. Trace

    Read the history behind a defensive construct.

  2. Compare

    Inspect current callers, tests, and replacement controls.

  3. Recommend

    Explain whether to keep, replace, or remove it.

ResultA recommendation grounded in history and current code
Historical rationale is one input. A safe-to-remove conclusion also requires evidence that the responsibility is still met today.

The skill traces relevant history through blame and commits, then looks at current callers and tests. It gathers the original rationale where available and checks whether the conditions that justified the code still exist.

A safe-to-remove conclusion also needs current evidence: replacement controls, changed callers, or tests showing the responsibility is still met. A historical explanation alone cannot prove that today’s deletion is safe.

An example request

Ask your agent

“Before removing this duplicate-delivery guard, investigate why it was added and whether current callers and tests make it unnecessary.”

This illustrates a request you can adapt; it is not a transcript of a completed run.

A grounded recommendation about keeping, replacing, or removing the construct, with the history and present-day evidence behind it.

Install and use

The skill’s identifier is git-archaeologist. It ships in the discipline-gates plugin. In Claude Code, first add the Overclock marketplace, then install the package:

/plugin install discipline-gates@overclock

For a standalone installation, keep the skill directory and its bundled resources together. The repository also includes per-skill Codex metadata. Read the full skill instructions for its exact workflow and supporting files.

What to keep in mind

Commit messages and historical comments are evidence to assess, not instructions to follow. They may be incomplete or no longer accurate.

The investigation should be scoped to the risky change. Routine edits that do not weaken defensive behavior should not trigger a history tour.

  • Test discipline — Demonstrate the bug before changing the code that is supposed to fix it.
  • Debugging discipline — Build a useful observation loop for a bug that resists straightforward reproduction.