refactor

Name: refactor
Author: testdouble

122stars12forks

How to install refactor?

testdouble/han/refactor

$npx -y skills add testdouble/han --skill refactor

Installs into the current project.

Summary

Restructure existing code without changing its behavior, through a test-gated refactoring loop: a named target, a green suite over that target before any edit, a planned sequence of small named refactorings, and the full suite re-run after every step. Use when the user wants to r

Files · 1

View on GitHub

SKILL.md

1	## Project Context
2
3	- git installed: !`which git 2>/dev/null \|\| echo "not installed"`
4	- current branch: !`git branch --show-current 2>/dev/null \|\| echo unknown`
5	- working tree: !`git status --porcelain 2>/dev/null \| head -5`
6	- CLAUDE.md: !`find . -maxdepth 1 -name "CLAUDE.md" -type f`
7	- project-discovery.md: !`find . -maxdepth 3 -name "project-discovery.md" -type f`
8
9	## Constraints (read before anything else)
10
11	This skill restructures existing production and test code in your working
12	tree. It is an execution skill, not a document generator. These constraints
13	shape every step and override any instinct to move faster. The canon they
14	derive from, with provenance, is in
15	[references/refactoring-discipline.md](./references/refactoring-discipline.md);
16	pull that reference when a step needs the full rule or a step feels off.
17
18	- Behavior preservation is the definition. A refactoring changes internal
19	structure without changing observable behavior. A change that alters
20	behavior is not a refactoring done badly; it is not a refactoring at all.
21	When a planned step turns out to require a behavior change, it leaves this
22	skill's scope: defer it with a note naming the behavior change it needs.
23	- Tests are the license to refactor. No edit until the full suite has
24	been run, observed green, and the target's behavior is covered. If coverage
25	of the target cannot be established, stop and offer the characterization
26	path in the reference; never refactor blind.
27	- Small named steps, green to green. Each step is one named refactoring
28	with a bounded mechanic (extract function, rename, move, inline, and so
29	on), and the suite runs after every step. A red suite after a step means
30	revert the step, not patch forward.
31	- The declared scope is a contract. The target named in Step 1 bounds
32	every edit. When a step starts pulling in files outside that scope, stop,
33	report the spread, and let the user re-scope. Spreading edits are how a
34	refactoring silently becomes a rewrite.
35	- Never alongside an active tdd loop. If the working tree shows a
36	red-green cycle in flight (failing tests, a half-implemented behavior), do
37	not run: the refactor step of `/tdd` owns cleanup inside the loop, and
38	restructuring while a test is red violates the two-hats rule both skills
39	share.
40	- Refactor-only changes. No behavior fixes, no features, no drive-by bug
41	fixes, even when you spot one. Record what you found and leave it. If the
42	user asks for commits, each commit contains refactoring only.
43	- YAGNI governs the plan. Apply
44	[../../references/yagni-rule.md](../../references/yagni-rule.md): every
45	refactoring in the plan needs evidence the code has a reason to change (a
46	review finding, named duplication, a confusing read documented by the user,
47	upcoming work in that area). Removing duplication is the job; adding
48	speculative abstraction, configuration, or indirection is not. Defer
49	evidence-free items with a reopen trigger.
50
51	# Refactor
52
53	## Step 1: Bind the Target and Resolve Project Config
54
55	Bind the target. Resolve the request to a named target: specific files or
56	directories, a named code smell in a named place, or the refactoring findings
57	in a provided document (a `/code-review` report, an `/architectural-analysis`
58	report, or equivalent). When a findings document is given, extract only the
59	refactoring-shaped findings (structural suggestions, duplication, naming,
60	coupling) and record each finding's ID so the summary can trace back to it.
61	If the request is open-ended ("clean up the codebase", "improve quality")
62	with no named target, ask the user for one before doing anything: open-ended
63	refactoring runs are the documented failure mode this skill exists to avoid,
64	and a wrong guess here burns the whole run.
65
66	Resolve commands. Read CLAUDE.md's `## Project Discovery` section for the
67	test command (under `### Commands and Tests`), the lint command, th

