Prompt Engineering

Remove Duplicate Code — Consolidate Without Coupling

Three near-identical functions, one future bug fixed in only two of them. This prompt consolidates duplication into shared logic — and knows when near-duplicates should stay separate.

Open in Refactor Prompt Builder

Overview

Duplicate code removal sounds mechanical until the duplicates turn out to differ on purpose. This prompt uses the maintainability goal — extract the shared logic so a future fix lands in one place — with the warning that saves refactors: near-duplicate code is not always true duplication, and merging two blocks that evolve for different reasons creates coupling, not reuse. The loaded setup carries a real-world constraint of exactly that kind: one of the three export functions uses a subtly different date format, and the contract demands confirmation of whether that is intentional before any merge.

How to use this resource

Map the copies

Identical, near-identical, and intentionally-different blocks get separated before anything merges.
Confirm the differences

A subtle divergence — a date format, a rounding rule — is a question for a human, not a casualty of the merge.
Extract once, verify each

The shared logic lands in one place; every original call path is validated against its old behavior.

Why This Works

Future fixes landing in one place is the entire economic case for the refactor
The coupling warning prevents the merge that makes two features hostage to each other
Per-call-path validation catches the copy that was different for a reason

Best for

Codebases where the same fix keeps being applied in several places
Copy-paste-driven modules that drifted slightly apart
Cleanups after fast feature work

Not for

Detecting duplicated phrasing in a prompt — that's the Prompt Cleaner
Reporting duplication as a finding without changing it — that's the Code Review Prompt Generator

Use cases

Consolidating copy-pasted export, report, or handler functions
Extracting shared validation scattered across endpoints
Deciding whether two similar blocks are one concept or two

FAQ

How does this refactor prompt handle export functions that differ in one small way, like a date format?

It's told to ask before merging. The stated constraint is that the CSV export uses a subtly different date format — "confirm whether that is intentional before merging." The TRANSFORMATION GUIDANCE warns that near-duplicate blocks merged when they evolve for different reasons "creates coupling, not reuse." The refactor-prompt-builder outputs this prompt; the divergence becomes a question for you, not a silent casualty.

Will this prompt change what my code outputs when it removes the duplication?

It's constrained not to. BEHAVIOR PRESERVATION REQUIREMENTS keep formats, ordering, precision, side effects, and public contracts identical, and if goal and behavior conflict, "behavior wins: stop and explain the conflict." Anything skipped for safety lands under "Suggested but not applied." You still validate each original call path — the prompt produces the refactor, not a proof it's behavior-neutral.

Customize This Resource

Opens this setup in Refactor Prompt Builder. Generate to get the full refactoring contract — then adjust the goal, risk level, and validation strategy.

Open in Refactor Prompt Builder

Prompt Template

Copy it as-is, or use Open in Refactor Prompt Builder to load it pre-filled and customize it with your own context.

REFACTORING OBJECTIVE
Consolidate the three near-identical export functions into shared logic a future fix lands in once.
Refactoring goal: maintainability — make the next change cheaper without changing current behavior.
Change how the code is built — never what the code does. If a transformation cannot be made safely with the available information, leave that code unchanged and say why.

EXISTING CODE CONTEXT
Code context: none specified — treat unknown consumers as possible and unstated requirements as existing.
Language: not specified — infer it from the code and stay consistent with it.
Stated constraints:
- The CSV export uses a subtly different date format — confirm whether that is intentional before merging
Code to refactor:
```
[Paste the code to refactor here]
```

REFACTORING GOAL
Primary goal: Maintainability.
Transformation priorities for this goal:
1. Separate concerns: split code that changes for different reasons into units that change for one reason.
2. Reduce duplication by extracting the shared logic — once duplication is gone, a future fix lands in one place.
3. Clarify responsibilities: one job per function, one purpose per module.
4. Localize change impact: a future edit should touch few places, not many.

RISK PROFILE
Risk level: Balanced.
- Apply reasonable improvements: moderate restructuring is allowed where the benefit is clear.
- Group related changes, but keep each group reviewable and separately verifiable.
- When a transformation is borderline-safe, apply the conservative version and note the more aggressive option.

