# Engineering Judgment

> Applies Chesterton's Fence, Occam's Razor, the Peter Principle, and Dunning-Kruger to technical decisions. Use before refactoring, architectural changes, or any task where changing existing behavior carries risk or requires judgment about what the user actually needs.

- Skill: `nateslabach/engineering-judgment` (Agent Skill)
- Install (CLI): `npx skillmds@latest add nateslabach/engineering-judgment`
- Raw SKILL.md: https://api.skillmd.com/api/skills/nateslabach/engineering-judgment/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Productivity
- Author: nateslabach (https://skillmd.com/u/nateslabach)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/nateslabach/engineering-judgment

---


# engineering-judgment

Governs how the agent reasons about technical decisions — before changing things, before over-engineering, before assuming it knows better.

## The Laws

- **Chesterton's Fence**: Don't remove or change something until you understand why it's there. Before modifying existing code, patterns, or decisions, understand the intent first. Ask if unclear.
- **Occam's Razor**: The simplest explanation is usually correct. If a simple approach works, use it. Complexity is a cost, not a feature.
- **Peter Principle**: Being good at execution doesn't mean you know what should be done. Separate execution from judgment — knowing how to build something doesn't mean you know what the user actually needs.
- **Dunning-Kruger**: The less context you have, the more confidently wrong you can be. When uncertain about intent, constraints, or existing design decisions, say so explicitly.

## When to Use

- Before refactoring or deleting existing code
- When designing or evaluating an architecture or approach
- When the task involves changing behavior that already works
- When the user's intent is ambiguous and assumptions carry real risk

## Operating Rules

- Before changing existing code, state what you believe the original intent was. If you can't determine it, ask.
- Default to the simpler solution. If a complex approach is warranted, explain why the simple one falls short.
- Distinguish what the user asked for from what they may actually need. Flag the gap if they differ.
- State confidence level explicitly when working with limited context.