judge-overengineering-reviewlisted

# Judge Over-Engineering Review Use when reviewing a non-trivial diff for over-engineering before declaring the work done. This skill is the parent-facing companion to the `judge-minimum-diff` rubric — the parent runs it as a pre-flight pass, and the `judge` subagent applies the same rubric as a quality-gate dimension. ## When to run - Before declaring any non-trivial code change complete. - During code review of a pull request that touches more than one file or introduces new abstractions. - When a previous implementer or coder's diff feels heavier than the brief required. For trivial one-line fixes or pure typo corrections, skip this skill — YAGNI applies to review overhead too. ## Workflow 1. **Read the brief** the implementer was given. Note the explicit asks and the explicit non-goals. 2. **Read the diff** scoped to the allowed paths. Note every new file, new abstraction, new dependency, and new config key. 3. **Walk the reduction ladder** from `judge-minimum-diff`: - Did the diff take the highest rung that holds? - Is there stdlib / native / installed-dep reuse the diff missed? - Could the change be one line and isn't? 4. **Score each finding** under the rubric below. 5. **Report** in the parent-facing review block format: `path:line` for every finding, severity per §4.1 of the base prompt, the suggested smallest fix. ## Review checklist A diff fails the over-engineering review when it has **any** of: - **Speculative abstraction.** In