refactoring-code

Name: refactoring-code
Author: alexei-led

6installs5forks

How to install refactoring-code?

alexei-led/cc-thingz/refactoring-code

$npx -y skills add alexei-led/cc-thingz --skill refactoring-code

Installs into the current project.

Summary

Use this when many edits must preserve externally observable behavior. Stop if you cannot name the maintenance value and the behavior that must stay unchanged.

Files · 1

View on GitHub

SKILL.md

1	# Batch Refactoring
2
3	Use this when many edits must preserve externally observable behavior. Stop if you
4	cannot name the maintenance value and the behavior that must stay unchanged.
5
6	## Role-gated action
7
8	Detect capability from tools:
9
10	- Write-capable role: map scope, apply one batch, run verification.
11	- Read-only role: map scope and emit the refactor in the Proposed Changes contract. Apply nothing; run nothing.
12
13	## Route elsewhere
14
15	Do not use this for:
16
17	- one small edit that normal coding tools can handle
18	- behavior changes, bug fixes, or failing checks → `fixing-code`
19	- test-only cleanup, coverage, or TDD → `improving-tests`
20	- review findings without edits → `reviewing-code`
21	- target architecture design or repo-wide structural audit → architecture skills
22	- cosmetic churn with no maintenance value
23
24	## Language references
25
26	Load the matching reference for the language being refactored:
27
28	- C# /.NET: `references/csharp.md`
29	- Go: `references/go.md`
30	- Java/Kotlin: `references/java-kotlin.md`
31	- Python: `references/python.md`
32	- Rust: `references/rust.md`
33	- TypeScript/JavaScript: `references/typescript.md`
34
35	Unsupported language: use the general workflow in this file only.
36
37	## Evidence first
38
39	Before editing:
40
41	1. Define goal, non-goals, preservation target, and safety gate.
42	2. Map every affected site with text search and language-aware tools.
43	3. For renames, moves, extracts, splits, or broad restructures, use graph tools when available:
44	- GitNexus dry-run rename for renames; GitNexus context, impact, and query for callers, callees, execution flows, and string/dynamic refs.
45	- codegraph status first; if fresh, use codegraph context or affected to size dependency/call blast radius.
46	4. Treat stale graph indexes as no evidence. Refresh if allowed; otherwise fall back to search/LSP and report the gap.
47	5. Check non-code references when names or paths change: config, routes, DI wiring, serialization keys, CLI entries, generated sources, scripts, and docs.
48	6. Read representative implementation files and tests.
49	7. Add characterization tests at the public boundary when behavior is under-specified and risk is not low.
50
51	No mapped site, no edit.
52
53	## Batch rules
54
55	Good batches are small, reversible, and single-purpose:
56
57	- rename one symbol/concept and all callers
58	- move one module/function and its tests
59	- extract one cohesive responsibility behind the same public behavior
60	- remove one duplicate implementation after tests prove equivalence
61	- update one repeated pattern across mapped sites
62
63	Rules:
64
65	- Separate mechanical structure changes from logic changes.
66	- Do not rename many concepts while changing APIs or control flow.
67	- Prefer semantic refactoring tools; use precise text edits only for mapped sites.
68	- For public APIs, keep compatibility shims or deprecations unless the user approved a breaking change.
69	- Run narrow tests after each batch; run broader lint/type/test checks before the next batch or final report.
70	- Delete dead code exposed by the refactor. Do not hand-edit generated or vendored files unless the project regenerates them from source.
71
72	## Output
73
74	Engineer:
75
76	```text
77	REFACTOR COMPLETE
78	=================
79	Preservation target: <behavior that must not change>
80	Safety gate: <tests/checks used>
81	Files changed: N
82	Status: CLEAN \| NEEDS ATTENTION
83
84	Mapping:
85	- <tool/search> — <key affected sites or graph gap>
86
87	Changes:
88	- path:line — change
89
90	Verification:
91	- <command> — pass/fail
92	```
93
94	Reviewer:
95
96	```text
97	## Proposed Changes
98
99	Preservation target: <behavior that must not change>
100	Safety gate: <tests/checks the applier should run>
101
102	Mapping:
103	- <tool/search> — <affected sites or graph gap>
104
105	### Change 1: <brief description>
106
107	File: `path/to/file`
108	Action: CREATE \| MODIFY \| DELETE
109
110	Code:
111	<changed regions with enough context to locate them>
112
113	Rationale: <why this preserves behavior while improving structure>
114	```
115
116	For multi-file renames, list every mapped occurrence or explicitly mark ambiguous/unmapped references.
117
118	## Failure handling
119
120	- Scope unclear: ask which files/concept and what behavior to preserve.
121	- Tests/checks missing for risky code: ask to add characterization tests or shrink/defer the refactor.
122	- Tests fail after a batch: inspect or revert that batch before continuing.
123	- Required behavior change appears: stop and split into refactor first, then feature/fix.
124	- Graph tool missing or s

People who liked this also viewed

6 picks

Type

