Agent skill

Code Refactoring Workflow

by luongnv89 in luongnv89/claude-howto

Guides systematic, test-backed refactoring in the style of Martin Fowler, moving through research, planning and small incremental changes with your approval at each phase.

MITAuto-check passedDevelopment

SKILL.md written in Ukrainian; this summary is our English description.

Install Code Refactoring Workflow

skills CLI
$ npx skills add luongnv89/claude-howto --skill refactor -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install luongnv89/claude-howto refactor --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/luongnv89/claude-howto.git skills-src && mkdir -p .claude/skills && cp -r skills-src/uk/03-skills/refactor .claude/skills/refactor && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
refactor
GitHub stars
42k
Token cost
~3.1k tokens
SKILL.md length
1,200 words
Files
6 (incl. scripts, references)
Skills in repo
25
Repo updated
First seen
Licence
MIT

At a glance

Guides systematic, test-backed refactoring in the style of Martin Fowler, moving through research, planning and small incremental changes with your approval at each phase.

  • Works in 5 steps: Збереження поведінки: Зовнішня поведінка… → Малі кроки: Робити крихітні, тестовані… → Тест-орієнтованість: Тести — це… → …
  • Restructuring a messy module without changing its behavior
  • SKILL.md covers Основні принципи, Огляд робочого процесу, Фаза 1: Дослідження та аналіз and Фаза 2: Оцінка покриття тестами, plus 4 more sections
  • Runs Python scripts from its folder; calls npm, pytest and python

What it does

The skill is written in Ukrainian and applies the approach from Fowler's book Refactoring: Improving the Design of Existing Code (second edition). Its principles are preserving external behavior, taking small steps, treating tests as a safety net, refactoring as a continuous process rather than a one-off event, and getting the user's approval at every phase.

The first phase is research and analysis. The agent asks about scope, goals, constraints, deadline pressure and test status, reads the target code, maps dependencies, documents the current architecture and notes technical-debt markers such as TODOs and FIXMEs, then presents its findings and asks for approval. The second phase assesses test coverage by finding and running the existing tests and checking coverage where it is available, and then asks you how to proceed depending on whether tests exist and pass.

The folder also ships code-smell and refactoring-catalog references, two Python scripts named analyze-complexity.py and detect-smells.py, and a refactoring-plan template.

When your agent uses it

  • Restructuring a messy module without changing its behavior
  • Reducing technical debt or cleaning up legacy code
  • Finding and removing code smells in a codebase

Example prompts

  • “Refactor the order-processing module step by step and check with me after each phase.”
  • “Find the code smells in src/billing and propose a refactoring plan.”
  • “There are no tests for this legacy parser. Assess the coverage before we refactor anything.”

Requirements

  • A way to run the project's tests, such as npm test
  • Python for the bundled analysis scripts

Workflow steps

5 steps, taken from the first numbered list in SKILL.md.

  1. Збереження поведінки: Зовнішня поведінка повинна залишатися незмінною
  2. Малі кроки: Робити крихітні, тестовані зміни
  3. Тест-орієнтованість: Тести — це страхувальна сітка
  4. Безперервність: Рефакторинг — постійний процес, а не одноразова подія
  5. Співпраця: Затвердження користувача потрібне на кожній фазі

What it can do on your machine

Read from SKILL.md and the folder at commit 556af8d. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Ships 2 files in scripts/ (Python), which the agent can run.

    Shell commands in SKILL.md call:

    • npm
    • pytest
    • python
    • mvn

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md. Its commands use npm, which can reach the network depending on how they are called.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Code Refactoring Workflow loads about 3.1k tokens when it runs, and up to ~17k if it reads all its reference files. Until then it costs about 99 tokens; SKILL.md has 1,200 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~99
When it runs · the whole SKILL.md, loaded when a task matches
~3.1k
With references · SKILL.md plus every file in references/, read only if the agent opens them
~17k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); the scripts in this folder are not scanned.

SKILL.md

The full file from luongnv89/claude-howto at commit 556af8d, republished under its MIT licence (© luongnv89). 1,200 words, ~3,089 tokens.

