judge-minimum-diff

Judge Minimum-Diff Lens

Use when judging a code change, diff, or implementation report. This is the rubric dimension the Pythinker judge subagent applies to every non-trivial diff — the same ladder that lives in the base system prompt's §6 (Code Standards), surfaced here as an explicit rubric so the judge, an implementer doing pre-flight, or a reviewer running the over-engineering skill apply it uniformly.

The judge applies the full ladder. There is no mode switch on the judge (lite / full / ultra); the implementer is the role that would carry a mode toggle if one is ever introduced.

The ladder — walk it before writing code; stop at the first rung that holds

1. Does this need to exist at all? A speculative need is skipped, said so in one line. YAGNI is the highest rung.
2. Does the standard library do it? Use it.
3. Does a native platform or framework feature cover it? A database constraint over an app-level check, a built-in form control over a picker library, the language's own construct over a hand-rolled one — use it.
4. Does a dependency already in the manifest solve it? Use it; never add a new dependency for what a few lines cover.
5. Can it be one line? Make it one line.
6. Only then write the minimum code that works.

When two rungs both hold, take the higher one and move on. The ladder is a reflex, not a research project. None of this overrides the guards below: trust-boundary validation, error handling that prevents data loss, security, and accessibility stay in even at rung 5.

Minimum-diff rubric

A diff passes the minimum-diff check when all of these hold:

• The change takes the smallest rung of the ladder above before adding new code.
• There are no abstractions (no interface with one implementation, no factory for one product, no config layer for a value that never changes) that the brief did not ask for.
• There are no new dependencies unless the brief asked for one; when one is added, a one-line justification names why an already-installed dependency or the standard library couldn't cover it.
• There are no new config keys unless a consumer is named in the same diff (a value with no consumer is over-engineering).
• There are no new files unless the brief asked for them; reuse the nearest neighbor's module.
• There are no error paths for impossible scenarios; validate at boundaries, not deep in business logic.
• There is no reformatting, renaming, or wrapping churn outside the changed lines. Formatting churn is scope creep.
• Comments only where they earn their keep: non-obvious algorithms, deliberate simplifications whose ceiling matters, business rules, or genuine TODO: technical debt. No self-evident comments.