refactoring-code

description

Batch behavior-preserving refactors for multi-file, repeated-pattern, large-file, rename, move, extract, split, or restructure work. Use for "refactor across files", "batch rename", "update pattern everywhere", large files (500+ lines), or 5+ coordinated edits in one file. NOT for single targeted edits, behavior changes or bug fixes (use fixing-code), test-only refactors (use improving-tests), code review (use reviewing-code), or architecture redesign (use architecture-design/review).

name

refactoring-code

Batch Refactoring

Follow the base skill. This Pi overlay only defines tool use and execution details.

Role-gated action

Detect capability from tools:

• Write-capable role: map scope, apply one batch, run verification.
• Read-only role: map scope and emit the refactor in the Proposed Changes contract. Apply nothing; run nothing.

Route elsewhere

Do not use this for:

• one small edit that normal coding tools can handle
• behavior changes, bug fixes, or failing checks → fixing-code
• test-only cleanup, coverage, or TDD → improving-tests
• review findings without edits → reviewing-code
• target architecture design or repo-wide structural audit → architecture skills
• cosmetic churn with no maintenance value

Language references

Load the matching reference for the language being refactored:

• C# /.NET: references/csharp.md
• Go: references/go.md
• Java/Kotlin: references/java-kotlin.md
• Python: references/python.md
• Rust: references/rust.md
• TypeScript/JavaScript: references/typescript.md

Unsupported language: use the general workflow in this file only.

Evidence first

Before editing:

1. Define goal, non-goals, preservation target, and safety gate.
2. Map every affected site with text search and language-aware tools.
3. For renames, moves, extracts, splits, or broad restructures, use graph tools when available:
   • GitNexus dry-run rename for renames; GitNexus context, impact, and query for callers, callees, execution flows, and string/dynamic refs.
   • codegraph status first; if fresh, use codegraph context or affected to size dependency/call blast radius.
4. Treat stale graph indexes as no evidence. Refresh if allowed; otherwise fall back to search/LSP and report the gap.
5. Check non-code references when names or paths change: config, routes, DI wiring, serialization keys, CLI entries, generated sources, scripts, and docs.
6. Read representative implementation files and tests.
7. Add characterization tests at the public boundary when behavior is under-specified and risk is not low.

No mapped site, no edit.

Batch rules

Good batches are small, reversible, and single-purpose:

• rename one symbol/concept and all callers
• move one module/function and its tests
• extract one cohesive responsibility behind the same public behavior
• remove one duplicate implementation after tests prove equivalence
• update one repeated pattern across mapped sites

Rules:

• Separate mechanical structure changes from logic changes.
• Do not rename many concepts while changing APIs or control flow.
• Prefer semantic refactoring tools; use precise text edits only for mapped sites.
• For public APIs, keep compatibility shims or deprecations unless the user approved a breaking change.
• Run narrow tests after each batch; run broader lint/type/test checks before the next batch or final report.
• Delete dead code exposed by the refactor. Do not hand-edit generated or vendored files unless the project regenerates them from source.

Output

Engineer:

REFACTOR COMPLETE
=================
Preservation target: <behavior that must not change>
Safety gate: <tests/checks used>
Files changed: N
Status: CLEAN | NEEDS ATTENTION

Mapping:
- <tool/search> — <key affected sites or graph gap>

Changes:
- path:line — change

Verification:
- <command> — pass/fail

Reviewer:

## Proposed Changes

Preservation target: <behavior that must not change>
Safety gate: <tests/checks the applier should run>

Mapping:
- <tool/search> — <affected sites or graph gap>

### Change 1: <brief description>

File: `path/to/file`
Action: CREATE | MODIFY | DELETE

Code:
<changed regions with enough context to locate them>

Rationale: <why this preserves behavior while improving structure>

For multi-file renames, list every mapped occurrence or explicitly mark ambiguous/unmapped references.

Failure handling

• Scope unclear: ask which files/concept and what behavior to preserve.
• Tests/checks missing for risky code: ask to add characterization tests or shrink/defer the refactor.
• Tests fail after a batch: inspect or revert that batch before continuing.
• Required behavior change appears: stop and split into refactor first, then feature/fix.
• Graph tool missing or stale: report the gap and use search/LSP evidence instead.
• Generated or vendored occurrence: skip it unless regeneration is part of the verified workflow.

Pi tool rules

• Pi has no tool-level read-only enforcement; follow the active agent's role directive (engineer applies one batch, reviewer proposes only) rather than inferring the role from tool availability.
• Use bash (rg, fd, git grep) to map affected sites; Pi has no dedicated grep/glob tool.
• Use edit for existing files and write only for new files.
• Prefer installed Task* tools to track multi-batch refactors across steps; fall back to todo when that task toolset is unavailable.
• Use ask_user_question when scope, preservation target, or safety gate is unclear.

Output on Pi

Use the base skill's Engineer and Reviewer output contracts exactly, unmodified.