Promptheus/commands36 commands · free · CC0Promptheus hub ↗
← All commands
/simplify <file | selection>

Refactor

Simplify

Untangle complexity without changing behaviour.

simplifyreadability
CategoryRefactor
Arguments<file | selection>
Allowed toolsReadGrepGlobEdit
What it does

Simplify overly complex code — flatten nesting, use guard clauses, drop needless abstraction — without changing behaviour.

.claude/commands/simplify.md.claude/commands/ (project) · ~/.claude/commands/ (global)
Install into your repo
npx promptheus-commands add simplify

The prompt

Simplify the code in $ARGUMENTS so it reads more plainly, without changing its observable behaviour — its return values, side effects, thrown errors, emitted output, and public signatures/serialization stay byte-for-byte identical for every input.

If $ARGUMENTS is empty, target the current uncommitted diff (git diff HEAD). If the working tree is clean, stop and ask which file or selection to simplify — do not guess.

Method

  1. Scope it. Resolve $ARGUMENTS to concrete files/line ranges. Read the full surrounding context, not just the named lines — you must understand callers and callees before touching anything.
  2. Establish a safety net. Detect the project's test and lint commands (package.json scripts, Makefile, pyproject.toml, justfile, CI config). Run the relevant tests now to confirm a green baseline. If none cover this code, say so and substitute: write a characterization test that pins the current outputs before editing, or if that is impractical, enumerate the call sites and the representative inputs (edge cases, error paths, boundary values) by hand and diff old-vs-new behaviour for each, or compare the compiler/interpreter's AST or token stream before and after.
  3. Learn the conventions. Detect language idioms, naming style, formatter, and error-handling patterns already used in these files. Match them — do not import a style from another ecosystem.
  4. Simplify in small, behaviour-preserving steps. Re-run the affected tests after each meaningful step. If the suite is slow (more than ~30s), batch related edits and run only the targeted file/module between them, keeping a full run for step 5 — batching is fine, silently skipping verification is not. Apply only these moves where they make the code plainer:
    • Replace nested if/else pyramids with guard clauses and early returns; handle error/edge cases first, then the happy path at the base indent.
    • Drop else after a branch that returns/throws/continues. Invert conditions and apply De Morgan to untangle boolean logic.
    • Inline needless indirection: single-use helpers, variables, wrappers, or layers that only forward arguments and add a hop.
    • Collapse duplicated branches; remove dead code, unreachable paths, unused params, and redundant local state.
    • Prefer clear stdlib/built-ins (map/filter/comprehensions, standard collections) over hand-rolled loops only when the result is more legible.
    • Clarify names: fix misleading identifiers, expand cryptic abbreviations, flip booleans that read backwards. Keep renames local unless the symbol is trivially scoped.
    • Resync comments and docstrings as you go: rewrite or delete any that a control-flow change made inaccurate, and drop comments that only narrate now-obvious code. Never leave a comment describing the old shape.
  5. Verify. Re-run the full test suite, linter, and formatter. Everything must pass. Re-read your own diff as a reviewer would.

Output

  • Make the edits directly, then report: a one-line summary, a bullet per change naming the technique, the file:line, and why it is clearer, plus the exact test/lint commands you ran with their results. Do not paste the full diff or file contents — name the changes and let the tool diff show them; quote at most a one-to-three-line before/after snippet when the point is otherwise unclear.
  • Flag anything you deliberately left alone because simplifying it would risk behaviour.

Rules

  • Never change observable behaviour, public signatures, serialization, or error semantics. If a simplification would, stop and surface it instead of applying it.
  • Never add dependencies, new abstractions, config, or "while I'm here" features. This command removes cleverness; it does not add any.
  • Always keep the diff minimal and reviewable — no unrelated reformatting, no mass renames, no reordering that inflates the diff without improving clarity.
  • If tests are red before you start, report that and stop — do not simplify on top of a broken baseline.
  • When a change is a genuine judgement call between two equally clear forms, prefer the one closer to the surrounding code and leave it; do not churn.

Add it to your toolkit

Save it as .claude/commands/simplify.md or .cursor/commands/simplify.md, then invoke it with /simplify and your arguments.

Back to top ↑