@lenardangeloolajay/len-toolkit 1.1.0

package/templates/skills/refactoring/refactoring.nano.md

@@ -0,0 +1,37 @@
+# OBEY Refactoring by Martin Fowler
+
+## When to use
+
+Use as a compact always-on rule set for changing existing code under tight context.
+
+## Primary bias to correct
+
+Cleanup must preserve behavior and move in small verified steps, not become a rewrite.
+
+## Decision rules
+
+- Preserve observable behavior; isolate feature changes, migrations, redesign, and cleanup.
+- Work in small buildable, testable, reviewable steps; split changes that are too large to reason about locally.
+- Get a safety net or record the verification gap before risky structural edits.
+- Refactor the smell that blocks the current change, not every smell nearby.
+- Prefer simple named moves: rename, extract, inline, move, split phases, encapsulate mutation, decompose conditionals, and remove duplication.
+- Put behavior, state, and validation with the concept that owns them; avoid vague utilities, pass-through layers, and just-in-case abstractions.
+- Keep mutation and call contracts clear: avoid boolean flags, parameter reassignment, public mutable data, unnecessary setters, and hidden side effects.
+- Stop when the change is easy, the code is clearer, and further cleanup would be speculative.
+
+## Trigger rules
+
+- When behavior is unclear or tests are weak, characterize current behavior before broader refactoring.
+- When adding a feature is awkward, make the smallest preparatory refactor that makes it straightforward.
+- When the same edit appears for a third time, centralize ownership instead of copying again.
+- When conditionals or type codes grow, decompose intent before reaching for polymorphism, state, strategy, or lookup tables.
+- When a patch mixes cleanup with behavior or broad code motion, split it where practical.
+- When tempted to rewrite, choose the next small behavior-preserving transformation.
+
+## Final checklist
+
+- Same behavior?
+- Safety net or verification gap?
+- Small runnable step?
+- Clearer names, ownership, and control flow?
+- No speculative abstraction or mixed patch?

package/templates/skills/refactoring-guru/SKILL.md

@@ -0,0 +1,11 @@
+---
+name: refactoring-guru
+description: Apply Refactoring.Guru-inspired rules when diagnosing code smells, choosing refactoring techniques, and stopping cleanup before uncontrolled redesign.
+license: MIT
+---
+
+# Refactoring.Guru Skill
+
+Use this skill when a task involves diagnosing smells, choosing targeted refactoring treatments, preserving behavior, applying a refactoring catalog, or avoiding uncontrolled redesign.
+
+Before making design or code decisions, read and apply [refactoring-guru.mini.md](refactoring-guru.mini.md). Use [refactoring-guru.md](refactoring-guru.md) only as a deeper reference when the mini rules are not enough for the current refactoring tradeoff.