From grimoire
Establishes why each element exists in an inherited working system before making modifications, preventing unintended breakage.
How this skill is triggered — by the user, by Claude, or both
Slash command
/grimoire:apply-chestertons-fenceThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Before modifying any element of an inherited working system, establish why that element exists — because systems that work encode solutions to problems no longer visible, and removing elements without that understanding destroys the solution along with the evidence of the problem.
Before modifying any element of an inherited working system, establish why that element exists — because systems that work encode solutions to problems no longer visible, and removing elements without that understanding destroys the solution along with the evidence of the problem.
When Cao Can (曹参) became prime minister of Han (~188 BC), succeeding the legendary Xiao He, officials expected active reform. He changed nothing. When Emperor Hui pressed him on this "laziness," Cao Can asked two questions: Could the Emperor surpass Emperor Gaozu in wisdom? No. Could Cao Can surpass Xiao He? No. "Then," he said, "their laws and institutions are already clear. We have only to maintain them faithfully." 资治通鉴 records the era that followed as one of the most stable in Han history. Sima Guang cited this as evidence that maintaining a working system faithfully outperforms well-intentioned reform of a system you don't fully understand.
G.K. Chesterton articulated the same principle in "The Thing" (1929): "Don't ever take a fence down until you know the reason it was put up." The reformer who removes a fence without understanding it has not improved the system — they have removed a constraint whose purpose they couldn't see.
Adopted by: Amazon (two-way door vs. one-way door framework — one-way-door decisions, which are hard to reverse, require deep understanding of why the current state exists before reversal); Google, Netflix, Stripe (engineering principle: "don't refactor code you don't understand" — standard software engineering practice); McKinsey, BCG, Bain (diagnostic before solution is foundational methodology — understand current state thoroughly before prescribing change).
Impact: Deming "Out of the Crisis" (1986) mathematically demonstrated that "tampering" — adjusting a stable system without a model of why it works — consistently makes the system perform worse. His funnel experiment is a standard illustration in statistical process control education. Organizations that change working systems without understanding them routinely break what worked and then struggle to diagnose why, because the problem the system was solving is no longer visible once the solution is gone.
Why best: The instinct to change things upon arrival — to signal activity, to differentiate from a predecessor, or to apply prior-context knowledge — is nearly universal and nearly always costly in inherited contexts. The disciplined alternative is not passivity but diagnosis: build a model of why each element exists before touching any element.
Distinct from apply-premortem: apply-premortem surfaces failure modes of a NEW plan before commitment. apply-chestertons-fence applies to EXISTING working systems — the question is not "what could go wrong with our new plan" but "why does the current system work the way it does, and what would break if we changed this element?"
Distinct from apply-inversion: apply-inversion reasons backward from failure to identify risks in a plan. apply-chestertons-fence is a prerequisite discipline: before any change decision, establish whether you can explain the function of what you're proposing to change.
Identify what "working" means. Before diagnosing the system, define what "working" looks like quantitatively. What outputs does the current system produce? At what rate? With what variance? This establishes the baseline you need to detect whether a change improved or degraded performance.
Map the system before touching it. List every major element — rule, process, structure, constraint, norm — that you are considering changing. For each element, write one sentence explaining why you believe it exists.
Apply the fence test to each element. For each element where you cannot write a complete explanation of why it exists: do not change it yet. The inability to explain why something is there is the signal that you don't yet understand it — not that it's unnecessary.
Investigate unexplained elements. Ask people who have worked with the system longest: "Why does this exist? What was the problem it was solving? What happened when it wasn't here?" If no one knows, look for historical incidents or failures that preceded the element's introduction. Often the element was introduced after a costly failure — and its function is to prevent that failure from recurring.
Only change elements you can fully explain. Prioritize changes where you can articulate: (a) why the current element exists, (b) what problem the change solves, (c) why the alternative is better than the current approach. For elements where you cannot articulate all three: wait.
Change one element at a time in stable systems. In a working system, changing multiple elements simultaneously makes it impossible to diagnose which change caused a subsequent problem. The discipline of single-variable change is especially important in inherited systems where your model is incomplete.
Document the reason for each change. Write down — before making the change — why the element existed, why you are changing it, and what you expect to happen. This record prevents future inheritors from treating your changes as Chesterton's fences they don't understand.
New executive inheriting a team: Incoming VP notices the team has a weekly all-hands meeting that seems redundant. Before canceling it, they attend for a month and discover it's the only forum where cross-functional blockers surface early — without it, issues accumulate until they become crises. The meeting survives; the format is improved instead.
Acquiring a company: Integration team decides to migrate the acquired company's customer data to the acquirer's CRM system. The acquired CRM has custom fields that seem redundant. Before removing them, the team investigates and finds those fields are used by the support team to flag accounts with unusual contractual terms that require special handling. Removing them would cause standard process to be applied to accounts where it would breach contract. The fields are preserved and migrated.
Software engineering: New engineer takes over a codebase with a seemingly redundant validation check on a field that appears to always be populated. They remove it as cleanup. In production, they discover that the check was protecting against a specific edge case in an upstream system that occasionally sends null values for that field — an edge case the original engineer had experienced and fixed. The check is restored after an incident.
Organizational redesign: Consulting team recommends removing a middle-management layer as an efficiency measure. Before implementing, a manager with 10 years of tenure explains that the layer was introduced after a product incident where field teams made contradictory commitments to the same customer. The layer's function is coordination of commitments. The redesign is restructured to preserve the coordination function through a different mechanism.
npx claudepluginhub jeffreytse/grimoire --plugin grimoireRanks candidate interventions by Donella Meadows' 12-level hierarchy to find the highest-leverage point you can actually move. Use when parameter tweaks keep not sticking.
Investigates historical context of existing code, patterns, or constraints via git log/blame, PR/ADR searches, and dependency analysis before proposing changes.
Investigates historical context of existing code, patterns, constraints, or ADRs using git log/blame, GitHub PR searches, and dependency analysis before proposing changes.