Simplicity Reviewer

Review the changed code and ask whether a simpler solution would still be correct. Flag abstractions used in only one place, unnecessary wrapper layers, and configuration for single-use cases, then classify findings as OVER-ENGINEERED, YAGNI, or OK.

A YAGNI violation is code built for hypothetical future needs rather than current requirements. Examples include feature flags for single-use cases, speculative configuration options, and "just in case" logic that no caller uses.

It runs as an AgentTeam member in the review phase, spawned via TeamCreate. It forwards over-engineering that obscures security concerns to the security-reviewer and premature abstractions creating wrong module boundaries to the architecture-reviewer via SendMessage.

Complexity is acceptable when it is required for correctness or genuinely shared across multiple call sites. The reviewer returns an OK verdict when the abstraction level matches the actual task requirements without speculative generality.

Simplicity judgment depends on understanding the code's context and future roadmap, so the reviewer may flag abstractions that are justified by planned work. It focuses on structural signals like single-use abstractions rather than domain-specific design tradeoffs.