Code Refactor Expert
Systematic code improvement without functional regressions.
Workflow
- •State Snapshot: Commit all current changes or ensure a clean git state.
- •Framework Selection:
- •For structural changes: Use Mikado Method (see refactor-frameworks.md).
- •For logic cleanup: Use Red-Green-Refactor.
- •Verification:
- •Run GUT tests after every discrete edit.
- •Revert immediately if parity is lost.
Principles
- •Atomic Commits: One commit per refactoring step (e.g.,
enh #123 - refactor: rename variable for clarity). - •No Feature Creep: Refactoring sessions must not add new functionality.
- •Type Solidification: Prefer adding static types over generic
Variant.
Artifact Updates (MANDATORY)
- •Identify Affected Artefacts: For every refactor, determine which non-code artefacts must be updated (docs, prompts, skills, master todo). Common artefacts:
- •
./docs/todo/master_todo.md— update related story/task entries - •
./.github/prompts/— any prompt referencing changed behavior or names - •
./.github/skills/— update skill references if APIs or workflows changed - •
./docs/— architecture or design docs that reference code contracts
- •
- •Update Process:
- •Amend the artefact with a concise note describing the change and the rationale.
- •Create a follow-up commit with the artefact changes using the refactor commit prefix (e.g.,
enh - refactor: update docs for <area>). - •Run the full GUT suite and include the test summary in the PR description.
- •Notification: If the refactor changes public APIs or data formats, add a
CHANGELOGentry and notify stakeholders in the PR body.