chestertons-fence

Enforces git-based context discovery before allowing code deletions or refactors.

Updated Mar 31, 2026
One-click install
npx skills add https://github.com/calvyntwh/karu-custom-skills --skill chestertons-fence
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: chestertons-fence
Source: https://github.com/calvyntwh/karu-custom-skills/tree/main/skills/chestertons-fence
Command: npx skills add https://github.com/calvyntwh/karu-custom-skills --skill chestertons-fence

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

Prevents accidental regressions and hidden breakages by requiring context and evidence before removing or simplifying code that may have historical or environmental reasons for existing.

Core Features & Use Cases

  • Context-first audit: A stepwise protocol to pause, investigate history, and verify intent before changing or deleting code.
  • Archaeology & interrogation: Guidance to use git blame, commit inspection, and repository search to uncover reasons for odd or "ugly" code.
  • Risk triage & decision matrix: Prioritizes investigation depth based on blast radius and recommends KEEP, REFACTOR, DELETE, or FLAG.
  • Rubber-duck validation: Enforces explaining code in plain English as a safety check before making irreversible edits.
  • Self-improvement logs: Optional learning artifacts to capture recurring patterns and corrections for future detection.

Quick Start

Use the chestertons-fence skill to audit a risky code change by performing git archaeology, explaining the logic in plain English, and documenting your decision before deleting anything.

Frequently Asked Questions about chestertons-fence

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I safely delete legacy code during refactoring without causing regressions?

To safely delete legacy code during refactoring, enforce context discovery before changes by inspecting git history and explaining the logic in plain English to verify intent and prevent hidden breakages.

What is git archaeology and how does it help with code review?

Git archaeology uses git blame and commit inspection to uncover historical reasons for odd or ugly code. It helps code review by revealing edge cases and external constraints before modifying legacy codebases.

How do I assess the risk of removing code before a cleanup?

Assess the risk of removing code by triaging its blast radius. Prioritize investigation depth based on impact, then decide to KEEP, REFACTOR, DELETE, or FLAG the targeted code segments.

Does rubber-ducking work for preventing accidental regressions in legacy code?

Rubber-ducking prevents accidental regressions by enforcing a plain English explanation of code logic as a safety check. This validation step ensures you fully understand intent before making irreversible edits.

When should I not delete ugly code during a debugging session?

You should not delete ugly code during debugging if git history inspection reveals hidden environmental constraints or edge cases. Flag the code instead of deleting to avoid causing accidental regressions.