code-simplifier

name	code-simplifier
description	Analyzes recently modified code and creates pull requests with simplifications that improve clarity, consistency, and maintainability while preserving functionality

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:

1. Read the file contents
2. 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
3. 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:

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