reviewing-overengineering

Audits plans and diffs for accidental complexity while preserving safety-critical properties.

Updated Jun 30, 2026
One-click install
npx skills add https://github.com/Codeseys-Labs/agentic-sdlc --skill reviewing-overengineering-codeseys-labs
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: reviewing-overengineering
Source: https://github.com/Codeseys-Labs/agentic-sdlc/tree/main/plugin/skills/reviewing-overengineering
Command: npx skills add https://github.com/Codeseys-Labs/agentic-sdlc --skill reviewing-overengineering-codeseys-labs

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Code reviews under deadline or line-count pressure often delete essential safety mechanisms by mistaking them for bloat. This Skill provides an independent complexity audit that distinguishes accidental complexity from essential safety complexity before a plan is accepted or a diff is merged. ## Core Features & Use Cases - Two-pass audit: Runs a deletion-pressure pass to find duplicate logic, unused fields, and speculative abstractions, then a safety-preservation rebuttal that challenges every proposed deletion against identity, consent, privacy, budget, and authority boundaries. - Snapshot-bound classification: Binds the review to an immutable commit, diff digest, or frozen plan, and classifies every proposal as keep, delete, defer, or remediate. - Remediation loop control: Treats remediated candidates as new candidates requiring re-review, never waving through unseen changes based on a passing test suite. - Use Case: A reviewer is asked to cut a 2,000-line diff down to 500 lines before release. The Skill audits each proposed deletion, rejects cuts that weaken trust-boundary controls, and emits a keep/delete/defer/remediate report tied to the exact snapshot reviewed. ## Quick Start Ask the AI to review this diff for overengineering and flag any proposed deletion that would weaken a safety or trust-boundary property.

Frequently Asked Questions about reviewing-overengineering

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I review a diff for overengineering without removing safety checks?

Run two passes: first identify duplicate logic, unused fields, and speculative abstractions, then challenge every proposed deletion against identity, consent, privacy, budget, and authority boundaries. Reject any deletion that weakens those properties even if tests pass.

How to tell accidental complexity from essential safety complexity in code review?

Classify each mechanism by the property it preserves. Essential safety complexity protects trust boundaries and must be kept; accidental complexity has an existing check that preserves behavior after removal; speculative functionality should be deferred with a concrete trigger for adding it later.

When should this complexity audit run in the development workflow?

It fires before a plan is accepted or a diff is merged when size, layer count, or abstraction budget is questioned, and whenever simplification pressure or a line-count target enters a review. It also re-reviews any remediation claiming simplification.

Does a passing test suite prove a simplification is safe?

No. Passing tests alone do not prove identity, consent, privacy, budget, or authority properties survived a deletion. The audit requires an independent safety-preservation rebuttal for every accepted deletion, separate from the producer's test results.

What are the limitations of a complexity audit versus a correctness review?

This audit targets complexity and deletion safety, not general correctness or continuous style advice. It also does not enumerate threats to a trust boundary; that belongs to a dedicated threat-modeling skill such as sdlc-threat-model.