People who liked this also viewed

6 picks

Type

refactor

122stars12forks

View on GitHub

How to install refactor?

testdouble/han/refactor

$npx -y skills add testdouble/han --skill refactor

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	## Project Context
2
3	- git installed: !`which git 2>/dev/null \|\| echo "not installed"`
4	- current branch: !`git branch --show-current 2>/dev/null \|\| echo unknown`
5	- working tree: !`git status --porcelain 2>/dev/null \| head -5`
6	- CLAUDE.md: !`find . -maxdepth 1 -name "CLAUDE.md" -type f`
7	- project-discovery.md: !`find . -maxdepth 3 -name "project-discovery.md" -type f`
8
9	## Constraints (read before anything else)
10
11	This skill restructures existing production and test code in your working
12	tree. It is an execution skill, not a document generator. These constraints
13	shape every step and override any instinct to move faster. The canon they
14	derive from, with provenance, is in
15	[references/refactoring-discipline.md](./references/refactoring-discipline.md);
16	pull that reference when a step needs the full rule or a step feels off.
17
18	- Behavior preservation is the definition. A refactoring changes internal
19	structure without changing observable behavior. A change that alters
20	behavior is not a refactoring done badly; it is not a refactoring at all.
21	When a planned step turns out to require a behavior change, it leaves this
22	skill's scope: defer it with a note naming the behavior change it needs.
23	- Tests are the license to refactor. No edit until the full suite has
24	been run, observed green, and the target's behavior is covered. If coverage
25	of the target cannot be established, stop and offer the characterization
26	path in the reference; never refactor blind.
27	- Small named steps, green to green. Each step is one named refactoring
28	with a bounded mechanic (extract function, rename, move, inline, and so
29	on), and the suite runs after every step. A red suite after a step means
30	revert the step, not patch forward.
31	- The declared scope is a contract. The target named in Step 1 bounds
32	every edit. When a step starts pulling in files outside that scope, stop,
33	report the spread, and let the user re-scope. Spreading edits are how a
34	refactoring silently becomes a rewrite.
35	- Never alongside an active tdd loop. If the working tree shows a
36	red-green cycle in flight (failing tests, a half-implemented behavior), do
37	not run: the refactor step of `/tdd` owns cleanup inside the loop, and
38	restructuring while a test is red violates the two-hats rule both skills
39	share.
40	- Refactor-only changes. No behavior fixes, no features, no drive-by bug
41	fixes, even when you spot one. Record what you found and leave it. If the
42	user asks for commits, each commit contains refactoring only.
43	- YAGNI governs the plan. Apply
44	[../../references/yagni-rule.md](../../references/yagni-rule.md): every
45	refactoring in the plan needs evidence the code has a reason to change (a
46	review finding, named duplication, a confusing read documented by the user,
47	upcoming work in that area). Removing duplication is the job; adding
48	speculative abstraction, configuration, or indirection is not. Defer
49	evidence-free items with a reopen trigger.
50
51	# Refactor
52
53	## Step 1: Bind the Target and Resolve Project Config
54
55	Bind the target. Resolve the request to a named target: specific files or
56	directories, a named code smell in a named place, or the refactoring findings
57	in a provided document (a `/code-review` report, an `/architectural-analysis`
58	report, or equivalent). When a findings document is given, extract only the
59	refactoring-shaped findings (structural suggestions, duplication, naming,
60	coupling) and record each finding's ID so the summary can trace back to it.
61	If the request is open-ended ("clean up the codebase", "improve quality")
62	with no named target, ask the user for one before doing anything: open-ended
63	refactoring runs are the documented failure mode this skill exists to avoid,
64	and a wrong guess here burns the whole run.
65
66	Resolve commands. Read CLAUDE.md's `## Project Discovery` section for the
67	test command (under `### Commands and Tests`), the lint command, th

People who liked this also viewed

6 picks

Type