Download SKILL.mdSave it as .claude/skills/refactor/SKILL.md (or your agent's skills folder). This skill also uses 5 other files; get the full folder from GitHub.
name
refactor
description
Систематичний рефакторинг коду на основі методології Мартіна Фаулера. Використовуйте, коли користувачі просять рефакторити код, покращити структуру коду, зменшити технічний борг, очистити застарілий код, усунути запахи коду (code smells) або покращити супровідність коду. Ця навичка проводить через поетапний підхід з дослідженням, плануванням та безпечною інкрементальною реалізацією.

Навичка рефакторингу коду

Систематичний підхід до рефакторингу коду на основі книги Мартіна Фаулера Refactoring: Improving the Design of Existing Code (2-ге видання). Ця навичка наголошує на безпечних, інкрементальних змінах, підкріплених тестами.

«Рефакторинг — це процес зміни програмної системи таким чином, що не змінює зовнішню поведінку коду, але покращує його внутрішню структуру.» — Мартін Фаулер

Основні принципи

  1. Збереження поведінки: Зовнішня поведінка повинна залишатися незмінною
  2. Малі кроки: Робити крихітні, тестовані зміни
  3. Тест-орієнтованість: Тести — це страхувальна сітка
  4. Безперервність: Рефакторинг — постійний процес, а не одноразова подія
  5. Співпраця: Затвердження користувача потрібне на кожній фазі

Огляд робочого процесу

Фаза 1: Дослідження та аналіз
    ↓
Фаза 2: Оцінка покриття тестами
    ↓
Фаза 3: Виявлення запахів коду
    ↓
Фаза 4: Створення плану рефакторингу
    ↓
Фаза 5: Інкрементальна реалізація
    ↓
Фаза 6: Перегляд та ітерація

Фаза 1: Дослідження та аналіз

Цілі
  • Зрозуміти структуру та призначення кодової бази
  • Визначити обсяг рефакторингу
  • Зібрати контекст про бізнес-вимоги
Запитання до користувача

Перед початком уточніть:

  1. Обсяг: Які файли/модулі/функції потребують рефакторингу?
  2. Цілі: Які проблеми ви намагаєтесь вирішити? (читабельність, продуктивність, супровідність)
  3. Обмеження: Чи є зони, які НЕ слід змінювати?
  4. Тиск термінів: Чи блокує це іншу роботу?
  5. Стан тестів: Чи існують тести? Чи проходять вони?
Дії
  • Прочитати та зрозуміти цільовий код
  • Виявити залежності та інтеграції
  • Задокументувати поточну архітектуру
  • Зафіксувати існуючі маркери технічного боргу (TODOs, FIXMEs)
Вивід

Представити знахідки користувачу:

  • Резюме структури коду
  • Виявлені проблемні зони
  • Початкові рекомендації
  • Запросити затвердження для продовження

Фаза 2: Оцінка покриття тестами

Чому тести важливі

«Рефакторинг без тестів — як їзда без пасків безпеки.» — Мартін Фаулер

Тести — ключовий засіб безпечного рефакторингу. Без них ви ризикуєте внести помилки.

Кроки оцінки
  1. Перевірити наявні тести

    bash
    # Пошук файлів тестів
    find . -name "*test*" -o -name "*spec*" | head -20
  2. Запустити існуючі тести

    bash
    # JavaScript/TypeScript
    npm test
    
    # Python
    pytest -v
    
    # Java
    mvn test
  3. Перевірити покриття (якщо доступно)

    bash
    # JavaScript
    npm run test:coverage
    
    # Python
    pytest --cov=.
Точка рішення: Запитати користувача

Якщо тести існують та проходять:

  • Перейти до Фази 3

Якщо тести відсутні або неповні: Представити варіанти:

  1. Спочатку написати тести (рекомендовано)
  2. Додавати тести інкрементально під час рефакторингу
  3. Продовжити без тестів (ризиковано — потребує підтвердження користувача)

Якщо тести не проходять:

  • ЗУПИНИТИСЯ. Виправити тести перед рефакторингом
  • Запитати користувача: Чи слід спочатку виправити тести?
Рекомендації щодо написання тестів (якщо потрібно)

Для кожної функції, що рефакториться, забезпечити тести для:

  • Успішний шлях (нормальна робота)
  • Граничні випадки (порожні введення, null, межі)
  • Сценарії помилок (невалідні введення, виключення)

Використовуйте цикл «red-green-refactor»:

  1. Написати тест, що не проходить (red)
  2. Зробити так, щоб пройшов (green)
  3. Рефакторити

Фаза 3: Виявлення запахів коду

Що таке запахи коду?

Симптоми глибших проблем у коді. Це не помилки, а індикатори того, що код можна покращити.

Типові запахи коду для перевірки

Див. references/code-smells.md для повного каталогу.

Короткий довідник
ЗапахОзнакиВплив
Довгий методМетоди > 30-50 рядківВажко зрозуміти, тестувати, супроводжувати
Дубльований кодТа сама логіка в кількох місцяхВиправлення помилок потрібне в кількох місцях
Великий класКлас з занадто багатьма відповідальностямиПорушує принцип єдиної відповідальності
Заздрість до функційМетод використовує дані іншого класу більшеПогана інкапсуляція
Одержимість примітивамиНадмірне використання примітивів замість обʼєктівВідсутні доменні концепції
Довгий список параметрівМетоди з 4+ параметрамиСкладно викликати правильно
Групи данихТі самі елементи даних зʼявляються разомВідсутня абстракція
Оператори SwitchСкладні ланцюжки switch/if-elseВажко розширювати
Спекулятивна загальністьКод «на всякий випадок»Зайва складність
Мертвий кодНевикористаний кодПлутанина, тягар супровідності
Кроки аналізу
  1. Автоматичний аналіз (якщо скрипти доступні)

    bash
    python scripts/detect-smells.py <file>
  2. Ручний перегляд

    • Систематично пройти код
    • Зафіксувати кожен запах з розташуванням та серйозністю
    • Категоризувати за впливом (Критичний/Високий/Середній/Низький)
  3. Пріоритезація Зосередитися на запахах, які:

    • Блокують поточну розробку
    • Спричиняють помилки або плутанину
    • Впливають на найчастіше змінювані шляхи коду
Вивід: Звіт про запахи

Представити користувачу:

  • Список виявлених запахів з розташуванням
  • Оцінку серйозності для кожного
  • Рекомендований порядок пріоритету
  • Запросити затвердження пріоритетів

Фаза 4: Створення плану рефакторингу

Вибір рефакторингів

Для кожного запаху обрати відповідний рефакторинг з каталогу.

Див. references/refactoring-catalog.md для повного списку.

Відповідність запахів рефакторингам
Запах кодуРекомендований рефакторинг
Long MethodExtract Method, Replace Temp with Query
Duplicated CodeExtract Method, Pull Up Method, Form Template Method
Large ClassExtract Class, Extract Subclass
Feature EnvyMove Method, Move Field
Primitive ObsessionReplace Primitive with Object, Replace Type Code with Class
Long Parameter ListIntroduce Parameter Object, Preserve Whole Object
Data ClumpsExtract Class, Introduce Parameter Object
Switch StatementsReplace Conditional with Polymorphism
Speculative GeneralityCollapse Hierarchy, Inline Class, Remove Dead Code
Dead CodeRemove Dead Code
Структура плану

Використовуйте шаблон templates/refactoring-plan.md.

Для кожного рефакторингу:

  1. Ціль: Який код зміниться
  2. Запах: Яку проблему вирішує
  3. Рефакторинг: Яку техніку застосувати
  4. Кроки: Детальні мікрокроки
  5. Ризики: Що може піти не так
  6. Відкат: Як скасувати за потреби
Show full SKILL.md (510 more words)Show less
Поетапний підхід

КРИТИЧНО: Впроваджуйте рефакторинг поступово, фазами.

Фаза A: Швидкі перемоги (Низький ризик, висока цінність)

  • Перейменування змінних для ясності
  • Витяг очевидного дубльованого коду
  • Видалення мертвого коду

Фаза B: Структурні покращення (Середній ризик)

  • Витяг методів з довгих функцій
  • Введення обʼєктів параметрів
  • Переміщення методів до відповідних класів

Фаза C: Архітектурні зміни (Вищий ризик)

  • Заміна умовних конструкцій поліморфізмом
  • Витяг класів
  • Введення патернів проєктування
Точка рішення: Представити план користувачу

Перед реалізацією:

  • Показати повний план рефакторингу
  • Пояснити кожну фазу та її ризики
  • Отримати явне затвердження для кожної фази
  • Запитати: «Чи продовжити з Фазою A?»

Фаза 5: Інкрементальна реалізація

Золоте правило

«Зміна → Тест → Зелений? → Коміт → Наступний крок»

Ритм реалізації

Для кожного кроку рефакторингу:

  1. Попередня перевірка

    • Тести проходять (зелені)
    • Код компілюється
  2. Зробити ОДНУ малу зміну

    • Дотримуватися механіки з каталогу
    • Тримати зміни мінімальними
  3. Верифікація

    • Негайно запустити тести
    • Перевірити на помилки компіляції
  4. Якщо тести проходять (зелені)

    • Закомітити з описовим повідомленням
    • Перейти до наступного кроку
  5. Якщо тести не проходять (червоні)

    • ЗУПИНИТИСЯ негайно
    • Скасувати зміну
    • Проаналізувати, що пішло не так
    • Запитати користувача, якщо незрозуміло
Стратегія комітів

Кожен коміт має бути:

  • Атомарний: Одна логічна зміна
  • Оборотний: Легко відкатити
  • Описовий: Зрозуміле повідомлення коміту

Приклади повідомлень комітів:

refactor: Extract calculateTotal() from processOrder()
refactor: Rename 'x' to 'customerCount' for clarity
refactor: Remove unused validateOldFormat() method
Звіт про прогрес

Після кожної підфази звітувати користувачу:

  • Внесені зміни
  • Тести досі проходять?
  • Виявлені проблеми
  • Запитати: «Продовжити з наступною порцією?»

Фаза 6: Перегляд та ітерація

Контрольний список після рефакторингу
  • Усі тести проходять
  • Немає нових попереджень/помилок
  • Код успішно компілюється
  • Поведінка не змінилася (ручна верифікація)
  • Документація оновлена за потреби
  • Історія комітів чиста
Порівняння метрик

Запустити аналіз складності до і після:

bash
python scripts/analyze-complexity.py <file>

Представити покращення:

  • Зміна кількості рядків коду
  • Зміна цикломатичної складності
  • Зміна індексу супровідності
Перегляд користувачем

Представити фінальні результати:

  • Резюме всіх змін
  • Порівняння коду до/після
  • Покращення метрик
  • Залишковий технічний борг
  • Запитати: «Чи задоволені ви цими змінами?»
Наступні кроки

Обговорити з користувачем:

  • Додаткові запахи для усунення?
  • Запланувати подальший рефакторинг?
  • Застосувати аналогічні зміни в інших місцях?

Важливі рекомендації

Коли ЗУПИНИТИСЯ та запитати

Завжди паузу та консультацію з користувачем, коли:

  • Невпевненість щодо бізнес-логіки
  • Зміна може вплинути на зовнішні API
  • Покриття тестами недостатнє
  • Потрібне значне архітектурне рішення
  • Рівень ризику зростає
  • Зустрічаєте неочікувану складність
Правила безпеки
  1. Ніколи не рефакторити без тестів (якщо користувач явно не підтвердив ризик)
  2. Ніколи не робити великих змін — розбивати на крихітні кроки
  3. Ніколи не пропускати запуск тестів після кожної зміни
  4. Ніколи не продовжувати, якщо тести не проходять — виправити або відкатити
  5. Ніколи не припускати — якщо сумніваєтесь, запитайте
Чого НЕ робити
  • Не поєднуйте рефакторинг з додаванням функцій
  • Не рефакторте під час аварій на продакшні
  • Не рефакторте код, який не розумієте
  • Не переускладнюйте — тримайте просто
  • Не рефакторте все одразу

Приклад швидкого старту

Сценарій: Довгий метод з дублюванням

До:

javascript
function processOrder(order) {
  // 150 рядків коду з:
  // - Дубльованою логікою валідації
  // - Інлайн-обчисленнями
  // - Змішаними відповідальностями
}

Кроки рефакторингу:

  1. Переконатися, що тести існують для processOrder()
  2. Витягти валідацію у validateOrder()
  3. Тест — має пройти
  4. Витягти обчислення у calculateOrderTotal()
  5. Тест — має пройти
  6. Витягти сповіщення у notifyCustomer()
  7. Тест — має пройти
  8. Перегляд — processOrder() тепер оркеструє 3 чіткі функції

Після:

javascript
function processOrder(order) {
  validateOrder(order);
  const total = calculateOrderTotal(order);
  notifyCustomer(order, total);
  return { order, total };
}

Довідники

Скрипти

  • scripts/analyze-complexity.py — аналіз метрик складності коду
  • scripts/detect-smells.py — автоматичне виявлення запахів

Історія версій

  • v1.0.0 (2025-01-15): Початковий випуск з методологією Фаулера, поетапним підходом, точками консультації з користувачем

© luongnv89, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

SKILL.md and 5 other files (scripts, references) in uk/03-skills/refactor of luongnv89/claude-howto.

  • SKILL.md
  • references/code-smells.md
  • references/refactoring-catalog.md
  • scripts/analyze-complexity.py
  • scripts/detect-smells.py
  • templates/refactoring-plan.md

Open the folder on GitHubat commit 556af8d

Compare with similar skills

Code Refactoring Workflow next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Code Refactoring Workflow compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Code Refactoring Workflow this skillluongnv89/claude-howto42k—~3.1kAutomated safety check: PassMIT
Fowler-Style Refactoringlhfer/claude-howto-zh-cn2.3k—~156Automated safety check: PassMIT
Architecture Optimizationwondelai/skills2.4k—~7.4kAutomated safety check: PassMIT
Improve Code Qualitywondelai/skills2.4k—~6.2kAutomated safety check: PassMIT
Tech Debt Analyzerailabs-393/ai-labs-claude-skills4542 repos~3.9kAutomated safety check: PassMIT
FIXME Resolvertailcallhq/forgecode7.6k—~1.1kAutomated safety check: PassApache-2.0

Similar skills

  • Fowler-Style Refactoring

    lhfer/claude-howto-zh-cn

    基于 Martin Fowler 方法论做系统化重构。Use when users ask to refactor code, improve structure, reduce technical debt, clean up legacy code, or improve maintainability.

    2.3k GitHub stars~156 tokensUpdated 2 mo ago
    DevelopmentAuto-check passed
  • Guided journey from a working codebase grown slow and tangled to one measurably fast, cleanly bounded, and readable.

    2.4k GitHub stars~7.4k tokensUpdated 27 days ago
    DevelopmentAuto-check passed
  • Improve Code Quality

    wondelai/skills

    Guided journey from a working-but-untested vibe-coded prototype to a production-ready product with tests, clean structure, a business-rules boundary, and resilience at scale.

    2.4k GitHub stars~6.2k tokensUpdated 27 days ago
    DevelopmentAuto-check passed
  • Tech Debt Analyzer

    ailabs-393/ai-labs-claude-skills

    This skill should be used when analyzing technical debt in a codebase, documenting code quality issues, creating technical debt registers, or assessing code maintainability.

    454 GitHub starsUsed in 2 repos~3.9k tokens
    DevelopmentAuto-check passed
  • FIXME Resolver

    tailcallhq/forgecode

    Finds every FIXME comment in a codebase, groups related ones across files into one task, implements the work they describe and removes the comments once it is done.

    7.6k GitHub stars~1.1k tokensUpdated yesterday
    DevelopmentAuto-check passed
  • Desloppify

    Git-on-my-level/codex-autorunner

    Codebase health scanner and technical debt tracker. An agent skill from Git-on-my-level/codex-autorunner.

    875 GitHub stars~3.4k tokensUpdated 6 days ago
    DevelopmentAuto-check passed

More from luongnv89/claude-howto

All 25 skills in this repo
  • Systematic Code Refactoring

    luongnv89/claude-howto

    Guides refactoring in phases based on Martin Fowler's method: research, test coverage check, planning and small tested steps, with your approval at each phase.

    42k GitHub stars~3k tokensUpdated 7 days ago
    Auto-check passed
  • Blog Post Drafting

    luongnv89/claude-howto

    Guides drafting a blog post from an idea and optional source material: research, brainstorming, outlining and version-tracked drafts, with user approval at each step.

    42k GitHub stars~2.1k tokensUpdated 7 days ago
    Auto-check passed
  • Brand Voice Guide

    luongnv89/claude-howto

    Ensure all communication matches brand voice and tone guidelines. Use when creating marketing copy, customer communications, public-facing content, or when…

    42k GitHub stars~609 tokensUpdated 7 days ago
    Auto-check passed
  • Code Review Specialist

    luongnv89/claude-howto

    Reviews code for security, performance, quality and maintainability, using a checklist, a finding template and two metrics scripts.

    42k GitHub stars~764 tokensUpdated 7 days ago
    Auto-check passed
  • Claude Code Skill Assessment

    luongnv89/claude-howto

    Runs a quick or deep quiz on Claude Code skills, scores ten feature areas and generates a personalized learning path with prioritized next steps.

    42k GitHub stars~5.5k tokensUpdated 7 days ago
    Auto-check passed
  • Claude Code Lesson Quiz

    luongnv89/claude-howto

    Quizzes a learner on one lesson of the Claude Code tutorial with ten questions, scores the answers and points out weak spots.

    42k GitHub stars~2.3k tokensUpdated 7 days ago
    Auto-check passed

Categories

Questions about Code Refactoring Workflow

What does Code Refactoring Workflow do?

Guides systematic, test-backed refactoring in the style of Martin Fowler, moving through research, planning and small incremental changes with your approval at each phase. The skill is written in Ukrainian and applies the approach from Fowler's book Refactoring: Improving the Design of Existing Code (second edition). Its principles are preserving external behavior, taking small steps, treating tests as a safety net, refactoring as a continuous process rather than a one-off event, and getting the user's approval at every phase.

When should I use Code Refactoring Workflow?

Code Refactoring Workflow fits situations like: restructuring a messy module without changing its behavior; reducing technical debt or cleaning up legacy code; finding and removing code smells in a codebase.

How do I install Code Refactoring Workflow in Claude Code?

Run `npx skills add luongnv89/claude-howto --skill refactor -a claude-code`. Or copy the skill folder (uk/03-skills/refactor in luongnv89/claude-howto) into .claude/skills/refactor in your project. Claude Code loads it when a task matches its description.

How do I install Code Refactoring Workflow in Codex?

Run `npx skills add luongnv89/claude-howto --skill refactor -a codex`. Or copy the skill folder (uk/03-skills/refactor in luongnv89/claude-howto) into .agents/skills/refactor in your project. Codex loads it when a task matches its description.

Can I use Code Refactoring Workflow in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add luongnv89/claude-howto --skill refactor -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/refactor, .gemini/skills/refactor, .github/skills/refactor and .opencode/skills/refactor in your project.

What does Code Refactoring Workflow need to run?

Going by SKILL.md and its folder, Code Refactoring Workflow needs Python for the scripts in its folder and the command-line tools its instructions call (npm, pytest, python and mvn). Our summary lists: A way to run the project's tests, such as npm test; Python for the bundled analysis scripts.

Does Code Refactoring Workflow access the network?

SKILL.md contains no URLs. Its commands use npm, which can reach the network depending on how they are called. This is read from the text; nothing was executed.

Is Code Refactoring Workflow safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. The check reads SKILL.md only: the scripts in the folder are not scanned, so read them before running anything.

What licence does Code Refactoring Workflow use?

Code Refactoring Workflow is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Code Refactoring Workflow use?

About 3.1k tokens (SKILL.md is roughly 12k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full. Its references folder adds about 14k tokens, read only when the agent opens those files.

What are the alternatives to Code Refactoring Workflow?

Skills that share tags, products or a category with Code Refactoring Workflow: Fowler-Style Refactoring (lhfer/claude-howto-zh-cn, 2.3k stars), Architecture Optimization (wondelai/skills, 2.4k stars), Improve Code Quality (wondelai/skills, 2.4k stars) and Tech Debt Analyzer (ailabs-393/ai-labs-claude-skills, 454 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Code Refactoring Workflow?

luongnv89 (a GitHub user) maintains it in luongnv89/claude-howto, which has 41,764 GitHub stars. The repository holds 25 skills in this directory. The repository was last updated on September 30, 2026.

Source: luongnv89/claude-howto on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.