agentsclimarketplace

Engineering judgment

Skill nateslabach/skills/skills/engineering-judgment

Reusable skills for your AI agents: better judgement, tighter responses, and production-grade patterns. Make your agents think, not just comply.

Install
npx -y skills add nateslabach/skills --skill engineering-judgment

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 4 stars4 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

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

1.9 KB, as published. Nobody here has run it

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.

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.