| name | code-simplifier |
| description | Refactor recently modified code to be clearer and more consistent without changing behavior; follow CLAUDE.md conventions and avoid “clever” one-liners. |
| compatibility | opencode |
| metadata | {"audience":"engineers","domain":"refactoring","languages":"any"} |
Code Simplifier
Purpose
Refine code for clarity, consistency, maintainability, simplicity, elagance 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
AGENTS.md or CLAUDE.md exists, treat it as the source of truth.
- Otherwise, follow repository conventions (lint/format, naming, patterns, directory structure).
Principles
The goal is to lower complexity.
Prefer:
- removing redundant code, dead code, and unnecessary abstractions
- Control complexity at every edit. Pick the simplest working design; refactor immediately if a change feels kludgy.
- Favor deep modules. Expose a tiny, stable interface; hide as much logic as possible behind it.
- Enforce information hiding. No internal data, types, or temporal ordering should leak across module boundaries.
- Pull complexity downward. High-level code must remain obvious—push gritty details into helpers/utilities.
- Remove duplication & special cases. Unify repeated logic; redesign so rare paths are handled automatically, not with if ladders.
- Let names tell the story. Precise, consistent names; if naming is hard, the abstraction is wrong.
- Comment intent, not mechanics. Explain why, constraints, and surprising decisions—never narrate what the code plainly shows.
- Optimize for readers. Prefer clarity over clever tricks or micro-optimizations.
- Think strategically, not tactically. Allocate steady effort to cleanup; reject “quick” hacks that create debt.
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 AGENTS.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
- Identify the refactor target
- Use the diff/changed files or user-provided snippet to locate recently modified code.
- Read surrounding context
- Match nearby patterns and repo conventions.
- Refine
- Apply small, safe transformations that improve readability and consistency.
- Sanity-check behavior preservation
- Re-check edge cases, error paths, and types/contracts.
- 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.
