refactor

Files (1)

• SKILL.md

SKILL.md (first lines)

Execute a safe, systematic refactoring workflow on the target scope.

Task: the task/scope the user described when invoking this skill (if none given, ask or infer from context)

## Phase 1: Analysis
Do the analysis yourself:
- **Code smells** (see `~/.codex/skills/code-smells`): long functions, deep nesting, duplication, large classes, long parameter lists, feature envy, primitive obsession, dead code.
- **Dependencies & coupling**: map module dependency direction, identify tight coupling and leaf vs core modules.
Synthesize into a unified findings list.

## Phase 2: Refactoring Plan
Present findings with severity ratings. Create a **safe refactoring order** based on:
1. Dependency direction (leaf modules first, core last)
2. Test coverage (well-tested first; untested code needs characterization tests first)
3. Risk level (pure functions → utilities → business logic → public API)

Each step specifies: target file(s), smell addressed, refactoring pattern (Extract Method, Move Function, Replace Conditional with Polymorphism, etc.), and that behavior MUST remain identical.

**Wait for user approval before proceeding.**

## Phase 3: Test Baseline
1. Run the full test suite → record baseline pass count.
2. If no tests exist for target code, write characterization tests first.
3. Store baseline: `build PASS | lint PASS | test X/Y PASS`.

## Phase 4: Execution
For each approved step:
1. Apply ONE refactoring pattern at a time.
2. Run build + lint + test immediately after.
3. Tests fail → revert that step and report. Never fix forward.
4. Tests pass → commit atomically (`refactor(scope): pattern applied`) → next step.
Execute sequentially in leaf → root order (dependent modules strictly sequential).

## Phase 5: Verification
Run full build + lint + full test suite. Compare test count: baseline vs current (must be equal or greater).
Distinguish failure cause:
- **Breakage caused by a refactoring step** (green before, now fails) → revert that step immediately.
- **Pre-existing failures or environment/build issues unrelated to the refactor** → fix separately (root-cause, minimal diffs), don't revert refactoring.

## Phase 6: Review
Review the refactoring yourself: verify (1) no behavior changes, (2) improved structure, (3) no regressions.

## Phase 7: Report
```
## Refactoring Report
### Before → After
| Metric | Before | After |
| Files changed / Lines removed / Lines added / Avg function length / Max nesting / Test count |
### Applied Refactorings
| # | Pattern | Target | Result |
### Smells Resolved
- [x] ...
### Remaining (deferred)
- [ ] ... — reason
### Verification
Build: PASS | Lint: PASS | Tests: X/Y PASS
```

## Rules
- NEVER change behavior. Refactoring = same behavior, better structure.
- ONE pattern per commit — easy to revert.
- TEST FIRST. No refactoring without a green baseline.
- If a step breaks a previously-green test, revert that step immediately — don't fix forward.
- Don't refactor code you don't understand. Read it first.
- Preserve public API unless the user explicitly approves breaking changes.

From Hbin77/codex-kit, MIT.

More from Hbin77/codex-kit