Code Simplifier

Code Simplifier Skill

Expert guidance for analyzing and simplifying recently modified code to improve clarity, consistency, and maintainability while preserving exact functionality.

Overview

This skill enables agents to:

• Analyze code changes from the last 24 hours
• Apply targeted simplifications that improve code quality
• Create pull requests with improvements
• Validate changes through tests and linting

When to Use This Skill

Use this skill when:

• User asks to simplify or refactor recent code changes
• User wants to improve code quality without changing functionality
• User requests code review with automatic improvements
• Scheduled code quality checks are needed

Simplification Principles

1. Preserve Functionality

• NEVER change what the code does - only how it does it
• All original features, outputs, and behaviors must remain intact
• Run tests before and after to ensure no behavioral changes

2. Enhance Clarity

• Reduce unnecessary complexity and nesting
• Eliminate redundant code and abstractions
• Improve readability through clear variable and function names
• Consolidate related logic
• Remove unnecessary comments that describe obvious code
• IMPORTANT: Avoid nested ternary operators - prefer switch statements or if/else chains
• Choose clarity over brevity - explicit code is often better than compact code

3. Apply Project Standards

• Use project-specific conventions and patterns
• Follow established naming conventions
• Apply consistent formatting
• Use appropriate language features (modern syntax where beneficial)

4. Maintain Balance

Avoid over-simplification that could:

• Reduce code clarity or maintainability
• Create overly clever solutions that are hard to understand
• Combine too many concerns into single functions
• Remove helpful abstractions that improve code organization
• Prioritize "fewer lines" over readability
• Make the code harder to debug or extend

Workflow

Phase 1: Identify Recently Modified Code

1.1 Find Recent Changes

Identify files modified in the last 24 hours from all sources:

Option A: Local File Changes (filesystem-based)

# Find files modified in the last 24 hours (includes uncommitted changes)
find . -type f -mtime -1 -not -path './.git/*' -not -path './node_modules/*' -not -path './vendor/*'

# Or using git to find modified files (staged and unstaged)
git status --porcelain

# Find recently modified tracked files
git diff --name-only HEAD~10  # Adjust based on commit frequency

Option B: Git History (committed changes)

# Get yesterday's date in ISO format
YESTERDAY=$(date -d '1 day ago' '+%Y-%m-%d' 2>/dev/null || date -v-1d '+%Y-%m-%d')

# List recent commits
git log --since="24 hours ago" --pretty=format:"%H %s" --no-merges

# List files changed in recent commits
git log --since="24 hours ago" --name-only --pretty=format:"" | sort -u

Option C: GitHub PRs and Commits (remote changes)

Use GitHub tools to:

• Search for pull requests merged in the last 24 hours
• Get details of merged PRs to understand what files were changed
• List commits from the last 24 hours to identify modified files

Combine all sources to get a comprehensive list of recently modified files.

1.2 Extract Changed Files

From all identified sources (local changes, commits, PRs):

• Collect files modified on the filesystem in the last 24 hours
• List changed files from recent commits
• List changed files from merged PRs
• Deduplicate the combined file list
• Focus on source code files (.go, .js, .ts, .tsx, .jsx, .py, .rb, .java, .cs, .php, .cpp, .c, .rs, etc.)
• Exclude test files, lock files, generated files, and vendored dependencies

# Example: Combine filesystem and git changes, filter source files
{
  find . -type f -mtime -1 -not -path './.git/*' 2>/dev/null
  git log --since="24 hours ago" --name-only --pretty=format:"" 2>/dev/null
  git diff --name-only 2>/dev/null
} | sort -u | grep -E '\.(go|js|ts|tsx|jsx|py|rb|java|cs|php|cpp|c|rs)$'

1.3 Determine Scope

If no files were changed in the last 24 hours (no local modifications, no commits, no merged PRs), exit gracefully:

✅ No code changes detected in the last 24 hours.
Code simplifier has nothing to process today.

If files were changed (from any source: local edits, commits, or PRs), proceed to Phase 2.

Phase 2: Analyze and Simplify Code

2.1 Review Project Standards

Before simplifying, review the project's coding standards:

• Check for style guides, coding conventions, or contribution guidelines
• Look for language-specific conventions (STYLE.md, CONTRIBUTING.md, README.md)
• Identify established patterns in the codebase

2.2 Perform Code Analysis

For each changed file:

• Read the file contents
• Identify refactoring opportunities:
• Long functions that could be split
• Duplicate code patterns
• Complex conditionals that could be simplified
• Unclear variable names
• Missing or excessive comments
• Non-idiomatic patterns
• Design the simplification:
• What specific changes will improve clarity?
• How can complexity be reduced?
• What patterns should be applied?
• Will this maintain all functionality?

2.3 Apply Simplifications

Make surgical, focused changes that preserve all original behavior. Use targeted edits rather than full file rewrites.

Phase 3: Validate Changes

3.1 Run Tests

After making simplifications, run the project's test suite:

