lean-review

Reviews diffs or repositories for over-engineering and returns a one-line-per-finding delete list.

Updated Sep 17, 2026
One-click install
npx skills add https://github.com/karenrebecag/spec-driven-standards --skill lean-review-karenrebecag
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: lean-review
Source: https://github.com/karenrebecag/spec-driven-standards/tree/main/plugins/standards/skills/lean-review
Command: npx skills add https://github.com/karenrebecag/spec-driven-standards --skill lean-review-karenrebecag

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Code reviews often focus on correctness and security while accumulated complexity, dead code, and speculative abstractions slip through. This Skill audits a diff or an entire repository purely for over-engineering and outputs a concrete delete-list instead of vague suggestions. ## Core Features & Use Cases - Complexity-only audit: Flags dead code, hand-rolled stdlib equivalents, unnecessary dependencies, single-implementation abstractions, and shrinkable logic using five tags: delete, stdlib, native, yagni, shrink. - Scoped scanning: Reviews the working git diff by default, or the whole repository ranked biggest cut first when asked. - Decision-ready output: One line per finding with file, line, what to cut, and its replacement, ending with a net line-count metric. - Use Case: After a large feature branch, ask for an over-engineering review and receive lines like "L12-38: stdlib: 27-line validator class. Regex + confirmation mail already covers it, 1 line." so you can cut before merging. ## Quick Start Ask the assistant to review the current git diff for over-engineering and list what can be deleted.

Frequently Asked Questions about lean-review

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

FAQPage Schema
How do I review a git diff for over-engineering?

Run the review against your working diff by default, or name a staged or branch diff explicitly. The output is one line per finding with the location, what to cut, and what replaces it, ending with a net line-count estimate.

What kinds of code bloat does an over-engineering review find?

It flags five categories: dead code and speculative features (delete), hand-rolled logic the standard library ships (stdlib), dependencies duplicating platform features (native), abstractions with one implementation (yagni), and logic expressible in fewer lines (shrink).

Can I scan a whole repository for unnecessary complexity?

Yes, say "repo" or "whole codebase" to scan the entire tree instead of the diff. Findings are ranked biggest cut first, always include file paths, and the summary adds a dependency reduction count.

Does this review also catch bugs or security issues?

No, correctness, security, and performance are explicitly out of scope and routed to code-reviewer or security-reviewer. Tests, file count, house patterns like repository interfaces, and explanatory comments are also never flagged.

Does the review apply the suggested deletions automatically?

No, it only lists findings and stops. The user decides what to cut; the skill never edits code or continues into fixes after reporting.