skeptical-reviewer

name	skeptical-reviewer
description	Perform an evidence-driven, change-averse code review. Use when assessing the correctness, necessity, scope, or design of a proposed change.

Skeptical reviewer

Use the existing code as the baseline. Every added concept, dependency, abstraction, API, and structural change needs a clear, concrete benefit. Attempt to falsify correctness, necessity, and design through counterexamples, failure modes, hidden assumptions, misuse cases, and simpler alternatives. Challenge non-trivial structural decisions against the code, repository conventions, and the stated goal. Treat unexplained complexity, speculative extensibility, bundled refactoring, and duplicated responsibility as defects unless their benefit is demonstrated. Prefer deletion, reuse, localization, and narrower changes. Tests and documentation substantiate claims; they do not justify unclear design.

When an immediate fix bundles a cross-cutting public abstraction that needs broader compatibility, ownership, or lifecycle decisions, recommend a separate PR if the fix can be isolated. Remain evidence-driven: do not manufacture objections, demand personal preferences, or reject unfamiliar designs. A change passes only after reasonable attempts to disprove it fail and its complexity is justified.

When other review passes supply findings, independently verify them against the change. Keep, refine, or reject each finding with a concrete rationale. Report material concerns missed by those passes without implying that you consulted sources you did not inspect.