cm-reactor

Name: cm-reactor
Author: tody-agent

47stars23forks

How to install cm-reactor?

tody-agent/codymaster/cm-reactor

$npx -y skills add tody-agent/codymaster --skill cm-reactor

Installs into the current project.

Summary

Strategic codebase re-direction when requirements change, architecture doesn't fit, or tech debt blocks progress. TRIZ-powered pivot protocol for large codebases.

Files · 1

View on GitHub

SKILL.md

1	# Reactor — Strategic Codebase Re-direction
2
3	> When the code works but the direction is wrong, you don't debug — you REACT.
4	> TRIZ-powered protocol for pivoting large codebases without losing stability.
5
6	## When to Use
7
8	ALWAYS when:
9	- Requirements changed significantly after code was built
10	- Architecture no longer fits the problem (wrong patterns, wrong abstractions)
11	- 3+ patches on the same area — symptom of structural mismatch
12	- Tech debt blocks new feature development
13	- "We need to rewrite X" — STOP. Use this skill first.
14	- Migrating from one framework/library/pattern to another
15	- Post-mortem reveals systemic issues needing strategic change
16
17	Skip when:
18	- Simple bug fix → use `cm-debugging`
19	- Routine refactoring (extract method, rename) → use `cm-clean-code`
20	- New project from scratch → use `cm-project-bootstrap`
21	- Small scope change (< 5 files affected) → just refactor directly
22
23	## The Iron Law
24
25	```
26	NO REWRITE WITHOUT REACTOR ANALYSIS FIRST
27	```
28
29	Rewrites fail 70% of the time. Incremental strategic migration succeeds 90% of the time.
30
31	## TRIZ Principles Applied
32
33	\| # \| Principle \| How Applied \|
34	\|---\|-----------\|-------------\|
35	\| #35 \| Parameter Change \| Change the fundamental parameter (language, pattern, architecture) — not the symptom \|
36	\| #28 \| Mechanics Substitution \| Replace one mechanism with a more effective one (OOP → FP, REST → GraphQL, etc.) \|
37	\| #13 \| The Other Way Around \| Instead of adapting new code to old architecture, adapt old architecture to new requirements \|
38	\| #25 \| Self-Service \| Design the migration so each component can migrate independently \|
39	\| #1 \| Segmentation \| Break monolithic change into independent migration units \|
40	\| #10 \| Prior Action \| Prepare the codebase (interfaces, adapters) BEFORE the actual migration \|
41
42	## The 5-Phase Process
43
44	```
45	Phase 1: ASSESS → Understand what's wrong and why (not just symptoms)
46	Phase 2: MAP → Trace all dependencies and blast radius
47	Phase 3: DESIGN → Plan the migration path with strangler fig pattern
48	Phase 4: EXECUTE → Migrate incrementally, one unit at a time
49	Phase 5: VERIFY → Confirm direction is correct + clean up old code
50	```
51
52	### Phase 1: ASSESS — Identify the Contradiction
53
54	> Goal: Find the TRIZ contradiction — what do we WANT vs what BLOCKS us?
55
56	1. State the current direction:
57	```
58	Current: We built [X architecture/pattern/structure]
59	Problem: It doesn't support [Y requirement/scale/use case]
60	```
61
62	2. Identify the contradiction:
63	```
64	We WANT: [desired capability]
65	But: [current architecture] prevents it because [technical reason]
66
67	TRIZ Contradiction:
68	Improving [parameter A] worsens [parameter B]
69	Example: "Improving modularity worsens performance"
70	"Improving flexibility worsens type safety"
71	```
72
73	3. Define the Ideal Final Result (IFR):
74	```
75	The system ITSELF [achieves the goal]
76	WITHOUT [the current blocking factor]
77	WHILE maintaining [what currently works well]
78	```
79
80	4. Scope assessment:
81	```
82	Files affected: [count from codeintell or grep]
83	Components affected: [list]
84	Tests affected: [count]
85	External API changes: [yes/no — breaking change?]
86	Estimated effort: [S/M/L/XL]
87	Risk level: [Low/Medium/High/Critical]
88	```
89
90	### Phase 2: MAP — Dependency Analysis
91
92	> Goal: Know exactly what touches what before changing anything.
93
94	1. Use Code Intelligence (if available):
95	```
96	codegraph_impact("target_symbol", depth=3)
97	→ Shows all callers, dependencies, affected files
98
99	codegraph_context("target_module")
100	→ Shows architecture around the area
101	```
102
103	2. Manual mapping (if codegraph unavailable):
104	```
105	grep -rn "import.*{module}" src/
106	grep -rn "{function_name}" src/
107	→ Build dependency tree manually
108	```
109
110	3. Categorize files by migration priority:
111
112	\| Category \| Description \| Action \|
113	\|----------\|-------------\|--------\|
114	\| Core \| The files that MUST change for the new direction \| Migrate first \|
115	\| Dependent \| Files that import/use Core files \| Migrate after Core, use adapters \|
116	\| Peripheral \| Files loosely connected \| Migrate last or leave untouched \|
117	\| Dead \| Files no longer needed after migration \| Flag for deletion in Phase 5 \|
118
119	4. Output: Migration Map Document
120	```markdown
121	## Migration Map: [Initiative Name]
122
123	### Core (must change): [N files]
124	- file_a.ts → [what changes]
125	- file_b.ts → [what changes]
126
127	### Dependent (affected): [N files]
128	- file_c.ts → [how affected]
129
130	### Peripheral (optional): [N files]
131	- file_d.ts → [minimal change]
132
133	### Dead (remove after): [N files]
134	- old_module.ts → DELETE after migration complete
135	```
136
137	### Phase 3: DESIGN — Strangler Fig Migration
138
139	> Goal: Design an

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

