# Code Simplifier

> Simplifies and refines recently modified code for clarity, consistency, and maintainability while preserving exact functionality.

- Skill: `munlucky/code-simplifier` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add munlucky/code-simplifier`
- Raw SKILL.md: https://api.skillmd.com/api/skills/munlucky/code-simplifier/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: munlucky (https://skillmd.com/u/munlucky)
- Updated: 2026-09-10
- Page: https://skillmd.com/skills/munlucky/code-simplifier

---


# Code Simplifier

## Role

Run after implementation and before final verification or review when the change set would benefit from a clarity pass.

This skill is workflow-integrated, but it may also be invoked directly for an explicit simplification pass.

## Core Contract

- preserve exact behavior
- work primarily on recently modified code
- prefer clarity over brevity
- ask whether a non-trivial change has a simpler, more elegant shape before verification
- reduce unnecessary complexity, nesting, and duplication
- follow repository coding standards and established patterns
- avoid clever rewrites that make debugging harder

## What To Improve

- redundant branches, wrappers, and abstractions
- shallow pass-through modules that fail the deletion test
- overly dense expressions and nested ternaries
- names that obscure intent
- repeated logic that can be consolidated safely
- comments that restate obvious code
- inconsistent structure inside recently touched modules
- module locality when a small interface can hide repeated implementation complexity
- hacky patches that can be replaced by a smaller change aligned with the existing design

## What Not To Do

- do not widen scope beyond recently modified files unless explicitly asked
- do not change external behavior, data contracts, or side effects
- do not compress code into dense one-liners
- do not remove useful abstractions that improve module boundaries
- do not introduce a new abstraction unless it improves locality, leverage, or testability
- do not rename domain terms away from the project glossary without updating the glossary or surfacing the conflict
- do not force an elegance pass for trivial one-line or obviously correct fixes; record the skip reason when the orchestrator requires evidence

## Balanced Elegance Check

For non-trivial behavior or architecture changes:

1. Identify the smallest behavior-preserving cleanup that reduces future confusion.
2. Prefer existing local patterns over new abstractions.
3. Replace visibly hacky fixes when a clear elegant path is already known.
4. Stop when further cleanup would widen scope or change behavior.

## Suggested Workflow Position

Typical placement:

1. `implementation-runner`
2. `code-simplifier`
3. `completion-verifier`
4. `codex-review-code`

## Output

- refined code with unchanged behavior
- short note only when a simplification materially changes readability or structure