Code Simplifier

Purpose

Refine code for clarity, consistency, and maintainability while preserving exact functionality.

This skill improves how code is written, not what it does.

Default scope

• Refactor only code that was recently modified/touched in the current session (diff/edited files/lines).
• Expand scope only if the user explicitly requests it.

Non-negotiables

Preserve behavior (always)

Do not change:

• outputs, side effects, observable performance characteristics that are relied upon, or public APIs
• error behavior (what fails, what returns, user-visible messages/types) unless explicitly requested
• data formats, serialization, ordering, timing semantics (when relevant)

If you can’t be confident behavior is unchanged, ask for expected behavior/tests.

Follow project standards (always)

• If CLAUDE.md exists, treat it as the source of truth.
• Otherwise, follow repository conventions (lint/format, naming, patterns, directory structure).

Clarity heuristics (language-agnostic)

Prefer:

• reducing nesting (guard clauses / early returns / extracting helpers when it clarifies intent)
• removing redundant code, dead code, and unnecessary abstractions
• improving naming to make intent obvious (variables, functions, types)
• keeping functions/components/modules single-purpose
• comments that explain why (rationale), not what (obvious mechanics)

Hard rule:

• Avoid nested ternary operators (or equivalent “dense inline branching” patterns). Prefer clear multi-branch constructs (if/else, switch, pattern matching, or well-named helpers).

Balance: what not to do

Avoid “simplifications” that:

• create clever/dense code that’s harder to read (one-liners, tricky short-circuiting, overly abstracted pipelines)
• over-DRY into abstractions that hide intent
• merge multiple concerns into one function/module
• prioritize fewer lines over maintainability
• reduce debuggability (harder breakpoints/stack traces) without strong reason

When CLAUDE.md specifies language/framework rules

Apply them exactly. Examples of project-standard rules you might see:

• import/module conventions (e.g., ES modules, import sorting, extensions)
• “prefer function over arrow functions”
• explicit return types for exported/top-level functions (TypeScript)
• framework component patterns (React/Vue/etc.) and explicit props types
• error handling patterns (“avoid try/catch when possible”, etc.)

Treat these as conditional: enforce them only if they are part of the project’s standards.

Workflow

1. Identify the refactor target
   • Use the diff/changed files or user-provided snippet to locate recently modified code.
2. Read surrounding context
   • Match nearby patterns and repo conventions.
3. Refine
   • Apply small, safe transformations that improve readability and consistency.
4. Sanity-check behavior preservation
   • Re-check edge cases, error paths, and types/contracts.
5. Report
   • Summarize only changes that affect understanding (not every mechanical edit).

Output expectations

When producing changes:

• Prefer a patch/diff or clearly delimited “before/after” blocks.
• Provide a short change summary focused on readability/consistency.
• State that behavior is intended to be unchanged, and note any assumptions + what to verify.