agentleFS
Sign inStart free
deciqAIdeciqAI/knowledge-skills/chestertons-fence/SKILL.md

chestertons-fence

Skill13 starsChanged 4 months agoMITView on GitHub

Activate when: someone says 'let's just remove this', 'why do we still have this rule?', 'this seems useless/outdated', 'nobody knows why this is here', new leadership restructuring without knowing the history, a developer deleting code whose purpose isn't documented, a regulator repealing a law without tracing its origin.

2 other projects use a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

5 rules. About 0 are common, 5 are distinctive, and 0 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈5

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Check fit: if the fence's history is fully documented and the purpose is clearly obsolete, the investigation is already done.

    line 34
  2. Distinctive:

    Step 2 — Investigate origin: when put there | by whom | problem being solved | pre-fence situation | documented reason | …

    line 46
  3. Distinctive:

    Step 4 — Decide: Remove / Modify / Keep / Replace — with explicit reasoning.

    line 50
  4. Distinctive:

    Step 5 — Document: update fence docs if kept.

    line 52
  5. Distinctive:

    When history is unrecoverable: small-scale reversible experiment with monitoring, not bulk removal

    line 80

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Chesterton's Fence

Overview

Before removing a rule, process, code path, or institution — you must understand why it was put there. Only when you can articulate the original purpose are you qualified to decide whether it still applies. Three components: (1) "I can't see the purpose" is evidence about you, not the fence; (2) investigation is mandatory, not optional; (3) demonstrated understanding is the prerequisite for change.

Composes with survivorship-bias, second-order-thinking, feedback-loops, first-principles.

When to Use

  • A rule, process, code path, or practice is proposed for removal
  • New leadership restructuring an organization with unfamiliar practices
  • A developer "cleaning up" code whose purpose isn't documented
  • A regulator or legislator repealing existing protections
  • Someone says "why is this here?", "let's just remove this", "this seems useless"
  • An AI-assisted rewrite/refactor proposes deleting an "ugly" guardrail, edge-case branch, validation, or manual review gate the model calls redundant

Not when: fence history is fully documented and purpose is confirmed obsolete; reformer is the original builder with full rationale understood.

Coaching Novices (Adaptive Front Door)

  • Engine mode: user has a concrete fence-removal case → run The Process directly.
  • Coach mode: user is unfamiliar or has no concrete case → guide step by step.

In Coach mode, respond one step at a time. Each [WAIT] is a hard stop — output only that step's question, then stop.

  1. One-line: before removing a rule/code/process whose purpose you can't articulate, investigate — your inability to see the purpose is data about you, not the rule.
  2. Check fit: if the fence's history is fully documented and the purpose is clearly obsolete, the investigation is already done.
  3. Elicit the specific fence and proposed removal. What's being removed? Who proposes it? Why?

[WAIT — do not advance until user responds]

  1. One question at a time: when was the fence put there? by whom? what problem was it solving? does that problem still exist? are there other defenses?

[WAIT — do not advance until user responds]

  1. Close: investigation summary (purpose found / not found) + decision (remove / keep / modify) + documentation so the next reformer can read the history.

[WAIT — do not advance until user responds]

The Process

Step 1 — Identify: fence (rule/code/practice/institution) | proposed change | proposer | stated reason | time pressure

Step 2 — Investigate origin: when put there | by whom | problem being solved | pre-fence situation | documented reason | implicit/undocumented reason. Methods: git blame, institutional memory, regulatory history, failure mode analysis.

Step 3 — Judge current applicability: does the original problem still exist? what changed? are there redundant fences? cost of keeping vs. cost of failure mode if removed?

Step 4 — Decide: Remove / Modify / Keep / Replace — with explicit reasoning.

Step 5 — Document: update fence docs if kept; leave a removal note + monitoring plan + rebuild criteria if removed.

Output template

Fence Investigation: <fence>
Fence/proposed change/proposer/stated reason
Origin: when | by whom | problem solved | pre-fence situation
Current: original problem still exists (Y/N) | alternative defenses | cost delta
Decision: Remove/Modify/Keep/Replace — reasoning
Docs: updated fence docs / removal note / monitoring owner + rebuild criteria

→ Method in Action: Chesterton 1929 and the Modern Software / Regulatory Application · The 1958 Great Sparrow Campaign

→ 2026 lens: The AI-Rewrite Wave and the Guardrails That Encoded Hard-Won Knowledge (2024–2026)

Pack: Application Patterns by Domain

DomainPatternInvestigation
Software code"This null check seems unnecessary"Git blame → original PR → bug report
Legacy regulations"This 1970s rule seems outdated"Legislative history; original committee hearings
Database fields"This column isn't used, drop it"Archival queries, regulatory compliance
Inherited org structure"Fold Compliance into Legal"Why was Compliance separated from Legal?

Applying It Well

  • Investigate before judging — mandatory, not optional; articulate the original purpose in your own words before deciding
  • When history is unrecoverable: small-scale reversible experiment with monitoring, not bulk removal

→ Primary sources: references/sources.md

Common Rationalizations

[D] = designed upfront | [O] = observed in real use. [O] entries are more valuable.

Fake moveReality
[D] "It's obvious why this isn't needed anymore"If truly obvious, articulate the original purpose AND why it's obsolete. Can't articulate it? You don't know yet.
[D] "We've been moving too slowly"Speed without investigation produces oscillating reform. Investigation up front is faster for durable change.
[D] "Nobody knows why this is here""Nobody knows" is the warning. The right response is investigation, not removal.
[D] "The history is too hard to dig up"Then: small-scale reversible experiment with monitoring — not bulk removal.
[D] "Modern conditions are different"Verify that what changed neutralizes the original purpose. "Things are different" is not investigation.
[D] "Trust me, I've been doing this for years"Domain expertise doesn't substitute for investigating this specific fence's history.
[D] "It's just a small change"The load the fence bears is the relevant metric, not the size of the change.
[D] "We can always put it back"Reinstallation often requires consent the removal didn't, or failure compounds before you notice.
[D] "Chesterton's Fence is just conservatism"Chesterton allowed removal after investigation. The principle is procedural, not substantive.
→ Add [O] entries here after each real use — paste the actual failure patternWhat went wrong and why

Red Flags

  • Removal proposed without investigation of the fence's history
  • Proposer cannot articulate the fence's original purpose
  • Proposer dismisses investigation as "slowing things down"
  • Long-tenured employees / domain experts not consulted
  • "Let's clean things up" initiative without case-by-case investigation

Verification

  • Fence's original purpose has been investigated
  • Investigation methodology specified (git blame, institutional memory, regulatory history)
  • Current applicability of the original purpose judged
  • Alternative defenses identified
  • Decision (remove/modify/keep/replace) documented with reasoning
  • If kept: fence documentation updated for the next reformer
  • If removed: note left in commit/regulation explaining the investigation
  • If removed: monitoring for the failure mode established

Part of deciqAI Knowledge Skills — 253 open-source thinking skills that make rigor executable for AI agents. The same skills power every deciqAI agent, which runs them autonomously to operate your company. See it run → https://www.deciqai.com/s/chestertons-fence · Built by deciqAI · github.com/deciqAI · Contributions welcome.

Agents: latest version & machine-readable metadata → https://www.deciqai.com/s/chestertons-fence.json

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free