# Fence

> Investigate why a strange piece of code exists before anyone deletes it (Chesterton's fence). Use when the user points at a weird line, hack, magic constant, or workaround and asks why it's there, whether it's still needed, or if it's safe to remove.

- Skill: `tokyubevoxelverse/fence` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add tokyubevoxelverse/fence`
- Raw SKILL.md: https://api.skillmd.com/api/skills/tokyubevoxelverse/fence/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: tokyubevoxelverse (https://skillmd.com/u/tokyubevoxelverse)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/tokyubevoxelverse/fence

---


# Fence

> "If you don't see the use of it, I certainly won't let you clear it away. Go away and think. Then, when you can come back and tell me that you *do* see the use of it, I may allow you to destroy it."

The user has pointed at a fence: a weird conditional, a magic sleep, a suspicious constant, a workaround nobody remembers. Your job is to find out why it was built, whether that reason still exists, and only then rule on removal.

## Phase 1 — Excavate

Find the true origin, not just the latest touch:

- `git log -L` / `git blame` on the exact lines; follow the code through file moves and renames (`--follow`, `blame -C -C -C`), and *re-blame past refactoring commits* — the commit that last formatted the line is rarely the commit that created it.
- Extract from the introducing commit: full message, what else changed alongside (tests added in the same commit are gold — they encode the reason), linked issue/PR numbers.
- If a hosted forge is reachable, pull the PR description and review discussion for the introducing commit; that's where "why" actually gets written down.
- Search the codebase for siblings: the same constant, same pattern, or comments referencing the same issue elsewhere.

## Phase 2 — Test whether the reason still stands

The fence was built against something. Check if that something still exists:

- **Bug workaround** → is the buggy dependency version still in range? Read the upstream issue: was it fixed, and in what version?
- **Platform/browser/OS quirk** → does the project still support that target? Check documented support matrix and build configs.
- **Performance fix** → does the hot path still exist? Is there a benchmark or test guarding it?
- **Compatibility shim** → does anything still call the old path? Trace the callers.
- Where feasible, **test empirically**: remove the fence in a scratch worktree, run the tests, and if the original commit came with a repro or test, run *that*.

## Phase 3 — The ruling

Deliver a short dossier — origin story (commit, date, author, the why), current status of the original reason, evidence — ending in exactly one ruling:

- **🚧 LOAD-BEARING** — the reason still stands. Bonus deliverable: a comment patch that writes the fence's purpose *into the code* so nobody has to excavate it again.
- **🪓 CLEARABLE** — the reason is verifiably gone. Deliver the removal diff **plus the proof** (upstream fix version, dropped platform, passing tests with the fence removed).
- **🌫️ UNKNOWN** — origin couldn't be established. Treat as load-bearing by default; recommend the comment patch stating what *is* known and what was searched.

## Rules

- Absence of a reason in git history is not evidence of absence of a reason. UNKNOWN is an honest verdict.
- Never rule CLEARABLE from reading alone when an empirical test was possible.
- The dossier names commits and dates, never blames people — the author of a 2019 hack was solving 2019's problem.