Diagnose which mental domain is holding you back before choosing a cognitive intervention.
by deciqai1 installs3 stars
Coding
Chesterton's Fence
Try itA structured check before removing any rule, process, or piece of code — so you know why it exists first.
What it does
This skill applies a two-century-old wisdom to modern decision-making: before removing anything, investigate its original purpose. It guides you through a five-step process — Identify, Investigate origin, Judge current applicability, Decide, Document — preventing the common mistake of removing a fence you don't understand. The skill offers two engagement modes: Engine mode for concrete removal cases, and Coach mode that walks users step-by-step through investigation, stopping for responses at each stage. It surfaces common rationalizations ("nobody knows why this is here", "we can always put it back") and red flags, and produces a structured investigation summary with a clear decision and d…
When to use it
- A developer wants to delete legacy code with no documentation
- New leadership proposes restructuring without knowing the history
- An AI assistant suggests removing a validation check it calls redundant
- A regulator considers repealing an older law without tracing its origin
The skill document
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.
- 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.
- Check fit: if the fence's history is fully documented and the purpose is clearly obsolete, the investigation is already done.
- Elicit the specific fence and proposed removal. What's being removed? Who proposes it? Why?
[WAIT — do not advance until user responds]
- 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]
- 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/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
| Domain | Pattern | Investigation |
|---|---|---|
| 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 move | Reality |
|---|---|
| [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 pattern | What 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 — 227 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/c/chestertons-fence · ⭐ Star the repo → https://github.com/deciqAI/knowledge-skills · Contributions welcome.
Agents: latest version & machine-readable metadata → https://www.deciqai.com/s/chestertons-fence.json
Questions people ask
- When should I use this skill?
- Activate when someone proposes removing a rule, process, code, or practice without understanding its original purpose — phrases like "why do we still have this?" or "let's just delete this" are triggers.
- What's the core process?
- Five steps: Identify the fence and proposed change, Investigate its origin (when, by whom, what problem it solved), Judge whether the original problem still exists, Decide to Remove/Modify/Keep/Replace, and Document the decision so the next reformer has context.
- What if I can't find the history?
- When the fence's history is unrecoverable, the skill recommends a small-scale reversible experiment with monitoring — not bulk removal. The inability to see the purpose is treated as evidence about you, not evidence that the fence is unnecessary.
Related skills
Replace vague hunches with calibrated probability estimates you can track and improve over time.
by deciqai2 stars
Make irreversible life decisions by projecting to 80 and naming which regret you'd rather live with.
by deciqai1 installs2 stars
Spot weak reasoning before you accept it — a structured audit for any argument
by deciqai2 stars
Make better high-stakes decisions by knowing when to trust intuition and when to force slow analysis.
by deciqai1 installs2 stars
Detect when presentation language is steering your decision instead of the facts themselves.
by deciqai1 installs2 stars
More from deciqai
Browse all skillsDiagnose your organization's strategic phase and spot misaligned initiatives before they drain momentum.
by deciqai7 installs2 stars
When multiple explanations all fit the evidence, pick the one that assumes the least.
by deciqai5 installs2 stars
Identify catastrophic failure paths before you commit — and design your plan around eliminating them.
by deciqai4 installs2 stars
Trace decisions past the obvious effect to catch the consequences that reverse it.
by deciqai4 installs2 stars
A structured interview and analysis process that uncovers the actual job customers hire your product to do — and who they're really competing against.
by deciqai3 installs3 stars
Diagnose why learners are struggling and redesign instruction to stay within working memory limits.
by deciqai2 installs3 stars