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.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: tokyubevoxelverse
• Source: tokyubevoxelverse/fence
• License: MIT

Install and usage instructions live in the source repository linked above.