Coding Workflows
"Refactor this code" invites hidden behavior changes. Pick a goal, a risk level, and a code context — and get a refactoring contract: behavior preservation requirements, seven always-on safety rules, goal-specific warnings, and an assumptions discipline where uncertainty becomes a question, never a silent decision. Runs entirely in your browser.
What should change, and toward what? E.g. "Decompose the 400-line ProcessOrder method into small, named steps."
Strict demands before/after verification, behavior comparison, regression and integration checks.
Hard limits the refactor must respect — "Public API must not change", "Database schema is frozen".
Paste it and the prompt carries it verbatim in a fenced block — or leave empty for a paste-here placeholder.
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.
View Resource →Dependency cycles, leaky modules, misplaced responsibilities — cleaned up within the existing design. Explicitly not an invitation to invent a new architecture.
View Resource →Legacy code has callers you cannot see and assumptions nobody wrote down. This refactoring prompt treats every public surface as load-bearing and changes in small, verified steps.
View Resource →Pattern matching, records, nullable annotations, async done right — a C# modernization scope with the rule that matters: modern equivalents are rarely exact equivalents.
View Resource →var to const, callback pyramids to async/await, || guards to ?? — with the trap called out by name: || treats 0 and empty string as missing, ?? does not.
View Resource →Code a new hire cannot follow is a cost on every future change. This prompt renames for intent, extracts nameable steps, and replaces cleverness with clarity — semantics untouched.
View Resource →Deep nesting and tangled branching make code unreasonable. This prompt flattens control flow with guard clauses and collapses duplicate decisions — with every branch still routing the same way.
View Resource →"Refactor this code" invites silent behavior changes. The refactoring contract preserves business rules, outputs, and side effects — and flags uncertainty instead of deciding it.
View Resource →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.
View Resource →For code that ships weekly: a refactoring prompt where regression avoidance outranks improvement depth, log lines stay intact, and every step is rollback-friendly.
View Resource →A complete AI-assisted review pass — not one prompt — that ends with ranked findings, tests guarding behavior, and a refactor plan when one is warranted.
View Playbook →The order that actually finds bugs instead of guessing at them — so you end with a verified fix, not a plausible one that quietly returns next week.
View Playbook →Update old, risky code you didn't write — safely — by understanding and pinning its behavior in tests before you change a single line.
View Playbook →Restructure code you own without breaking it — change only what's worth changing, and prove with tests and a diff that behavior held.
View Playbook →State the refactoring objective, pick the goal — Readability, Maintainability, Performance, Modernization, Simplification, or Architecture Cleanup — and set the risk level and code context. Each goal is a different transformation philosophy with its own priorities, known failure modes, and validation focus; contexts like Legacy or AI-Generated add real duties, and with the Modernization goal the language select sets a concrete modernization scope. Optionally paste the code (carried verbatim in a fenced block) and add hard constraints like "public API must not change". The live Refactor Preview shows the contract's shape before you commit. Click Generate Refactor Prompt for the full refactoring contract: behavior preservation requirements and seven safety rules that apply at every risk level, goal-specific transformation guidance, a validation strategy, and an assumptions discipline where uncertain behavior becomes a question — never a silent decision. Nothing leaves your browser.
No — it builds the contract. The output is a prompt that instructs an AI how to refactor safely: what to preserve, what to watch for, how to validate, and what to do with uncertainty. The flagship is the Behavior Preservation Contract — observable behavior, business rules, outputs, side effects, and integrations all survive unless you explicitly say otherwise.
Because the failure mode is silent. An unconstrained refactor invites hidden behavior changes, business rule regressions, removed functionality that looked redundant, and invented requirements — and the diff looks like an improvement. The contract counters each one by name: do not remove functionality, do not invent requirements, do not rewrite unrelated code, flag uncertain behavior instead of deciding it.
Different verbs. Review JUDGES — it asks "what is wrong?" and produces findings. Refactor CHANGES — it asks "how should it be changed?" and produces a controlled transformation. They chain naturally: a review finding like "this method does four jobs" becomes this tool's objective. And in this category: Debugging investigates failures, Test Case validates behavior, Code Explanation teaches it — Refactor transforms it.
The size of the allowed change set — never the safety rules. Conservative demands the smallest change set, prefers many independently safe steps, and skips anything unverifiable. Balanced allows moderate restructuring in reviewable groups. Aggressive allows larger restructuring — but its own rules say it plainly: aggressive applies to the size of the change, not its safety. No behavioral assumptions, no feature invention, at any level.
It targets the failure modes typical of generated code: repetition (generated code duplicates logic instead of extracting it), over-abstraction (wrappers and interfaces that make no decision), and unneeded complexity (defensive checks for impossible states). It also adds a subtle rule: generated code can look right while being subtly wrong — so a discovered bug gets flagged, never silently preserved as behavior.
No — the Performance goal is generic code performance: repeated work, allocations, algorithm choice. Its own guidance states that SQL query optimization (indexes, execution plans, query rewrites) is out of scope. That space belongs to the SQL Optimization Prompt tool, where dialect, schema, and execution-plan context get first-class treatment.
No, and that's deliberate. A refactor preserves behavior, including behavior that looks wrong — "fixing" it mid-refactor is how business rules get broken. The contract instructs the model to flag suspicious behavior as a question instead. If it really is a bug, diagnose it with the Debugging Prompt Generator first, fix it, then refactor clean code.