agentsclimarketplace
Sign in

Fence

Skill tokyubevoxelverse/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.From its SKILL.md

Install
npx -y skills add tokyubevoxelverse/fence

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

  • 20 days oldThe repository was created 20 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
  • 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

3.2 KB, 678 tokens by cl100k_base, as published. Nobody here has run it

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.

What ships with it: 2 files

3.2 KB alongside SKILL.md

Keep looking

Skills are one crate of 326,758. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.