title: Refactor for Readability

description: Improve clarity of a function without changing its behavior.

content:
Refactor this code for readability without changing its behavior:

```
{{code}}
```

Focus on: clear names, smaller functions, early returns over nesting, and removing incidental complexity. Do NOT change the public interface or observable behavior.

For each change, give a one-line reason. At the end, state how I can verify behavior is unchanged.

code

description: The code to refactor


title: Extract and Decompose

description: Break a large function or class into well-named, focused units.

content:
This unit is too big and does too much:

```
{{code}}
```

Decompose it. Identify the distinct responsibilities, propose a set of smaller functions/types with clear names and single responsibilities, and show how they compose back into the original behavior. Keep coupling low and avoid leaking internals. Flag any responsibility that probably belongs in a different module entirely.

description: The oversized unit


title: Remove Duplication

description: Find and consolidate duplicated logic safely.

content:
Find the duplication in this code and consolidate it:

```
{{code}}
```

Be careful: only unify code that is the same for the same *reason* (true duplication), not code that merely looks similar today but may diverge. For each consolidation, name the single concept it captures. If some near-duplicates should stay separate, say why.

description: Code with suspected duplication


title: Introduce a Design Pattern

description: Apply an appropriate design pattern to untangle code — or argue against it.

content:
Here is code that feels tangled:

```
{{code}}
```

Would a design pattern help? If yes, recommend the specific pattern, explain exactly what problem it solves here, and show the refactor. If a pattern would be over-engineering, say so and propose the simpler structural fix instead. Bias toward the simplest thing that removes the pain.

description: The tangled code


title: Make Code Testable

description: Restructure hard-to-test code to enable unit testing.

content:
This code is hard to test:

```
{{code}}
```

Refactor it to be testable: introduce seams for dependencies (I/O, time, randomness, network), separate decision logic from side effects, and make outputs observable. Don't change behavior. Then show one example test that the new structure makes possible but the old one didn't.

description: The untestable code


title: Modernize Legacy Code

description: Bring old code up to current language idioms and APIs.

content:
Modernize this legacy {{language}} code to current idioms and APIs:

```
{{code}}
```

Replace deprecated APIs, adopt modern language features where they genuinely improve clarity or safety, and tighten types. Preserve behavior exactly. List each deprecation you removed and what replaced it. Do not modernize for its own sake — skip changes that add churn without benefit.

language

description: The language

description: The legacy code


title: Reduce Cyclomatic Complexity

description: Flatten deeply nested or branch-heavy logic.

content:
This function has too many branches/nesting levels:

```
{{code}}
```

Reduce its complexity using guard clauses, early returns, lookup tables, polymorphism, or extraction — whichever fits. Keep behavior identical, including edge cases. Show the before/after complexity intuition and confirm every original branch is still covered.

code

description: The complex function


title: Tidy First, Then Change

description: Separate a structural cleanup from a behavioral change in two steps.

content:
I need to make this change: {{change}}

To the code:

```
{{code}}
```

Apply 'tidy first': propose a structural-only refactor (no behavior change) that makes the upcoming change easy, then make the behavioral change as a clean second step. Present them as two separate diffs so each is independently reviewable and revertible.

change

description: The behavioral change you need

description: The code to change


title: Replace Conditional with Polymorphism

description: Turn a sprawling type-switch into polymorphic dispatch, or leave it.

content:
This code switches on a type or kind in several places:

{{code}}

Would polymorphism (or a strategy map) be cleaner? If yes, show the refactor: one place decides the type, each behavior lives beside its variant. If the switch is in ONE place and small, say so and leave it, since polymorphism would scatter the logic. Justify your call.

code

description: The conditional-heavy code


title: Untangle a Circular Dependency

description: Break a cycle between modules.

content:
These modules depend on each other circularly: {{modules}}

Diagnose the cycle and break it. Options: extract the shared piece into a third module, invert a dependency via an interface or callback, or merge them if they are really one concept. Recommend the cleanest for my case and show the new dependency direction. Explain what the cycle was hiding about the design.

modules

description: The modules and how they depend on each other


title: Rename for Clarity

description: Propose better names for confusing identifiers.

content:
These names are unclear:

{{code}}

Propose better names. Each should say what the thing IS or DOES, at the right abstraction level, consistent with its neighbors. Avoid encodings, vague words (data, info, manager, helper), and lies. For each rename, one line on why it is clearer. Flag any name whose confusion signals a deeper design problem.

code

description: Code with poor names


title: Simplify a Boolean Expression

description: Make complex conditional logic readable and correct.

content:
This condition is hard to reason about:

{{expression}}

Simplify it without changing its truth table. Apply De Morgan laws, extract well-named intermediate booleans, and remove double negatives. Show the before and after and confirm they are equivalent for all inputs. If a bug is hiding in the complexity, point it out.

expression

description: The boolean expression


title: Extract an Interface

description: Decouple a caller from a concrete implementation.

content:
This code is tightly coupled to a concrete implementation:

{{code}}

Extract an interface (or protocol/trait) so the caller depends on behavior, not a concrete type. Define the minimal interface the caller actually needs — no more. Show the refactor and how a test could now substitute a fake. Warn me if this is premature abstraction: if there is exactly one implementation and no test or seam needs it, say so and leave it.

code

description: The tightly-coupled code


title: Split a God Object

description: Break an overgrown class or function into focused pieces.

content:
This class or function does too many things:

{{code}}

Identify the distinct responsibilities tangled inside it. Group the fields and methods that change together and propose how to split them into cohesive units, each with one reason to change. Show the new boundaries and how they collaborate. Sequence the refactor into safe steps. Flag any shared mutable state that makes the split harder than it looks.

description: The overgrown class/function


title: Replace Magic Values with Constants

description: Name unexplained literals scattered through code.

content:
This code has unexplained magic numbers or strings:

{{code}}

Replace them with well-named constants (or an enum) that say what the value MEANS, not just what it is. Group related ones and put them where they belong. Distinguish a true magic value from a self-evident literal (0, 1, an empty string) that needs no name. Show the before and after, and flag any literal whose duplication was hiding a bug.

description: Code with magic values


title: Make a Function Pure

description: Remove hidden side effects and dependencies.

content:
This function is hard to test or reason about because of side effects:

{{code}}

Separate the pure computation from the effects (I/O, mutation, time, randomness). Push the effects to the edges and make the core a pure function of its inputs. Show the refactor and how the pure core is now trivially testable. Tell me which effect genuinely cannot be removed and how to inject it instead so it can be faked.

description: The effectful function