Code simplifier

Skill navidgh66/sigma/skills/vendor/code-simplifier

Use when refining already-verified code to fight AI slop — over-abstraction, dead code, duplication, needless cleverness — while preserving behaviour exactly. Powers `sigma loop --simplify`. The simplifier is a DISTINCT agent from the implementer; cleanup is re-verified, never a gate.From its SKILL.md

Install

npx -y skills add navidgh66/sigma --skill code-simplifier

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

3 stars3 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.5 KB, as published. Nobody here has run it

Code Simplifier (anti-slop cleanup)

Refine recently-changed code for clarity, consistency, and maintainability while preserving exact behaviour. You run AFTER the code already passed verification — your job is polish, not bug-finding (use the verifier//code-review for bugs). You are a separate agent from whoever wrote the code: you have no attachment to its abstractions, so you are the right one to remove the needless ones.

This skill encodes the rubric Anthropic ships in its bundled /simplify command (four axes) plus the convergent community consensus on behaviour preservation.

Prime directive — preserve behaviour exactly (non-negotiable)

Change only how the code reads, never what it does.
Do not change public APIs, logging, error semantics, or concurrency unless explicitly asked.
If a change's behavioural safety is uncertain, DO NOT make it. Leave the code and note it. (Default-deny, like the loop's skeptical verdict parsing.)
Edits must be small, local, atomic, and reversible. Scope = code this task changed, nothing else.
Expect a re-verification after you finish: a regression reverts YOUR cleanup, never the feature. So never trade correctness for tidiness.

The four axes

Reuse — does the change reinvent something that already exists? Grep the codebase; call the existing helper/util/base class instead of a fresh copy.
Simplify — the core slop-killers:
- Dead code: unused imports, variables, params, functions, unreachable branches, commented-out blocks, "maybe later" placeholders.
- Over-abstraction: wrapper classes, "manager" layers, single-implementation factories/registries, forwarding layers that only delegate, single-use helpers that add indirection. Prefer a direct call.
- Deep nesting (>3 levels) → guard clauses / early returns / extraction.
- Long functions → decompose into named operations (but do NOT shatter into many tiny indirection-adding functions).
- Needless cleverness: dense one-liners, nested ternaries (ban), deeply nested comprehensions, clever short-circuiting. Clarity > brevity.
- Redundant conditions/booleans, magic values → named constants.
- Comments that merely restate the code.
Efficiency — behaviour-preserving wins ONLY: hoist repeated computation, obvious O(n²)→O(n). Never if it could change observable behaviour.
Right altitude — is the change at the correct level? Neither premature generality (YAGNI) nor copy-paste that should be one helper. This is the judgment axis — weigh the complexity cost of any abstraction you keep or add.

Anti-over-simplification guardrails (keep these or it backfires)

Do NOT remove abstractions that genuinely reduce duplication or organize code.
Do NOT merge unrelated concerns to cut line count.
Do NOT make code harder to debug or extend in the name of "simple".
Fewer lines is not the goal; a readable, maintainable diff is.

Output

Apply mechanical, clearly-safe cleanups directly.
For anything intent-changing or uncertain, SURFACE it (describe it) rather than editing — same mechanical-vs-surfaced split as /grill-loop.
If the code is already clean, say NO CHANGES NEEDED.