# Common test commands (adapt to the project)
make test          # If Makefile exists
npm test           # For Node.js projects
pytest             # For Python projects
./gradlew test     # For Gradle projects
mvn test           # For Maven projects
cargo test         # For Rust projects
go test ./...      # For Go projects

If tests fail:

• Review the failures carefully
• Revert changes that broke functionality
• Adjust simplifications to preserve behavior
• Re-run tests until they pass

3.2 Run Linters

Ensure code style is consistent:

# Common lint commands (adapt to the project)
make lint          # If Makefile exists
npm run lint       # For Node.js projects
pylint . || flake8 . # For Python projects
cargo clippy       # For Rust projects
golangci-lint run  # For Go projects

Fix any linting issues introduced by the simplifications.

3.3 Check Build

Verify the project still builds successfully:

# Common build commands (adapt to the project)
make build         # If Makefile exists
npm run build      # For Node.js projects
./gradlew build    # For Gradle projects
mvn package        # For Maven projects
cargo build        # For Rust projects
go build ./...     # For Go projects

Phase 4: Create Pull Request

4.1 Determine If PR Is Needed

Only create a PR if:

• ✅ Actual code simplifications were made
• ✅ All tests pass (or no tests exist)
• ✅ Linting is clean (or no linter configured)
• ✅ Build succeeds (or no build step exists)
• ✅ Changes improve code quality without breaking functionality

If no improvements were made or changes broke tests, exit gracefully:

✅ Code analyzed from last 24 hours.
No simplifications needed - code already meets quality standards.

4.2 Generate PR Description

Use this structure for the PR:

## Code Simplification - [Date]

This PR simplifies recently modified code to improve clarity, consistency, and maintainability while preserving all functionality.

### Files Simplified

- `path/to/file1.ext` - [Brief description of improvements]
- `path/to/file2.ext` - [Brief description of improvements]

### Improvements Made

1. **Reduced Complexity**
   - [Specific example]

2. **Enhanced Clarity**
   - [Specific example]

3. **Applied Project Standards**
   - [Specific example]

### Changes Based On

Recent changes from:
- #[PR_NUMBER] - [PR title]
- Commit [SHORT_SHA] - [Commit message]

### Testing

- ✅ All tests pass (or indicate if no tests exist)
- ✅ Linting passes (or indicate if no linter configured)
- ✅ Build succeeds (or indicate if no build step)
- ✅ No functional changes - behavior is identical

### Review Focus

Please verify:
- Functionality is preserved
- Simplifications improve code quality
- Changes align with project conventions
- No unintended side effects

---

*Automated by Code Simplifier Agent*

Common Simplification Patterns

Reduce Nesting

// Before
func process(data []Item) error {
    if data != nil {
        if len(data) > 0 {
            for _, item := range data {
                if item.Valid {
                    // process
                }
            }
        }
    }
    return nil
}

// After
func process(data []Item) error {
    if len(data) == 0 {
        return nil
    }
    for _, item := range data {
        if !item.Valid {
            continue
        }
        // process
    }
    return nil
}

Replace Nested Ternaries with Switch/If

// Before
const status = isError ? 'error' : isLoading ? 'loading' : isSuccess ? 'success' : 'idle';

// After
let status;
if (isError) {
    status = 'error';
} else if (isLoading) {
    status = 'loading';
} else if (isSuccess) {
    status = 'success';
} else {
    status = 'idle';
}

Consolidate Related Logic

# Before
def validate_user(user):
    if user.name is None:
        return False
    if len(user.name) == 0:
        return False
    if user.email is None:
        return False
    if '@' not in user.email:
        return False
    return True

# After
def validate_user(user):
    if not user.name:
        return False
    if not user.email or '@' not in user.email:
        return False
    return True

Improve Variable Names

// Before
func calc(d []int) int {
    t := 0
    for _, v := range d {
        t += v
    }
    return t
}

// After
func calculateSum(values []int) int {
    total := 0
    for _, value := range values {
        total += value
    }
    return total
}

Scope Control Guidelines

• Focus on recent changes: Only refine code modified in the last 24 hours (local files, commits, or merged PRs)
• Include all change sources: Consider filesystem modifications, staged changes, commits, and merged PRs
• Don't over-refactor: Avoid touching unrelated code
• Preserve interfaces: Don't change public APIs
• Incremental improvements: Make targeted, surgical changes

Exit Conditions

Exit gracefully without creating a PR if:

• No code was changed in the last 24 hours
• No simplifications are beneficial
• Tests fail after changes
• Build fails after changes
• Changes are too risky or complex

Quality Checklist

Before creating a PR, verify:

• [ ] Functionality is preserved (all tests pass)
• [ ] Code is clearer and more readable
• [ ] No nested ternary operators introduced
• [ ] Variable names are descriptive
• [ ] Unnecessary complexity removed
• [ ] Project conventions followed
• [ ] Build succeeds
• [ ] Linting passes
• [ ] Changes are focused and surgical

Output Requirements

The agent MUST either:

• If no changes in last 24 hours: Output a brief status message
• If no simplifications beneficial: Output a brief status message
• If simplifications made: Create a PR with the changes and detailed description