Overbuild & Scope Creep Diff Review
Review a finished diff against what was asked: cut scope creep, speculative abstractions, silent assumptions, and hollow tests.
Before & after
Same prompt, same agent — the only difference is the skill.
I'd be happy to review your auth middleware PR. Here's what I'd generally look at: - **Correctness**: Does the logic handle all cases, including edge cases? - **Security**: Are there any vulnerabilities, especially for auth code? - **Error handling**: Are errors handled gracefully? - **Testing**: Is there adequate test coverage? - **Readability**: Is the code clear and maintainable? - **Performance**: Any inefficiencies? For auth middleware specifically, I'd pay close attention to token validation, session handling, and how failures are handled (failing open vs. closed). Please share the code and I'll give you specific feedback.
Structured review — findings first, ranked by severity, each with the
specific failure it causes. Coverage over politeness: I report
everything and let you filter.
BLOCKING
▸ auth.middleware.ts:34 — fails OPEN on token-parse error
catch block logs and calls next(). A malformed token now passes
the middleware. Auth must fail CLOSED — any error is a 401, not a
pass-through. This is the finding that makes the PR unmergeable.
→ return res.status(401) in the catch, not next().
SHOULD-FIX
▸ :52 — timing-safe comparison missing
Token compared with ===. Vulnerable to timing analysis. Use a
constant-time compare (crypto.timingSafeEqual).
▸ :67 — no expiry check after signature verify
Signature is validated; exp is never read. A valid-but-expired
token is accepted. Verify exp explicitly.
CONSIDER
▸ :19 — the refactor moved token extraction into a helper but left
the old inline path at :44 unreachable. Dead code, delete it.
▸ Tests cover the happy path only. No test for: malformed token,
expired token, missing header. Given the fail-open bug above, the
missing-malformed-token test is the one that would have caught it.
NON-BLOCKING NITS (listed, not weighted)
▸ :28 variable name "t" — spell it out
▸ :71 magic number 3600 — name it
WHAT'S GOOD
The extraction into a single validation path is the right structure and
makes the two security fixes above easy to apply in one place. The bones
are correct; it's the failure-mode handling that's wrong.
VERDICT
Block on the fail-open (:34). Everything else can land in a follow-up,
but I'd fix the two security items in the same PR since the code is
already open. Want the fail-closed patch written?About this skill
AI-written and rushed changes tend to do more than they were asked to. This review checks every hunk against the original request and gives you a concrete list of cuts that makes the diff smaller and safer to merge.
What it does
- Pins down the goal from the ticket, PR description, or your instruction before judging anything
- Classifies each hunk as required, supporting, unrequested, or risky unrequested
- Flags speculative abstractions, unrequested dependencies and API changes, and hard-coded decisions nobody made
- Catches hollow tests: ones that pass without the change, assert on mocks, or were edited to go green
- Splits oversized diffs before reviewing them
What you get
A verdict, a cut list with actions and rough line savings, simplifications, assumptions to confirm with the requester, and test gaps.
Best for
Developers and reviewers merging Claude Code or other AI-assisted changes, and teams fighting PR bloat.
SKILL.md preview
---
name: overbuild-diff-review
description: Review a finished diff or pull request for the problems AI-written and rushed changes share - scope creep beyond the request, speculative abstractions, unrequested refactors and dependencies, silent assumptions baked into code, and tests that do not prove the change - and return a cut list that makes the diff smaller. Use when the user says "review this diff for overengineering", "did you change more than I asked?", "is this PR bloated?", "what can we cut from this change?", "check Claude's changes before I merge", or casually "this feels like too much code" or "simplify this PR".
---
# Overbuild Diff Review
… (sign up to view the full skill)More development skills
View all Development skills →Performance Bottleneck Profiling: Node, Python, Go
Classifies a slowdown, gives exact profiler commands, reads the output, and proves the fix with same-conditions p95/p99 numbers.
Feature Scaffolding with Working Tests
Turn a short feature spec into code, runnable tests, and integration wiring that match your existing project.
Feature Flag Rollouts and Kill Switches
Design staged flag rollouts, verify rollback paths, and audit flag debt with explicit defaults, gates, and retirement plans.
Microcontroller Firmware and RTOS Engineering
Build and debug MCU firmware with bounded ISR/RTOS timing, safe DMA ownership, and measured power budgets.