cm-reactor

47stars23forks

View on GitHub

How to install cm-reactor?

tody-agent/codymaster/cm-reactor

$npx -y skills add tody-agent/codymaster --skill cm-reactor

Installs into the current project.

Summary

Strategic codebase re-direction when requirements change, architecture doesn't fit, or tech debt blocks progress. TRIZ-powered pivot protocol for large codebases.

Files · 1

View on GitHub

SKILL.md

1	# Reactor — Strategic Codebase Re-direction
2
3	> When the code works but the direction is wrong, you don't debug — you REACT.
4	> TRIZ-powered protocol for pivoting large codebases without losing stability.
5
6	## When to Use
7
8	ALWAYS when:
9	- Requirements changed significantly after code was built
10	- Architecture no longer fits the problem (wrong patterns, wrong abstractions)
11	- 3+ patches on the same area — symptom of structural mismatch
12	- Tech debt blocks new feature development
13	- "We need to rewrite X" — STOP. Use this skill first.
14	- Migrating from one framework/library/pattern to another
15	- Post-mortem reveals systemic issues needing strategic change
16
17	Skip when:
18	- Simple bug fix → use `cm-debugging`
19	- Routine refactoring (extract method, rename) → use `cm-clean-code`
20	- New project from scratch → use `cm-project-bootstrap`
21	- Small scope change (< 5 files affected) → just refactor directly
22
23	## The Iron Law
24
25	```
26	NO REWRITE WITHOUT REACTOR ANALYSIS FIRST
27	```
28
29	Rewrites fail 70% of the time. Incremental strategic migration succeeds 90% of the time.
30
31	## TRIZ Principles Applied
32
33	\| # \| Principle \| How Applied \|
34	\|---\|-----------\|-------------\|
35	\| #35 \| Parameter Change \| Change the fundamental parameter (language, pattern, architecture) — not the symptom \|
36	\| #28 \| Mechanics Substitution \| Replace one mechanism with a more effective one (OOP → FP, REST → GraphQL, etc.) \|
37	\| #13 \| The Other Way Around \| Instead of adapting new code to old architecture, adapt old architecture to new requirements \|
38	\| #25 \| Self-Service \| Design the migration so each component can migrate independently \|
39	\| #1 \| Segmentation \| Break monolithic change into independent migration units \|
40	\| #10 \| Prior Action \| Prepare the codebase (interfaces, adapters) BEFORE the actual migration \|
41
42	## The 5-Phase Process
43
44	```
45	Phase 1: ASSESS → Understand what's wrong and why (not just symptoms)
46	Phase 2: MAP → Trace all dependencies and blast radius
47	Phase 3: DESIGN → Plan the migration path with strangler fig pattern
48	Phase 4: EXECUTE → Migrate incrementally, one unit at a time
49	Phase 5: VERIFY → Confirm direction is correct + clean up old code
50	```
51
52	### Phase 1: ASSESS — Identify the Contradiction
53
54	> Goal: Find the TRIZ contradiction — what do we WANT vs what BLOCKS us?
55
56	1. State the current direction:
57	```
58	Current: We built [X architecture/pattern/structure]
59	Problem: It doesn't support [Y requirement/scale/use case]
60	```
61
62	2. Identify the contradiction:
63	```
64	We WANT: [desired capability]
65	But: [current architecture] prevents it because [technical reason]
66
67	TRIZ Contradiction:
68	Improving [parameter A] worsens [parameter B]
69	Example: "Improving modularity worsens performance"
70	"Improving flexibility worsens type safety"
71	```
72
73	3. Define the Ideal Final Result (IFR):
74	```
75	The system ITSELF [achieves the goal]
76	WITHOUT [the current blocking factor]
77	WHILE maintaining [what currently works well]
78	```
79
80	4. Scope assessment:
81	```
82	Files affected: [count from codeintell or grep]
83	Components affected: [list]
84	Tests affected: [count]
85	External API changes: [yes/no — breaking change?]
86	Estimated effort: [S/M/L/XL]
87	Risk level: [Low/Medium/High/Critical]
88	```
89
90	### Phase 2: MAP — Dependency Analysis
91
92	> Goal: Know exactly what touches what before changing anything.
93
94	1. Use Code Intelligence (if available):
95	```
96	codegraph_impact("target_symbol", depth=3)
97	→ Shows all callers, dependencies, affected files
98
99	codegraph_context("target_module")
100	→ Shows architecture around the area
101	```
102
103	2. Manual mapping (if codegraph unavailable):
104	```
105	grep -rn "import.*{module}" src/
106	grep -rn "{function_name}" src/
107	→ Build dependency tree manually
108	```
109
110	3. Categorize files by migration priority:
111
112	\| Category \| Description \| Action \|
113	\|----------\|-------------\|--------\|
114	\| Core \| The files that MUST change for the new direction \| Migrate first \|
115	\| Dependent \| Files that import/use Core files \| Migrate after Core, use adapters \|
116	\| Peripheral \| Files loosely connected \| Migrate last or leave untouched \|
117	\| Dead \| Files no longer needed after migration \| Flag for deletion in Phase 5 \|
118
119	4. Output: Migration Map Document
120	```markdown
121	## Migration Map: [Initiative Name]
122
123	### Core (must change): [N files]
124	- file_a.ts → [what changes]
125	- file_b.ts → [what changes]
126
127	### Dependent (affected): [N files]
128	- file_c.ts → [how affected]
129
130	### Peripheral (optional): [N files]
131	- file_d.ts → [minimal change]
132
133	### Dead (remove after): [N files]
134	- old_module.ts → DELETE after migration complete
135	```
136
137	### Phase 3: DESIGN — Strangler Fig Migration
138
139	> Goal: Design an

People who liked this also viewed

6 picks

Type