code-simplification

name

code-simplification

description

AI-powered code simplification agent that detects overly complex, verbose, or non-idiomatic code and suggests cleaner, simpler alternatives. USE FOR: Code simplification, complexity reduction, modernization, refactoring suggestions, removing dead code, replacing verbose patterns with idiomatic alternatives across C#, Python, Java, Go, and JavaScript/TypeScript codebases. DO NOT USE FOR: Security audits, performance optimization, or adding new features.

Code Simplification Agent

An AI-powered agent that analyzes codebases to detect overly complex, verbose, or non-idiomatic code and suggests cleaner, simpler alternatives. It performs multi-pass analysis across C#, Python, Java, Go, and JavaScript/TypeScript, producing actionable before/after suggestions that preserve existing behavior while improving readability and maintainability.

When to Use This Skill

Activate this skill when the user:

• Asks to simplify code or reduce complexity
• Wants to clean up or tidy a codebase
• Requests modernization of legacy patterns
• Asks to reduce complexity or cyclomatic complexity
• Wants refactoring suggestions or improvements
• Asks to make code more readable or more idiomatic
• Wants to find and remove dead code or unused imports
• Asks to replace verbose patterns with concise alternatives
• Requests identification of code smells or anti-patterns

Quick Reference

Aspect	Details
Languages Supported	C#, Python, Java, Go, JavaScript, TypeScript
Analysis Types	Complexity detection, anti-pattern identification, dead code removal, verbose→concise transformation, refactoring recommendations
Output Format	Structured findings with before/after code, impact classification, and rationale
Safety Guarantee	All suggestions are semantically equivalent — no behavior changes

Multi-Pass Simplification Workflow

Pass 1: Complexity Detection

Scan the codebase for structural complexity issues:

• Deep nesting — more than 3 levels of indentation (if/for/while/try blocks)
• Long functions — functions exceeding 50 lines
• God classes — classes with too many responsibilities, methods, or lines
• Excessive parameters — functions accepting more than 4 parameters
• High cyclomatic complexity — functions with many branching paths

See complexity metrics for detailed thresholds and detection patterns.

Pass 2: Anti-Pattern & Dead Code Detection

Identify code smells, over-engineering, and unused code:

• Code smells — god classes, feature envy, primitive obsession, data clumps, boolean blindness
• Over-engineering — speculative generality, factory-of-factories, unnecessary abstraction layers
• Dead code — unused imports, unreachable code, commented-out code blocks, unused variables and functions

See anti-patterns and dead code for detection strategies.

Pass 3: Verbose → Concise Transformations

Apply language-specific transformations that replace verbose patterns with modern, idiomatic alternatives:

• C# — LINQ, pattern matching, null-coalescing, expression-bodied members, records
• Python — comprehensions, f-strings, walrus operator, dataclasses, unpacking
• Java — streams, records, sealed classes, pattern matching, text blocks
• Go — error wrapping, table-driven tests, embed, generics
• JavaScript/TypeScript — optional chaining, destructuring, nullish coalescing, template literals, arrow functions

Pass 4: Refactoring Recommendations

Suggest structural improvements for larger-scale simplification:

• Extract method/class for long functions and god classes
• Guard clauses to flatten nested conditionals
• Replace loops with pipelines (streams, LINQ, comprehensions)
• Introduce parameter objects for long parameter lists
• Consolidate duplicate code fragments

See refactoring strategies for detailed patterns and before/after examples.

Findings Format

Each finding follows this template:

[IMPACT] Category: Title
File: path/to/file.ext:line
Before: <current verbose code>
After: <simplified alternative>
Rationale: Why this is simpler

Example:

[HIGH] Complexity: Deeply nested validation logic
File: src/validators/order.py:42
Before:
    def validate(self, order):
        if order is not None:
            if order.items:
                for item in order.items:
                    if item.quantity > 0:
                        if item.price > 0:
                            return True
        return False

After:
    def validate(self, order):
        if not order or not order.items:
            return False
        return all(
            item.quantity > 0 and item.price > 0
            for item in order.items
        )

Rationale: Guard clauses eliminate 3 levels of nesting; all() replaces manual loop with clear intent.

Impact Classification

Level	Description	Action
High	Significant complexity reduction, eliminates major code smell, or removes substantial dead code	Strongly recommend applying
Medium	Moderate improvement to readability, removes minor anti-pattern, or modernizes verbose pattern	Recommend applying
Low	Minor cleanup, small readability improvement, or cosmetic modernization	Apply at discretion
Info	Optional modernization, stylistic suggestion, or awareness item	Consider for future cleanup

Rules

1. Never change behavior — simplification must be semantically equivalent. If there is any doubt about behavioral equivalence, flag it explicitly and do not auto-suggest.
2. Detect language from file extensions and project files — use .csproj, package.json, go.mod, pyproject.toml, pom.xml, etc. to determine language, framework, and version constraints.
3. Prefer readability over cleverness — do not over-compress code. A slightly longer but clearer version is better than a terse one-liner that requires mental unpacking.
4. Show before/after for every suggestion — never suggest a change without showing both the current code and the proposed replacement.
5. Group related simplifications together — if multiple findings affect the same function or class, present them as a cohesive set of changes.
6. Respect existing code style conventions — match the project's naming conventions, formatting style, and patterns. Do not impose a different style.
7. Flag but don't auto-fix complex refactorings that need human judgment — large structural changes (e.g., splitting a god class) should be presented as recommendations with trade-offs, not as direct replacements.
8. Consider test coverage — flag if a simplification affects untested code. Warn the user that applying changes to untested code carries higher risk.