hyperframes-cliUse the HyperFrames CLI development loop: init, add, catalog, capture, lint, check, snapshot, compare, grade-compare, preview, play, present, beats, keyframes, single or batch render, publish, cloud, SkillsJul 2026262k37k
request-refactor-planSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026165k181k
analyze-projectRigor Analyze / Rigor Audit read-only skill for deep learning research repositories. Use when the user wants to read and understand a repository, inspect model structure and training or inference entrSkillsMay 2026161k507
explore-codeRigor Improve implementation leaf skill for auditable candidate implementation in deep learning research repositories. Use when the researcher explicitly authorizes exploratory work on an isolated braSkillsMay 2026161k507
ubiquitous-languageSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026160k181k
scaffold-exercisesSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026149k181k

refactoring-code

6installs5forks

View on GitHub

How to install refactoring-code?

alexei-led/cc-thingz/refactoring-code

$npx -y skills add alexei-led/cc-thingz --skill refactoring-code

Installs into the current project.

Summary

Use this when many edits must preserve externally observable behavior. Stop if you cannot name the maintenance value and the behavior that must stay unchanged.

Files · 1

View on GitHub

SKILL.md

1	# Batch Refactoring
2
3	Use this when many edits must preserve externally observable behavior. Stop if you
4	cannot name the maintenance value and the behavior that must stay unchanged.
5
6	## Role-gated action
7
8	Detect capability from tools:
9
10	- Write-capable role: map scope, apply one batch, run verification.
11	- Read-only role: map scope and emit the refactor in the Proposed Changes contract. Apply nothing; run nothing.
12
13	## Route elsewhere
14
15	Do not use this for:
16
17	- one small edit that normal coding tools can handle
18	- behavior changes, bug fixes, or failing checks → `fixing-code`
19	- test-only cleanup, coverage, or TDD → `improving-tests`
20	- review findings without edits → `reviewing-code`
21	- target architecture design or repo-wide structural audit → architecture skills
22	- cosmetic churn with no maintenance value
23
24	## Language references
25
26	Load the matching reference for the language being refactored:
27
28	- C# /.NET: `references/csharp.md`
29	- Go: `references/go.md`
30	- Java/Kotlin: `references/java-kotlin.md`
31	- Python: `references/python.md`
32	- Rust: `references/rust.md`
33	- TypeScript/JavaScript: `references/typescript.md`
34
35	Unsupported language: use the general workflow in this file only.
36
37	## Evidence first
38
39	Before editing:
40
41	1. Define goal, non-goals, preservation target, and safety gate.
42	2. Map every affected site with text search and language-aware tools.
43	3. For renames, moves, extracts, splits, or broad restructures, use graph tools when available:
44	- GitNexus dry-run rename for renames; GitNexus context, impact, and query for callers, callees, execution flows, and string/dynamic refs.
45	- codegraph status first; if fresh, use codegraph context or affected to size dependency/call blast radius.
46	4. Treat stale graph indexes as no evidence. Refresh if allowed; otherwise fall back to search/LSP and report the gap.
47	5. Check non-code references when names or paths change: config, routes, DI wiring, serialization keys, CLI entries, generated sources, scripts, and docs.
48	6. Read representative implementation files and tests.
49	7. Add characterization tests at the public boundary when behavior is under-specified and risk is not low.
50
51	No mapped site, no edit.
52
53	## Batch rules
54
55	Good batches are small, reversible, and single-purpose:
56
57	- rename one symbol/concept and all callers
58	- move one module/function and its tests
59	- extract one cohesive responsibility behind the same public behavior
60	- remove one duplicate implementation after tests prove equivalence
61	- update one repeated pattern across mapped sites
62
63	Rules:
64
65	- Separate mechanical structure changes from logic changes.
66	- Do not rename many concepts while changing APIs or control flow.
67	- Prefer semantic refactoring tools; use precise text edits only for mapped sites.
68	- For public APIs, keep compatibility shims or deprecations unless the user approved a breaking change.
69	- Run narrow tests after each batch; run broader lint/type/test checks before the next batch or final report.
70	- Delete dead code exposed by the refactor. Do not hand-edit generated or vendored files unless the project regenerates them from source.
71
72	## Output
73
74	Engineer:
75
76	```text
77	REFACTOR COMPLETE
78	=================
79	Preservation target: <behavior that must not change>
80	Safety gate: <tests/checks used>
81	Files changed: N
82	Status: CLEAN \| NEEDS ATTENTION
83
84	Mapping:
85	- <tool/search> — <key affected sites or graph gap>
86
87	Changes:
88	- path:line — change
89
90	Verification:
91	- <command> — pass/fail
92	```
93
94	Reviewer:
95
96	```text
97	## Proposed Changes
98
99	Preservation target: <behavior that must not change>
100	Safety gate: <tests/checks the applier should run>
101
102	Mapping:
103	- <tool/search> — <affected sites or graph gap>
104
105	### Change 1: <brief description>
106
107	File: `path/to/file`
108	Action: CREATE \| MODIFY \| DELETE
109
110	Code:
111	<changed regions with enough context to locate them>
112
113	Rationale: <why this preserves behavior while improving structure>
114	```
115
116	For multi-file renames, list every mapped occurrence or explicitly mark ambiguous/unmapped references.
117
118	## Failure handling
119
120	- Scope unclear: ask which files/concept and what behavior to preserve.
121	- Tests/checks missing for risky code: ask to add characterization tests or shrink/defer the refactor.
122	- Tests fail after a batch: inspect or revert that batch before continuing.
123	- Required behavior change appears: stop and split into refactor first, then feature/fix.
124	- Graph tool missing or s

People who liked this also viewed

6 picks

Type