Code simplifier
Skill yidasanqian/codex-code-simplifier/plugins/code-simplifier/skills/code-simplifier
Codex plugin for simplifying recent code changes without changing behavior
npx -y skills add yidasanqian/codex-code-simplifier --skill code-simplifierAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Use when Codex should simplify, refactor, or clean up recently modified code while preserving exact behavior, especially after an implementation session, before commit, or when code has become overly complex, duplicated, deeply nested, or inconsistent with project conventions.
SKILL.md
2.7 KB, as published. Nobody here has run it
Code Simplifier
Use this skill to refine code for clarity, consistency, and maintainability without changing what it does.
Scope
- Focus on files changed in the current session or the user's explicitly named files.
- Preserve all behavior, public APIs, outputs, data formats, and side effects.
- Follow the nearest
AGENTS.mdand existing project style before applying general preferences. - Keep changes surgical. Do not refactor unrelated old code.
- Prefer readable, explicit code over clever or highly compressed code.
Workflow
- Inspect the current diff and nearby code before editing.
- Identify simplifications with a clear payoff:
- reduce unnecessary nesting or branching
- remove duplication introduced by recent edits
- inline single-use abstractions that obscure intent
- split code only when it creates a clearer boundary
- improve names when they clarify purpose
- remove comments that only repeat obvious code
- Skip changes that are only stylistic, risky, or hard to prove behavior-preserving.
- Apply the smallest coherent patch.
- Run the narrowest relevant verification command. Broaden verification when shared behavior changed.
- Report what changed and what was verified.
Guardrails
- Do not add features, options, new dependencies, or speculative flexibility.
- Do not change error messages, serialization, ordering, timing, permissions, or external calls unless the user asked.
- Do not convert clear conditionals into nested ternaries or dense one-liners.
- Do not remove helpful abstractions just to reduce line count.
- Do not rewrite an entire module when a local simplification is enough.
- Do not claim behavior is preserved without fresh verification evidence.
Good Targets
| Signal | Useful Simplification |
|---|---|
| Repeated blocks from recent edits | Extract or consolidate only the repeated intent |
Deep if nesting | Use early returns or clearer branching |
| Temporary variables with unclear names | Rename to describe domain meaning |
| Single-use wrapper function | Inline it if it hides more than it helps |
| Comments narrating code | Remove or replace with a reason-oriented comment |
Stop Conditions
Stop and ask before editing when behavior preservation depends on product intent, undocumented compatibility, or unclear external contracts. If verification cannot be run, say exactly what was not verified.
Gives 0 of the 12 instructions most refactoring skills give
Counted across 521 of the 525 authors here whose files we hold, read 2026-08-06
- run tests after each changein 59 of 521, across 56 files
- write tests before refactoringin 27 of 521, across 24 files
- preserve external behaviorin 26 of 521, across 22 files
- remove dead codein 25 of 521, across 24 files
- make small incremental changesin 20 of 521, across 17 files
- break the implementation into tiny commitsin 18 of 521, across 5 files
- ask the user about alternative optionsin 17 of 521, across 4 files
- create a GitHub issue with the planin 17 of 521, across 4 files
- explore the repository to verify assertionsin 17 of 521, across 4 files
- interview the user about the refactorin 16 of 521, across 3 files
- check the codebase for test coveragein 16 of 521, across 3 files
- refactor one thing at a timein 16 of 521, across 12 files
Said here and by no other author read
- focus only on changed or named files
- follow nearest agents file and project style
- keep changes surgical
- inspect the diff and nearby code before editing
- apply the smallest coherent patch
- run the narrowest verification command
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once.