ctx-refactor

Refactor the specified code following strict safety rules. Refactoring changes structure, not outcomes.

When to Use

• User says "refactor this", "clean this up", "simplify this"
• User wants to extract, rename, split, or reorganize code
• User says "this is messy" or "can we improve this"

When NOT to Use

• User wants to add new behavior (that's a feature, not a refactor)
• User wants a rename across the codebase (prefer /gitnexus-refactoring if GitNexus is available; otherwise use grep-based search to find all references before renaming)

Rules

Follow these in order. Do not skip steps.

1. Write or verify tests first: confirm existing behavior is captured before changing structure.
2. Preserve all existing behavior: refactoring changes structure, not outcomes. If a step would change observable behavior, stop and flag it as a separate task.
3. Make one structural change at a time: keep each step reviewable and revertible.
4. Run tests after each step: catch regressions immediately, not at the end.
5. Check project conventions: consult .context/CONVENTIONS.md to ensure the refactored code follows established patterns.

Execution

1. Read .context/CONVENTIONS.md to load project patterns
2. Read the target code and its tests
3. If no tests exist, write them first (confirm with user)
4. Plan the refactoring steps: present to user before starting
5. Execute one step at a time, running tests between each
6. After all steps, run make lint && make test

Output Format

Before starting, present the plan:

## Refactoring Plan: <target>

1. <step>: why
2. <step>: why
...

Tests to verify: <list>

After each step, report: what changed, tests still passing.