code-simplifier

name	code-simplifier
description	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.

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

1. Reuse — does the change reinvent something that already exists? Grep the codebase; call the existing helper/util/base class instead of a fresh copy.
2. 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.
3. Efficiency — behaviour-preserving wins ONLY: hoist repeated computation, obvious O(n²)→O(n). Never if it could change observable behaviour.
4. 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.