SAFETY RULES
These rules apply to every transformation, at every risk level:
1. Identify behavior assumptions before changing code — list every assumption you rely on.
2. Flag uncertain behavior instead of deciding it: if you cannot tell what a branch does or why it exists, ask — do not guess.
3. Do not remove functionality. Code that looks redundant may be load-bearing.
4. Do not invent requirements. Refactor toward the stated goal, not toward an imagined better product.
5. Do not rewrite unrelated code. Touch only what the goal requires.
6. Explain why each change exists — every transformation traces to the stated goal or to a named problem in the code.
7. Preserve public contracts — signatures, return types, error types, serialized shapes — unless explicitly instructed otherwise.

TRANSFORMATION GUIDANCE
Known failure modes of this goal — watch for:
- Near-duplicate code is not always true duplication — merging two similar blocks that evolve for different reasons creates coupling, not reuse.
- Do not abstract for imagined future requirements — extract what is duplicated now, not what might vary someday.

BEHAVIOR PRESERVATION REQUIREMENTS
- Preserve observable behavior: the same inputs produce the same outputs, including error cases.
- Preserve business rules: every condition, threshold, and special case survives the refactor exactly.
- Preserve outputs: formats, ordering, precision, and encodings stay identical unless the goal explicitly targets them.
- Preserve side effects: writes, emitted events, log lines other systems consume — and their relative order.
- Preserve integrations: API shapes, serialized payloads, database access patterns, and external call sequences.
- These requirements hold unless the instructions explicitly say otherwise — and any knowingly behavior-affecting change must be flagged, never silent.
- If achieving the goal and preserving behavior conflict, behavior wins: stop and explain the conflict instead of compromising it.

VALIDATION STRATEGY
Goal-specific validation: every extraction and merge must preserve each original call path's behavior, including its edge cases.
- Identify the key workflows this code serves and describe how to verify each still works after the refactor.
- List the major edge cases the original code handles and confirm each is still handled — name them individually.
- Recommend regression checks for the riskiest transformations made, riskiest first.

ASSUMPTIONS
- List every assumption made about the code's behavior, inputs, or environment.
- Mark each assumption VERIFIED (with its evidence) or UNVERIFIED (with the question that would resolve it).
- Any transformation that depends on an UNVERIFIED assumption must be flagged as conditional on it.

NON-GOALS
- Do not invent requirements.
- Do not redesign the entire system.
- Do not remove behavior without justification.
- Do not introduce new features.
- Separate assumptions clearly from facts.
- Flag uncertainty instead of resolving it silently.
- Explain the tradeoffs of any change that has them.

OUTPUT REQUIREMENTS
- Return the refactored code, complete — no elided sections, no "rest unchanged" placeholders inside changed units.
- Follow it with a change list: for each change — what changed, why it serves the goal, and its behavior impact (expected: none).
- Flag any change that could plausibly alter behavior, with the reason it might and the check that would confirm it does not.
- Where a worthwhile transformation was skipped for safety, list it under "Suggested but not applied" with what information would unlock it.

More resources from Refactor Prompt Builder

Resource

Refactor Prompt — the Behavior Preservation Contract

"Refactor this code" invites silent behavior changes. The refactoring contract preserves business rules, outputs, and side effects — and flags uncertainty instead of deciding it.

Prompt Engineering

Resource

Safe Refactoring Prompt — Zero Regression Tolerance

For code that ships weekly: a refactoring prompt where regression avoidance outranks improvement depth, log lines stay intact, and every step is rollback-friendly.

Prompt Engineering

Resource

AI-Generated Code Cleanup — Deflate the Generated Bloat

Generated code duplicates instead of extracting, wraps without deciding, and defends against impossible states. This prompt hunts those exact failure modes — without preserving bugs as behavior.

Prompt Engineering

Resources that pair well

Resource

Code Review Prompt — the Review Contract

"Review this code" gets shallow comments. The review contract gets findings with severities, a checklist, and a verdict.

Prompt Engineering

Resource

Playwright Test Prompt

getByRole over CSS chains, auto-wait over sleep, web-first assertions — Playwright tests written the way Playwright wants.

Engineering

Resource

Debugging Prompt — the Investigation Contract

"Fix this error" gets guesses. The investigation contract gets a ten-stage diagnosis: facts separated from assumptions, alternatives weighed, fixes justified.

Prompt Engineering

Related tools

Tool

Refactor Prompt Builder

Build behavior-preserving refactor prompts — goal, risk level, and code context turn into a safe refactoring contract.

Coding Workflows

Tip: Save time by exploring related resources and tools that integrate with this resource.