do-simplify

Identify the modified code, then apply only changes that preserve outputs, side effects, timing, public APIs, and error behavior. Focus on flattening nesting, removing dead branches, collapsing duplicates, and renaming vague identifiers, then verify each change at the call site.

Inline a helper when its body is clearer than its name and the call site becomes easier to read. Keep it when it names a domain concept, hides multiple checks behind one intent-revealing name, or separates high-level flow from low-level mechanics.

Avoid changes that combine unrelated concerns, expose low-level mechanics at important call sites, replace clear control flow with dense expressions, or introduce new patterns not already present. Do not reformat or modernize unrelated code.

Stop when remaining changes are taste preferences, when a refactor needs broader context than the modified code provides, or when simplification would require new tests, migrations, or API changes. If the code is already clear enough, say so.

Yes, the rules are language-agnostic and focus on readability, naming, and control flow rather than syntax. The Skill matches the surrounding style of the codebase instead of imposing new conventions.