code-refactor
Mission
Section titled “Mission”Improve existing code: measure → prioritize → transform → verify. Never break working behavior.
When to Use
Section titled “When to Use”Use when improving existing code quality, reducing technical debt, eliminating coupling, splitting oversized modules, improving performance, or hardening security of existing code.
Triggers: “refactor this”, “reduce tech debt”, “clean up”, “improve code quality”, “split this module”, “too complex”
Skills Invoked
Section titled “Skills Invoked”qual-refactoring-priority— ranks candidates by risk, impact, debt scorequal-code-analysis— static analysis to identify targetsgr-geodesic-refactor(gated) — optimal refactoring pathgr-escape-velocity-calculator(gated) — effort to escape debt well
Chain-To
Section titled “Chain-To”test-verify— verify refactored code still passes all testscode-review— review the refactoring for unintended consequencesphysics-analysis— escalate to GR-based debt analysis
Execution Pattern
Section titled “Execution Pattern”| Scope | Pattern |
|---|---|
| Single-file refactor | GPT-4.1 only (Zero-Cost) |
| Cross-module refactor | GPT-4.1 draft → Claude Sonnet 4.6 boundary review |
| Batch refactor | 3× GPT-4.1 parallel → single Claude Sonnet 4.6 diff-review |
Never use a free model as final reviewer for refactors touching gov-*, qm-*, gr-*, or security primitives.
Example
Section titled “Example”{ "request": "The UserService class is 800 lines. Refactor it into cohesive modules."}Output: Refactoring plan, module boundary proposal, extracted code files, and a test compatibility check.