Surgical Code Changes with Verifiable Goals
Plans and reviews code changes for hidden assumptions, overengineering, and scope creep, then ties each change to a pass/fail check.
Before & after
Same prompt, same agent — the only difference is the skill.
I can review your code and let you know if it's overcomplicated. I'd look at whether the changes are simpler than the original code or if you're adding unnecessary abstractions or patterns. It might help to know what problem you're trying to solve with these changes. Some code looks complex but is solving a real problem, while other code is complex for no reason. I could check if there are simpler ways to achieve the same goal, or if the code follows best practices for your language. It would also be useful to know if you've tested these changes. I'd recommend thinking about whether each line of code is earning its weight. Do you want me to focus on any particular part of the diff?
DISCIPLINED CODE REVIEW — DIFF CHECK ASSUMPTION SURFACED (before evaluating): You are: Optimizing a search filter for performance Problem: Current search takes 3 seconds on 100K records Goal: Sub-500ms response time Is that right? (if wrong, we miss the point of your diff) VERDICT: YOUR DIFF IS OVERCOMPLICATING THIS Original: Loop + filter + map (3 operations) Your diff: Custom B-tree index + cache layer + invalidation logic (12 files touched) SURGICAL CHANGE CRITIQUE You are solving a performance problem, not an architectural one First step: Add database index on search column (1 line SQL) Second step: If that's not enough, benchmark before caching Your diff adds caching + invalidation BEFORE measuring if either is needed Risk: Cache bugs, stale data, higher maintenance debt SIMPLE WINS FIRST (in priority order) 1. Add database index on search.term column (measure: drop to 600ms) 2. If still slow: Add query memoization (Claude can generate, 20 lines) 3. If still slow: Then consider your cache layer VERIFIABLE GOAL Before: "Make search faster" After: "Search under 500ms on 100K records, zero stale data" This diff: Doesn't have measurable rollback criteria RECOMMENDATION: Revert diff. Index the database. Remeasure. Then decide next step.
About this skill
Claude was asked to add a retry. It came back with a policy class, three config keys, a reformatted file, and a variable renamed across the codebase. The actual fix is buried in that noise, and nothing says how you'd know it works. This skill keeps every change as small as the problem and ties it to a check you can run.
What it does
- Builds a short assumption ledger before coding. Each item is tagged verified (with the file it came from), checkable (with the exact command), or a question for you.
- Turns vague requests like "caching works" or "fix the bug" into a falsifiable check: a command plus the expected result, with a failing test first for bugs.
- Labels every hunk of a pasted diff as required, supporting, out-of-scope, or speculative, then gives you the trimmed diff or an exact revert list.
- Cuts single-use abstractions, unrequested config, new dependencies, and error handling for states that can't happen. It searches for an existing project helper before writing a new one.
- Catches risky premises: tests made green by weakening assertions, caches missing a user or tenant key, "quick fixes" that change a public contract, and refactors mixed with features.
- Keeps unrelated problems in a "Noticed, not touched" list instead of editing them, and labels results UNVERIFIED unless it actually ran the check.
What you get
A verdict, the load-bearing assumptions, a runnable goal check, and either a minimal change or a hunk-by-hunk review with a trimmed diff. Questions come at the end, and only if they would change the code.
Best for
Developers using Claude Code who are tired of bloated diffs, reviewers checking AI-written PRs for scope creep, and anyone who wants a quick discipline pass before committing.
SKILL.md preview
---
name: surgical-code-changes
description: Plans, writes, and reviews code changes so every line traces to a stated goal. It surfaces load-bearing assumptions, cuts speculative abstractions and drive-by edits, and defines a pass/fail check before calling anything done. Use when the user says "review my diff", "am I overcomplicating this", "before I commit", "check this for scope creep", "keep this change minimal", "Claude keeps rewriting files I didn't ask it to touch", "my PR got way bigger than it should be", or "how do I know this fix actually works".
---
# Surgical Code Changes with Verifiable Goals
… (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.