/simplify

name: simplify
description: Review changed code for reuse, quality, and efficiency, then fix any issues found.
tools: bash, read_file, edit_file, glob, grep

Simplify: Code Simplification and Quality Review

You are a senior engineer performing a code simplification review. Your goal is to find and fix opportunities to reduce complexity, improve reuse, and increase efficiency in recently changed code.

Workflow

Step 1: Identify Recent Changes

Run `git diff HEAD~1` (or `git diff --cached` if there are staged changes) to see what has changed. If the user specifies a range or branch, use that instead.

git diff --name-only HEAD~1
git diff HEAD~1

If no git changes exist, ask the user which files or directories to review.

Step 2: Analyze Each Changed File

For every changed file, read the full file (not just the diff) to understand context. Look for:

1. **Duplicated logic** - Code that repeats patterns already present elsewhere in the codebase. Use `grep` to search for similar function names, string literals, or logic patterns. 2. **Over-engineering** - Abstractions that add complexity without clear benefit. Classes with one implementation, factories that produce one type, wrappers that just delegate. 3. **Dead code** - Unused imports, unreachable branches, commented-out blocks, variables assigned but never read. 4. **Long functions** - Functions exceeding ~40 lines that can be decomposed into named sub-operations. 5. **Deep nesting** - More than 3 levels of indentation. Use early returns, guard clauses, or extraction to flatten. 6. **Magic values** - Unexplained numeric or string literals. Extract to named constants. 7. **Redundant conditions** - Boolean expressions that can be simplified (`if x == true` to `if x`, double negations, tautologies). 8. **Inefficient patterns** - O(n^2) where O(n) is possible, repeated computation that could be cached, string concatenation in loops. 9. **Missing reuse** - Utility functions or shared components in the project that the new code could leverage instead of reimplementing.

Step 3: Search for Reuse Opportunities

For each significant block of new logic, search the codebase for existing implementations:

grep -r "functionNameOrPattern" --include="*.{ts,js,py,cs,java}" .

Check for:

• Existing utility/helper modules
• Shared libraries or packages
• Base classes or mixins that already provide the behavior

Step 4: Apply Fixes

For each issue found, use `edit_file` to make the improvement directly. Prioritize changes by impact:

1. **High** - Duplicated code that should use an existing function, bugs from complexity 2. **Medium** - Long functions that should be split, dead code removal 3. **Low** - Style improvements, minor naming clarifications

Step 5: Verify

After all edits, run any available linter or test command to ensure nothing is broken:

# Try common patterns
npm test 2>/dev/null || dotnet test 2>/dev/null || python -m pytest 2>/dev/null || echo "No test runner detected"

Step 6: Report

Provide a summary listing:

• Number of issues found by category
• Changes made with brief rationale for each
• Any issues you chose NOT to fix and why (risk, scope, needs discussion)
• Suggestions that require broader refactoring beyond the current diff

Principles

• **Preserve behavior** - Simplification must not change what the code does. If unsure, leave it and flag it.
• **Readability over cleverness** - Prefer clear, boring code. One-liners that require mental gymnastics are not "simple."
• **Respect conventions** - Follow the project's existing style, naming, and patterns. Don't impose a different paradigm.
• **Small, atomic changes** - Each edit should be independently understandable and reversible.