소스 정보
- 저장소
- InugamiDev/ultrathink-oss
- 최근 소스 활동
- 2026년 3월 24일 23:57
- 감지된 SKILL.md 언어
- 영어
- 스타
- 43
- 포크
- 10
설치 방법
기본적으로 소스를 먼저 확인하는 Prompt가 선택됩니다. 직접 명령으로 전환하거나 로컬 사본을 다운로드할 수도 있습니다.
소스 파일 검토
설치 여부를 결정하기 전에 SKILL.md와 SkillsMP에 표시된 보조 파일을 읽어 보세요.
메뉴
기본적으로 소스를 먼저 확인하는 Prompt가 선택됩니다. 직접 명령으로 전환하거나 로컬 사본을 다운로드할 수도 있습니다.
설치 여부를 결정하기 전에 SKILL.md와 SkillsMP에 표시된 보조 파일을 읽어 보세요.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
직접 명령은 검토 Prompt를 거치지 않습니다. 실행하기 전에 소스를 확인하세요.
npx skills add https://github.com/InugamiDev/ultrathink-oss --skill refactor명령은 한 줄로 유지됩니다. 복사하기 전에 가로로 스크롤해 전체 내용을 확인하세요.
로컬 사본을 원하시나요? SkillsMP에서 현재 제공할 수 있는 파일을 다운로드하세요.
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); }
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.
SOC 직업 분류 기준
