care-refactoring

Files (1)

• SKILL.md

SKILL.md (first lines)

# Care Refactoring

Use this skill when the goal is to make code easier to work with while preserving behavior. Do not use it as permission for broad rewrites.

## Refactor Test

Before changing code, answer these questions:

- What behavior must stay identical?
- What concrete pain does the refactor remove?
- What files or modules are in scope?
- What files are explicitly out of scope?
- What test, snapshot, or smoke proves behavior did not move?

If the benefit is vague, keep the change smaller.

## Workflow

1. Read the existing code path and local conventions.
2. Identify the smallest structural change that removes the real pain.
3. Add or run characterization coverage when behavior is not already protected.
4. Refactor in small steps, keeping public contracts stable.
5. Avoid mixing refactor with product behavior, copy, styling, or dependency changes.
6. Run targeted tests and any cheap type/lint/build gate.
7. Inspect the diff for accidental behavior changes, dead code, and widened API surface.

## Good Refactor Signals

- duplicated logic is consolidated behind an existing local pattern;
- names make existing behavior easier to read;
- module boundaries get clearer without new abstractions for their own sake;
- tests become simpler or more focused;
- future feature work has fewer files to touch.

## Stop Conditions

Stop or split the work when:

- the refactor changes user-visible behavior;
- the diff crosses unrelated ownership boundaries;
- a new abstraction is harder to explain than the code it replaced;
- tests are missing for risky behavior;
- the change starts requiring new dependencies or architecture choices.

## Final Check

Report:

- what behavior was preserved;
- what structure changed;
- what checks were run;
- any residual risk or follow-up that should not be hidden inside the refactor.

From iKairoseki/codex-agent-coordination, MIT.

More from iKairoseki/codex-agent-coordination