Plan a Behavior-Preserving Code Refactor

Outcome

Behavior-preserving refactor plan

Returns the refactor goal, preserved behavior, current structure issues, staged changes, behavior-change risks, and checks to run.

Use case

Refactor planning before code changes

Use before extracting functions, reducing duplication, simplifying control flow, renaming internals, or improving maintainability.

Output

Small change plan

Produces a staged plan with required changes, optional cleanup, risk areas, verification steps, missing evidence, and confidence level.

When to use this prompt

Use this prompt to plan a refactor that changes code structure while preserving externally visible behavior and avoiding invented project state.

Use it when

Existing code needs structural improvement

Use it when the goal is to improve readability, reduce duplication, simplify control flow, extract responsibilities, or improve maintainability without changing behavior.

Do not use it when

The task requires new feature design, architecture redesign, or security review

Use a feature-design, architecture-review, or security-review workflow when the task requires new behavior, system-level redesign, or threat analysis.

Inputs required

Provide the current code, intended refactor goal, behavior that must be preserved, tests or examples if available, and constraints. The prompt should not invent files, tests, execution results, or project architecture.

Current code

The function, file, module, component, or relevant excerpt that should be refactored.

Refactor goal

What should improve: readability, duplication, function size, naming, control flow, responsibility boundaries, or maintainability.

Behavior and verification context

Behavior that must be preserved, existing tests, examples, expected inputs and outputs, constraints, and known regression-sensitive paths.

Copy-ready prompt

Copy the prompt and replace the MATERIALS block with the current code, refactor goal, behavior constraints, tests, and relevant context.

Plan a behavior-preserving code refactor.

TASK:
Review the supplied code and produce a refactor plan that improves structure, readability, or maintainability without changing existing behavior.

REFACTOR SCOPE:
Focus on planning a small behavior-preserving refactor.
Do not introduce new product behavior unless the user explicitly asks for it.
Do not perform a full architecture redesign unless the user explicitly asks for architecture review.
Do not perform a security review unless the user explicitly asks for one.
Do not claim the refactor was implemented, run, tested, or verified unless execution evidence is supplied.
Do not invent project files, dependencies, tests, runtime output, logs, or hidden architecture.

BEHAVIOR-PRESERVATION RULES:
- Identify the behavior that must remain unchanged.
- Identify inputs, outputs, side effects, API contracts, configuration behavior, and error behavior that may be affected.
- If behavior is unclear, mark it as INSUFFICIENT_EVIDENCE.
- If the requested refactor may change behavior, flag it as BEHAVIOR_CHANGE_RISK.
- Prefer the smallest staged refactor that achieves the stated goal.
- Separate required refactor steps from optional cleanup.
- Do not remove code unless the supplied material supports that it is unused, duplicated, or unnecessary.
- Do not rename public APIs, exported symbols, routes, configuration keys, or externally used fields unless the user explicitly approves that scope.

REVIEW CHECKS:
- Current responsibility boundaries
- Duplication
- Function or module size
- Naming clarity
- Control-flow complexity
- Data-flow clarity
- Side effects
- Public API or interface stability
- Configuration or environment coupling
- Test impact
- Regression-sensitive paths

OUTPUT:
A) Refactor goal check
B) Behavior that must be preserved
C) Current structure issues
D) Refactor plan
E) Required changes
F) Optional cleanup
G) Behavior-change risks
H) Tests or checks to run
I) Missing evidence
J) Confidence

MATERIALS:
"""
Replace this block with:
- current code
- refactor goal
- behavior that must be preserved
- existing tests, if available
- examples or expected inputs and outputs, if available
- project constraints, if relevant
- files or APIs that must not change, if relevant
"""

ChatGPT Projects, GPTs, Skills, files/sources, Custom Instructions, Memory, and runtime prompts. Open mapping → Claude Projects, Project Instructions, Project Knowledge, Skills, and runtime chat input. Open mapping → Gemini Gems, Gem instructions, Knowledge files, Memory, Connected Apps, AI Studio, Gemini API, Files API, File Search, and Vertex AI. Open mapping →

Use these related workflows when the task needs code-quality review, test coverage review, or stricter evidence control.

No simulation / no fabrication

Use this component when the assistant must not invent project files, execution results, tests, logs, runtime behavior, or unsupported refactor evidence.

Open component →

Review code against language and framework best practices

Use this workflow when the next task is code-quality review rather than refactor planning.

Open workflow →

Test coverage and regression review

Use this workflow after a refactor plan when the next task is checking test coverage and regression risk.

Open workflow →

Use this as a runtime refactor-planning prompt