Code simplify

Skill helderberto/agent-skills/skills/code-simplify

Simplify working code without changing behavior — reduce complexity, remove dead abstractions, favor clarity over cleverness. Use when code works but is harder to read or maintain than it should be, or the user asks to "simplify", "clean up", "reduce complexity", or "make this clearer". Don't use to add features or backfill tests (use /tdd or /fortify), design a new interface (use /codebase-design), or review a PR (use /code-review).From its SKILL.md

Install

npx -y skills add helderberto/agent-skills --skill code-simplify

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

12 stars12 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.

SKILL.md

3.4 KB, 704 tokens by cl100k_base, as published. Nobody here has run it

Code Simplify

Make working code clearer without changing what it does. Clarity over cleverness. Behavior is frozen — the test suite is the contract. Applies to frontend and backend equally.

Target: $ARGUMENTS (file, directory, or module — if blank, use unstaged changes)

Guardrails

Chesterton's Fence — before removing anything, explain why it's there. If you can't, leave it and flag it. Never delete guards, checks, or branches you don't understand.
Behavior is frozen — no functional changes. Green test suite before and after; if a test's meaning has to change, you've gone too far.
Clarity over cleverness — a junior should read it without decoding. Prefer boring and obvious.

Workflow

1. Baseline

Identify target files (blank → unstaged changes)
Run the test suite. If red, stop — don't simplify broken code
If a target has no tests, flag it: simplification is unverifiable without them (offer /fortify)

2. Audit

List findings, most-impactful first:

Smell	Simplification
Deep nesting (> 2 levels)	Guard clauses / early return
Dead code, unused params, unreachable branches	Delete (after Chesterton's Fence)
Duplicated logic	Extract one named helper
Clever one-liners, dense ternaries	Expand to readable form
Shallow pass-through wrapper	Inline it (`/codebase-design` — the deletion test)
Speculative flexibility / config never used	Remove
Unclear names, primitive obsession	Rename to intent

Present the audit. Ask which items to apply — list each as an option, "All items" first and marked (Recommended). Use AskUserQuestion (multiSelect) when available; otherwise a numbered checklist.

3. Apply — one change at a time

Per approved item:

Make the single change
Run tests — must stay green
If red → revert that change, flag as blocked

Never batch. Use immutable edits — introduce no new mutation.

4. Report

## Simplify Report

### Applied
- Flattened `parseConfig` — 4 nesting levels → guard clauses
- Deleted unused `legacyMode` param (Chesterton: git blame shows the feature was removed)
- Inlined `wrapResult` pass-through (deletion test: complexity vanished)

### Skipped / Blocked
- `retryLoop` — kept the sleep; couldn't confirm why (Chesterton's Fence)

### Result
Tests: 42 passed | 0 failed | behavior unchanged

Relationship to neighbors

Depth framing — reach for /codebase-design vocabulary (deletion test, shallow module) when a simplification is really an interface question.
Splitting God functions or backfilling coverage → /fortify (it changes structure and adds tests; this skill only removes complexity).
Restructuring across modules → /architecture-audit.

Rules

Never change external behavior — simplification is internal only
Every removal passes the Chesterton's Fence test or gets flagged, not deleted
Skip files with no test infrastructure unless the user opts in

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.

Gives 1 of the 12 instructions most refactoring skills give in 704 tokens

Counted across 545 of the 587 authors here whose files we hold, read 2026-09-06

Run tests after each changein 61 of 545, across 59 files
Run tests before refactoringin 42 of 545
Revert immediately if tests failhere, and in 31 of 545, across 28 files
Perform refactoring in small stepsin 30 of 545, across 29 files
Write characterization tests for untested codein 21 of 545, across 19 files
Remove dead code and unused importsin 20 of 545
Identify code smellsin 20 of 545
Perform one refactoring at a timein 19 of 545
Commit after each successful refactoringin 17 of 545, across 15 files
Verify all tests pass after refactoringin 17 of 545
Keep refactoring separate from behavior changesin 16 of 545, across 14 files
Run the full test suitein 16 of 545

Said here and by no other author read

Explain why code exists before removing it
Verify tests remain green after each change
Present an audit of findings before applying changes
Rename variables to reflect intent
Expand dense one-liners into readable forms
Flag files lacking test coverage

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.