Why does this weird code exist, and can I delete it?
Every codebase has them: the sleep(50) nobody dares remove, the magic constant, the if that makes no sense. Chesterton's rule says you can't clear the fence until you know why it was built — but the knowing part means an afternoon of git archaeology, so everyone just... leaves it.
fence does the archaeology. Point it at the weird line and it re-blames past refactors to the true introducing commit, pulls the commit message, sibling tests, and PR discussion, checks whether the original reason still exists (is that upstream bug fixed? is that browser still supported?), and where possible tests removal empirically in a scratch worktree before ruling.
Works as a Claude Code skill:
# available in every project
git clone https://github.com/tokyubevoxelverse/fence ~/.claude/skills/fence
# or just one project
git clone https://github.com/tokyubevoxelverse/fence .claude/skills/fence/fence src/render.js:214 — why is there a setTimeout(0) here?
/fence what is RETRY_JITTER_MS = 173 about, can it go?
/fence this whole polyfill block in utils/compat.ts
| Ruling | Meaning | You get |
|---|---|---|
| 🚧 LOAD-BEARING | The reason still stands | A comment patch writing the why into the code, so nobody excavates twice |
| 🪓 CLEARABLE | The reason is verifiably gone | The removal diff plus the proof (upstream fix version, passing tests without it) |
| 🌫️ UNKNOWN | Origin lost to history | Treated as load-bearing; a comment documenting what is known |
The commit that last touched a line is almost never the commit that created it. fence follows the code through renames, moves, and reformats (blame -C -C -C, log -L), because the answer to "why" lives in the original commit — usually right next to the test that encodes it.
Part of a toolbox of skills that do real work — see tokyubevoxelverse/skills.
MIT