Loading page
About this tool
Builds a refactoring prompt with named goals, hard constraints and a complexity target, so behaviour stays exactly unchanged.
The Refactor Prompt Builder writes an AI refactoring prompt that names the exact refactorings to apply — Extract Function, Replace Nested Conditional with Guard Clauses, Replace Magic Literal and others from Fowler's catalogue — alongside hard constraints that keep observable behaviour, public APIs and existing tests unchanged. It also accepts a cyclomatic-complexity goal checked against McCabe's recommended per-function limit of 10, so 'clean this up' becomes a bounded, verifiable task instead of an invitation to rewrite.
Open Refactor Prompt Builder on AltFTool — it loads instantly in your browser.
Paste your code or data sample into the workspace.
Pick the format, conversion, or analysis you need.
Copy the polished result straight back into your project.
Each goal maps to a catalogued refactoring with its standard name, so the model applies a known-safe transformation instead of improvising.
Selectable hard constraints — identical outputs and error types, frozen API, untouched tests, no new dependencies — are written into the prompt as failure conditions.
The prompt orders the model to flag suspected bugs and leave them in place, because silently 'fixing' behaviour during a refactor is how regressions ship.
Refactoring changes a program's internal structure without changing its observable behaviour — same outputs, side effects and error behaviour for every input — while a rewrite may change behaviour. The generated prompt states this definition up front and instructs the model to skip any change it cannot prove behaviour-safe.
10 per function is the classic upper limit proposed in McCabe's 1976 paper that introduced the metric, and it remains the default threshold in linters like ESLint, pylint and SonarQube. This tool lets you set any lower target and notes in the prompt when your target still sits above 10.
Constrain it explicitly: require identical outputs and error types for all inputs including invalid ones, freeze the public API, forbid edits to tests, and require the model to justify why each step cannot change behaviour. This tool writes all of those as hard failure conditions — and your test suite remains the final check.
No — a refactor should preserve behaviour, bugs included, because mixing fixes into structural changes makes both impossible to review and revert independently. The generated prompt tells the model to flag suspected bugs in a comment and leave the behaviour intact for a separate change.