Skill

ctx-refactor

From ctx

Safely refactors code test-first: verifies/writes tests, one structural change at a time, preserves behavior. Use for 'refactor this', 'clean this up', reorganization.

Git

code-quality

testing

npx claudepluginhub activememory/ctx --plugin ctx

Tool Access

This skill is limited to using the following tools:

ReadGrepGlobEditWriteBash(go:*)Bash(make:*)Bash(git:*)

Preview

Refactor the specified code following strict safety rules.

SKILL.md

Similar Skills

refactor-code

Safely refactors code using tests to improve readability, cohesion, and maintainability without changing behavior. Triggers on 'refactor', 'clean up code', 'simplify', 'reduce complexity', 'technical debt'.

1 file

shipshitdev-library

Code Refactor Workflow

Guides refactoring code structure and modules to improve maintainability, readability, and performance while preserving external behavior and ensuring all tests pass.

hatch3r

Refactor Skill

Refactors code to improve structure, reduce duplication, and apply SRP/DRY principles without changing behavior. Use for incremental code quality enhancements with test verification.

aws-skills-for-claude-code

Stats

Parent Repo Stars41

Parent Repo Forks9

Last CommitMar 30, 2026

Actions

View Source View Plugin View on GitHub View README

Help us improve

Share bugs, ideas, or general feedback.

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.

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

Execution

Read .context/CONVENTIONS.md to load project patterns
Read the target code and its tests
If no tests exist, write them first (confirm with user)
Plan the refactoring steps: present to user before starting
Execute one step at a time, running tests between each
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.