refactoring

Name: refactoring
Author: dan-the-dev

27stars0forks

How to install refactoring?

dan-the-dev/xp-developer-skills/refactoring

$npx -y skills add dan-the-dev/xp-developer-skills --skill refactoring

Installs into the current project.

Summary

Martin Fowler–style refactoring — change the internal structure of code without changing observable behavior. Baby steps on a green baseline: one mechanical transformation at a time, tests stay green, revert on red. Separates refactoring from adding features (“two hats”), uses na

Files · 1

View on GitHub

SKILL.md

1	# Fowler-style refactoring (behavior-preserving)
2
3	## Mission
4
5	Refactoring (noun): a behavior-preserving change that makes code easier to understand or cheaper to change.
6
7	Refactoring (verb): applying such changes in small, reversible steps so that — like tidying LEGO without turning the spaceship into a car — the program does the same thing before and after; only structure, names, and arrangement improve.
8
9	Think: clean your room while the toys still work — one small tidy-up at a time, check that nothing broke after each step, and do not sneak in new toys (no new features during the same edits).
10
11	Optimize for:
12
13	- Safety — start from a green test baseline; end each step green
14	- Small steps — one mechanical change per step; if tests go red, undo that step and try smaller
15	- No behavior change — same inputs and outputs, same observable side effects
16	- Clarity — better names, clearer boundaries, less accidental duplication
17	- Reviewability — commits readers can trust as “structure only”
18
19	This skill is for dedicated refactoring sessions and for the REFACTOR phase inside TDD. It does not replace bugfix (fix wrong behavior), feature work (new behavior), or `skills/legacy-testing` (harness and characterization when code lacks tests) — compose with those skills ([references/two-hats-and-scope.md](references/two-hats-and-scope.md)).
20
21	---
22
23	## Golden rules (integrated)
24
25	\| Rule \| Practice \|
26	\|------\|----------\|
27	\| One small tidy-up at a time \| Single rename, one extract, one move — then run tests ([references/baby-steps-and-revert.md](references/baby-steps-and-revert.md)) \|
28	\| Green light \| Start green; after every step, green again; red → revert last step ([references/testing-and-safety-net.md](references/testing-and-safety-net.md)) \|
29	\| No new toys \| No new behavior, APIs, or “while we’re here” features ([references/two-hats-and-scope.md](references/two-hats-and-scope.md)) \|
30	\| Rule of three \| Wait for real repetition before abstracting; don’t DRY noise ([references/duplication-abstraction-and-naming.md](references/duplication-abstraction-and-naming.md)) \|
31	\| Good names \| Rename so code tells a story; same discipline in tests ([references/duplication-abstraction-and-naming.md](references/duplication-abstraction-and-naming.md)) \|
32	\| Leave it better \| Boy Scout rule: small local improvement when you touch code; scope larger refactors explicitly \|
33
34	---
35
36	## Two hats (Fowler)
37
38	At any moment you wear one hat:
39
40	- Add feature — extend behavior (tests may go red → green).
41	- Refactor — no new behavior; tests must stay green throughout.
42
43	Do not swap hats mid-commit. If you need both, finish one slice (including tests and commit) before the other.
44
45	---
46
47	## Relationship to other skills
48
49	\| Skill \| Role \|
50	\|-------\|------\|
51	\| `skills/tdd` \| Inner loop; REFACTOR step is this same discipline at tight proximity ([`refactor-discipline.md`](../tdd/references/refactor-discipline.md)) \|
52	\| `skills/bugfix` \| Fix wrong behavior first; refactoring is not a substitute for reproduction + RED \|
53	\| `skills/atdd` \| Acceptance defines what; refactoring does not change what \|
54	\| `skills/legacy-testing` \| Without tests, characterization and seams before large refactors ([`SKILL.md`](../legacy-testing/SKILL.md)) \|
55
56	Tests and design (Cupac): Prefer tests coupled to behavior, not structure, so internal moves do not break the suite for the wrong reason ([references/tests-and-design.md](references/tests-and-design.md)).
57
58	---
59
60	## Workflow (language-agnostic)
61
62	Shared delivery rules: [`docs/delivery-process.md`](../../docs/delivery-process.md) (§7 two hats, §9 step size, §2 verification) and [`docs/project-verification.md`](../../docs/project-verification.md) (re-verify after every mechanical step; lint and SonarQube before done).
63
64	1. Goal — one sentence: what will be easier after this (e.g. “extract pricing so policies are isolated”).
65	2. Baseline — checkout branch; all relevant automated checks green for this scope (fix unrelated reds first or narrow scope).
66	3. Plan — name 1–3 Fowler-style refactorings you will compose ([references/catalog-and-composing-refactorings.md](references/c

People who liked this also viewed

6 picks

Type

refactoring

27stars0forks

View on GitHub

How to install refactoring?

dan-the-dev/xp-developer-skills/refactoring

$npx -y skills add dan-the-dev/xp-developer-skills --skill refactoring

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Fowler-style refactoring (behavior-preserving)
2
3	## Mission
4
5	Refactoring (noun): a behavior-preserving change that makes code easier to understand or cheaper to change.
6
7	Refactoring (verb): applying such changes in small, reversible steps so that — like tidying LEGO without turning the spaceship into a car — the program does the same thing before and after; only structure, names, and arrangement improve.
8
9	Think: clean your room while the toys still work — one small tidy-up at a time, check that nothing broke after each step, and do not sneak in new toys (no new features during the same edits).
10
11	Optimize for:
12
13	- Safety — start from a green test baseline; end each step green
14	- Small steps — one mechanical change per step; if tests go red, undo that step and try smaller
15	- No behavior change — same inputs and outputs, same observable side effects
16	- Clarity — better names, clearer boundaries, less accidental duplication
17	- Reviewability — commits readers can trust as “structure only”
18
19	This skill is for dedicated refactoring sessions and for the REFACTOR phase inside TDD. It does not replace bugfix (fix wrong behavior), feature work (new behavior), or `skills/legacy-testing` (harness and characterization when code lacks tests) — compose with those skills ([references/two-hats-and-scope.md](references/two-hats-and-scope.md)).
20
21	---
22
23	## Golden rules (integrated)
24
25	\| Rule \| Practice \|
26	\|------\|----------\|
27	\| One small tidy-up at a time \| Single rename, one extract, one move — then run tests ([references/baby-steps-and-revert.md](references/baby-steps-and-revert.md)) \|
28	\| Green light \| Start green; after every step, green again; red → revert last step ([references/testing-and-safety-net.md](references/testing-and-safety-net.md)) \|
29	\| No new toys \| No new behavior, APIs, or “while we’re here” features ([references/two-hats-and-scope.md](references/two-hats-and-scope.md)) \|
30	\| Rule of three \| Wait for real repetition before abstracting; don’t DRY noise ([references/duplication-abstraction-and-naming.md](references/duplication-abstraction-and-naming.md)) \|
31	\| Good names \| Rename so code tells a story; same discipline in tests ([references/duplication-abstraction-and-naming.md](references/duplication-abstraction-and-naming.md)) \|
32	\| Leave it better \| Boy Scout rule: small local improvement when you touch code; scope larger refactors explicitly \|
33
34	---
35
36	## Two hats (Fowler)
37
38	At any moment you wear one hat:
39
40	- Add feature — extend behavior (tests may go red → green).
41	- Refactor — no new behavior; tests must stay green throughout.
42
43	Do not swap hats mid-commit. If you need both, finish one slice (including tests and commit) before the other.
44
45	---
46
47	## Relationship to other skills
48
49	\| Skill \| Role \|
50	\|-------\|------\|
51	\| `skills/tdd` \| Inner loop; REFACTOR step is this same discipline at tight proximity ([`refactor-discipline.md`](../tdd/references/refactor-discipline.md)) \|
52	\| `skills/bugfix` \| Fix wrong behavior first; refactoring is not a substitute for reproduction + RED \|
53	\| `skills/atdd` \| Acceptance defines what; refactoring does not change what \|
54	\| `skills/legacy-testing` \| Without tests, characterization and seams before large refactors ([`SKILL.md`](../legacy-testing/SKILL.md)) \|
55
56	Tests and design (Cupac): Prefer tests coupled to behavior, not structure, so internal moves do not break the suite for the wrong reason ([references/tests-and-design.md](references/tests-and-design.md)).
57
58	---
59
60	## Workflow (language-agnostic)
61
62	Shared delivery rules: [`docs/delivery-process.md`](../../docs/delivery-process.md) (§7 two hats, §9 step size, §2 verification) and [`docs/project-verification.md`](../../docs/project-verification.md) (re-verify after every mechanical step; lint and SonarQube before done).
63
64	1. Goal — one sentence: what will be easier after this (e.g. “extract pricing so policies are isolated”).
65	2. Baseline — checkout branch; all relevant automated checks green for this scope (fix unrelated reds first or narrow scope).
66	3. Plan — name 1–3 Fowler-style refactorings you will compose ([references/catalog-and-composing-refactorings.md](references/c

People who liked this also viewed

6 picks

Type