{"title":"Refactor for Readability","description":"Improve clarity of a function without changing its behavior.","tags":["readability","clean-code"],"content":"Refactor this code for readability without changing its behavior:\n\n```\n{{code}}\n```\n\nFocus on: clear names, smaller functions, early returns over nesting, and removing incidental complexity. Do NOT change the public interface or observable behavior.\n\nFor each change, give a one-line reason. At the end, state how I can verify behavior is unchanged.","variables":[{"name":"code","description":"The code to refactor","required":true,"multiline":true}]}
{"title":"Extract and Decompose","description":"Break a large function or class into well-named, focused units.","tags":["decomposition","srp"],"content":"This unit is too big and does too much:\n\n```\n{{code}}\n```\n\nDecompose 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.","variables":[{"name":"code","description":"The oversized unit","required":true,"multiline":true}]}
{"title":"Remove Duplication","description":"Find and consolidate duplicated logic safely.","tags":["dry","duplication"],"content":"Find the duplication in this code and consolidate it:\n\n```\n{{code}}\n```\n\nBe 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.","variables":[{"name":"code","description":"Code with suspected duplication","required":true,"multiline":true}]}
{"title":"Introduce a Design Pattern","description":"Apply an appropriate design pattern to untangle code — or argue against it.","tags":["patterns","design"],"content":"Here is code that feels tangled: \n\n```\n{{code}}\n```\n\nWould 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.","variables":[{"name":"code","description":"The tangled code","required":true,"multiline":true}]}
{"title":"Make Code Testable","description":"Restructure hard-to-test code to enable unit testing.","tags":["testability","di","seams"],"content":"This code is hard to test:\n\n```\n{{code}}\n```\n\nRefactor 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.","variables":[{"name":"code","description":"The untestable code","required":true,"multiline":true}]}
{"title":"Modernize Legacy Code","description":"Bring old code up to current language idioms and APIs.","tags":["legacy","modernization"],"content":"Modernize this legacy {{language}} code to current idioms and APIs:\n\n```\n{{code}}\n```\n\nReplace 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.","variables":[{"name":"language","description":"The language","required":true},{"name":"code","description":"The legacy code","required":true,"multiline":true}]}
{"title":"Reduce Cyclomatic Complexity","description":"Flatten deeply nested or branch-heavy logic.","tags":["complexity","control-flow"],"content":"This function has too many branches/nesting levels:\n\n```\n{{code}}\n```\n\nReduce 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.","variables":[{"name":"code","description":"The complex function","required":true,"multiline":true}]}
{"title":"Tidy First, Then Change","description":"Separate a structural cleanup from a behavioral change in two steps.","tags":["tidy-first","safe-change"],"content":"I need to make this change: {{change}}\n\nTo the code:\n\n```\n{{code}}\n```\n\nApply '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.","variables":[{"name":"change","description":"The behavioral change you need","required":true},{"name":"code","description":"The code to change","required":true,"multiline":true}]}
{"title":"Replace Conditional with Polymorphism","description":"Turn a sprawling type-switch into polymorphic dispatch, or leave it.","tags":["polymorphism","conditionals"],"content":"This code switches on a type or kind in several places:\n\n{{code}}\n\nWould 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.","variables":[{"name":"code","description":"The conditional-heavy code","required":true,"multiline":true}]}
{"title":"Untangle a Circular Dependency","description":"Break a cycle between modules.","tags":["dependencies","modularity"],"content":"These modules depend on each other circularly: {{modules}}\n\nDiagnose 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.","variables":[{"name":"modules","description":"The modules and how they depend on each other","required":true}]}
{"title":"Rename for Clarity","description":"Propose better names for confusing identifiers.","tags":["naming","readability"],"content":"These names are unclear:\n\n{{code}}\n\nPropose 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.","variables":[{"name":"code","description":"Code with poor names","required":true,"multiline":true}]}
{"title":"Simplify a Boolean Expression","description":"Make complex conditional logic readable and correct.","tags":["boolean-logic","conditionals"],"content":"This condition is hard to reason about:\n\n{{expression}}\n\nSimplify 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.","variables":[{"name":"expression","description":"The boolean expression","required":true,"multiline":true}]}
{"title":"Extract an Interface","description":"Decouple a caller from a concrete implementation.","tags":["interface","decoupling"],"content":"This code is tightly coupled to a concrete implementation:\n\n{{code}}\n\nExtract 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.","variables":[{"name":"code","description":"The tightly-coupled code","required":true,"multiline":true}]}
{"title":"Split a God Object","description":"Break an overgrown class or function into focused pieces.","tags":["god-object","cohesion"],"content":"This class or function does too many things:\n\n{{code}}\n\nIdentify 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.","variables":[{"name":"code","description":"The overgrown class/function","required":true,"multiline":true}]}
{"title":"Replace Magic Values with Constants","description":"Name unexplained literals scattered through code.","tags":["constants","readability"],"content":"This code has unexplained magic numbers or strings:\n\n{{code}}\n\nReplace 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.","variables":[{"name":"code","description":"Code with magic values","required":true,"multiline":true}]}
{"title":"Make a Function Pure","description":"Remove hidden side effects and dependencies.","tags":["purity","side-effects"],"content":"This function is hard to test or reason about because of side effects:\n\n{{code}}\n\nSeparate 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.","variables":[{"name":"code","description":"The effectful function","required":true,"multiline":true}]}