engineering-judgment git:20260521.a303943A

Immutable. This exact content never changes and is served at /api/v1/blob/09abdda1227910c9.

---
name: engineering-judgment
description: 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.
---

# 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.