Menu
Safe, incremental code refactoring with verification checkpoints and rollback safety
The review-first prompt is selected by default. You can switch to a direct command or download a local copy.
Read SKILL.md and any companion files shown by SkillsMP before deciding whether to install.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
A direct command skips the review prompt. Inspect the source before running it.
npx skills add https://github.com/InugamiDev/ultrathink-oss --skill refactorThe command stays on one line. Scroll horizontally to inspect it before copying.
Prefer a local copy? Download the files currently available to SkillsMP.
Unified design foundations — design system architecture, tokens, component specs, visual principles, creative vision, figma integration, plus brand design system loader (66 real brands via DESIGN.md). Absorbs design, design-system, design-systems, design-principles, design-router, creative-vision, figma, design-md.
Render, summarize, and present markdown documents and structured content in multiple output modes
Ultra UI skill - combines Google's DESIGN.md spec (machine-readable design tokens) with the ui-ux-pro-max knowledge base (91 styles, 161 palettes, 73 font pairings, 161 products, 104 UX guidelines, 25 chart types). Generates lint-clean DESIGN.md files, validates token references and WCAG contrast, exports Tailwind/DTCG tokens, and diffs design systems version-over-version.
Based on SOC occupation classification
Showing SKILL.md
| name | refactor |
| description | Safe, incremental code refactoring with verification checkpoints and rollback safety |
| layer | hub |
| category | workflow |
| triggers | ["/refactor","refactor this","clean up this code","restructure this","extract this","simplify this"] |
| inputs | [{"target":"Code, file(s), or module to refactor"},{"goal":"What the refactoring should achieve (readability, modularity, testability, etc.)"},{"constraints":"What must NOT change (public API, behavior, performance characteristics)"}] |
| outputs | [{"refactoringPlan":"Step-by-step plan with verification at each step"},{"changes":"List of all modifications made"},{"verificationResults":"Test results and behavioral checks at each checkpoint"}] |
| linksTo | ["test","code-review","scout","debug"] |
| linkedFrom | ["cook","team","ship","optimize"] |
| preferredNextSkills | ["test","code-review"] |
| fallbackSkills | ["debug","scout"] |
| riskLevel | medium |
| memoryReadPolicy | selective |
| memoryWritePolicy | selective |
| sideEffects | ["Modifies source code files","May modify or create test files","Runs tests between refactoring steps"] |
Improve code structure, readability, and maintainability WITHOUT changing external behavior. Refactoring is the disciplined practice of restructuring existing code -- altering its internal structure without altering its external behavior.
The cardinal rule: After refactoring, the system does exactly what it did before. Only the code is different.
Read the target code thoroughly. Understand what it does, how it does it, and why it is structured the way it is.
Identify the specific smells -- What is wrong with the current structure?
data, result, temp, handleDefine the refactoring goal -- What does the code look like when we are done?
Identify behavioral constraints -- What must NOT change?
Check test coverage -- What tests exist for this code?
Break the refactoring into small, safe steps. Each step should be:
Common refactoring moves (use as building blocks):
| Move | When to Use | Risk |
|---|---|---|
| Rename | Unclear names | Very Low |
| Extract function | Long function, duplicated logic | Low |
| Extract module/file | God object, mixed concerns | Medium |
| Inline | Over-abstraction, wrapper adds no value | Low |
| Move | Feature envy, wrong module | Medium |
| Replace conditional with polymorphism | Complex switch/if chains | Medium |
| Introduce parameter object | Function with 4+ parameters | Low |
| Replace magic values with constants | Unexplained literals | Very Low |
| Simplify conditional | Complex boolean expressions | Low |
| Pull up / Push down | Inheritance hierarchy adjustment | Medium |
Order the steps from lowest risk to highest. Rename before extract. Extract before move.
For each refactoring step:
a. Announce the step: "Step N: [move type] -- [description]"
b. Read the current state of affected files
c. Apply the change using Edit tool
d. Verify: Run tests. If tests pass, proceed. If tests fail:
e. Checkpoint: The code should be in a working state after every step. If interrupted here, the refactoring is partially complete but the code works.
Do NOT combine steps -- Even if two changes seem related, apply them separately and verify between them. This is the discipline that keeps refactoring safe.
Run the full test suite after all steps are complete.
Compare before/after -- The external behavior should be identical. Internal structure should match the refactoring goal.
Produce the refactoring report using the template below.
# Refactoring Report
## Target
[What was refactored]
## Goal
[What the refactoring aimed to achieve]
## Before/After Summary
| Metric | Before | After |
|--------|--------|-------|
| Files | [count] | [count] |
| Functions | [count] | [count] |
| Max nesting depth | [N] | [N] |
| Longest function (lines) | [N] | [N] |
| Test coverage | [%] | [%] |
## Steps Performed
1. **[Move type]**: [description] — Tests: PASS
2. **[Move type]**: [description] — Tests: PASS
3. ...
## Files Changed
- [file 1]: [what changed]
- [file 2]: [what changed]
- [new file]: [why created]
## Verification
- [ ] All existing tests pass
- [ ] No behavioral changes (same inputs → same outputs)
- [ ] New characterization tests added (if needed)
- [ ] Code matches refactoring goal
## Remaining Opportunities
- [Further refactoring that could be done but was out of scope]
/refactor Clean up src/lib/utils.ts -- it is 400 lines and does too many things
/refactor Extract the validation logic from the form component into a separate module
/refactor Improve naming in the payment processing module -- variables like 'x', 'tmp', and 'data' need descriptive names
/refactor Split the monolithic api/route.ts into separate route handlers per resource
Before:
function processOrder(order: Order) {
// 15 lines of validation logic
// 10 lines of discount calculation
// 20 lines of tax calculation
// 10 lines of shipping calculation
// 5 lines of total assembly
}
After (4 steps):
validateOrder(order) -- Tests: PASScalculateDiscount(order) -- Tests: PASScalculateTax(order, subtotal) -- Tests: PASScalculateShipping(order) -- Tests: PASSfunction processOrder(order: Order) {
validateOrder(order);
const discount = calculateDiscount(order);
const tax = calculateTax(order, order.subtotal - discount);
const shipping = calculateShipping(order);
return { ...order, discount, tax, shipping, total: order.subtotal - discount + tax + shipping };
}
Step 1: Extract constants
// Before
if (retries > 3) { setTimeout(fn, 5000); }
// After
const MAX_RETRIES = 3;
const RETRY_DELAY_MS = 5000;
if (retries > MAX_RETRIES) { setTimeout(fn, RETRY_DELAY_MS); }