Skip to main content Startseite Ersteller akillness oh-my-skills code-refactoring
code-refactoring Turn a cleanup packet into one behavior-preserving refactor brief. Use when the user needs to simplify a messy function, component, service, script, or module; split an oversized diff into safer cleanup slices; freeze behavior before touching fragile legacy code; or plan a repeated migration / codemod without changing intended behavior. Route diagnosis to `debugging`, review judgment to `code-review`, validation-program design to `testing-strategies`, bottleneck-led tuning to `performance-optimization`, and pure symbol inventory or impact mapping to `codebase-search`.
Zur Installation springen Skills Marktplatz Entdecken und erkunden Sie KI-Skills, die von der Community erstellt wurden.
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Prompt-Details anzeigen Ein direkter Befehl überspringt den Prüf-Prompt. Prüfen Sie die Quelle, bevor Sie ihn ausführen.
npx skills add https://github.com/akillness/oh-my-skills --skill code-refactoringDer Befehl bleibt in einer Zeile. Scrollen Sie horizontal, um ihn vor dem Kopieren vollständig zu prüfen.
Sie bevorzugen eine lokale Kopie? Laden Sie die Dateien herunter, die SkillsMP derzeit vorliegen.
ZIP herunterladen Herunterladen... Mehr aus diesem Repository
One-shot installer for the akillness/oh-my-gods agent skill bundle (80+ skills spanning agent-browser, agent-workflow, ai-research-skills, api-design, and the full god-skills catalog). Use when the user asks to add the oh-my-gods skill pack, bring in the AgenticSkills bundle, or wants every god-skill copied into Claude Code, Codex CLI, Antigravity/Gemini, and OpenCode in one step. Triggers on: AgenticSkills, agenticskills, oh-my-gods, god-skills, install oh-my-gods, bring in agentic skills bundle, install gods skills, add god skills.
Make any software agent-native with HKUDS CLI-Anything — route between four modes: install ready-made CLI harnesses via the CLI-Hub package manager (`pip install cli-anything-hub`, then `cli-hub list/search/info/install/launch`), give agents the autonomous discovery meta-skill (`npx skills add HKUDS/CLI-Anything --skill cli-hub-meta-skill`), generate a new harness from any codebase or GitHub repo via the 7-phase pipeline (`/plugin install cli-anything` → `/cli-anything <path>`), or iterate with `/cli-anything:refine`, `:test`, `:validate`. 40+ production harnesses (GIMP, Blender, LibreOffice, OBS, ComfyUI, Ollama, Godot, QGIS, …), 2,461 passing tests, Click CLIs with REPL + `--json` output. Use when agents must drive real desktop/server software without GUI automation. Triggers on: cli-anything, cli-hub, cli-anything-hub, agent-native cli, make software agent-native, cli harness generation, /cli-anything, harness refine, HKUDS cli.
Run Comet's Opik — open-source LLM observability, evaluation, and optimization — from one routing-first skill: install the Python/TypeScript SDK, stand up a server (Comet.com cloud, Docker Compose via `./opik.sh`, or Kubernetes/Helm), wire tracing through `@opik.track` or one of 50+ framework integrations (OpenAI, Anthropic, LangChain, LangGraph, LlamaIndex, CrewAI, DSPy, Ollama, Bedrock, Vercel AI SDK, …), score outputs with LLM-as-a-judge metrics (Hallucination, Moderation, Answer Relevance, Context Precision), and run Datasets/Experiments evaluations including PyTest CI gates. Use when the user wants LLM tracing, prompt evaluation, production LLM monitoring, agent optimization, or guardrails with Opik. Triggers on: opik, comet opik, opik configure, opik.sh, llm observability, llm tracing, llm as a judge, hallucination metric, prompt evaluation, opik dashboard, opik guardrails, agent optimizer.
Verwandte Berufe SOC
Basierend auf der SOC-Berufsklassifikation
name code-refactoring description Turn a cleanup packet into one behavior-preserving refactor brief. Use when the user needs to simplify a messy function, component, service, script, or module; split an oversized diff into safer cleanup slices; freeze behavior before touching fragile legacy code; or plan a repeated migration / codemod without changing intended behavior. Route diagnosis to `debugging`, review judgment to `code-review`, validation-program design to `testing-strategies`, bottleneck-led tuning to `performance-optimization`, and pure symbol inventory or impact mapping to `codebase-search`.
allowed-tools Read Grep Glob Bash Write compatibility Best for CLI, backend, frontend, fullstack, and game-programming codebases where the main task is structural cleanup with explicit verification. Not for proving a bug exists, approving a PR, choosing org-wide test policy, or isolating a performance bottleneck from traces or benchmarks.
metadata {"tags":"refactoring, code-quality, behavior-preservation, cleanup, codemod, migration, technical-debt, legacy-code","platforms":"Claude, ChatGPT, Gemini, Codex","version":"2.1","source":"akillness/oh-my-skills","modernization":"2026-04-14T00:00:00.000Z","hardening":"2026-04-18T00:00:00.000Z"}
Code Refactoring
Use this skill when the job is to improve structure without changing intended behavior .
The center of the skill should stay small and repeatable:
identify the cleanup packet you actually have,
choose one refactor mode,
make the behavior guardrail explicit,
stage the work in reviewable slices,
verify and route remaining work honestly.
Read these support docs before handling unfamiliar cleanup work:
When to use this skill
A function, component, service, script, or module is too tangled and needs structural cleanup without a behavior change.
A legacy area needs a freeze-first cleanup because the current behavior is fragile or poorly understood.
The same API, naming, or structure change repeats across many files and needs a codemod / migration brief.
A diff mixes cleanup with too much semantic work and needs to be split into smaller reviewable slices.
The user asks to refactor, decompose, deduplicate, rename safely, stage a cleanup, or plan a behavior-preserving migration.
When not to use this skill
The main job is proving why behavior is wrong, reproducing a failure, or isolating a regression → debuggingThe main job is deciding whether a concrete diff / PR is safe to merge → code-reviewThe main job is choosing org-wide validation depth, benchmark policy, or release gates → testing-strategiesThe main job is finding the bottleneck from traces, flamegraphs, CWV reports, or profiler output → performance-optimizationThe main job is finding symbols, call sites, or impact scope before any cleanup tactic is chosen → codebase-search
Instructions
Step 1: Start from the cleanup packet Choose the packet the user already has:
one messy file / component / service
a fragile legacy area with weak confidence in current behavior
a repeated migration pattern across many files
a cleanup-heavy diff that needs reshaping before review
only a vague desire to “find all the places first”
Output the intake briefly:
## Cleanup Packet
- Current artifact:
- Why it is enough (or not enough):
- Missing evidence to collect next:
Rule: do not force a giant refactor plan when the immediate need is only search, diagnosis, review, or performance evidence.
Step 2: Choose one primary refactor mode
local-safe-refactorbehavior-freeze-firstrepetitive-migration-codemoddiff-shaping-cleanup Signal Mode One file or narrow module, clear intent, at least one fast guardrail exists local-safe-refactorFragile legacy area, hidden invariants, weak test trust behavior-freeze-firstSame API or structure repeats across many files repetitive-migration-codemodCleanup is mixed into a risky review diff and needs smaller slices diff-shaping-cleanup
Rule: one primary mode, optional secondary note. Do not mix every cleanup tactic into one answer.
Step 3: Freeze the behavior guardrail Before broad edits, decide how you will prove intent stayed the same.
Guardrail sources can include:
existing unit / integration / end-to-end tests
typecheck and linter
characterization tests or captured examples
fixture snapshots or golden outputs
screenshots / preview captures for UI work
before/after sample input-output tables
manual smoke steps when automation is thin
Local cleanup → at least one fast verification pathFragile legacy cleanup → freeze behavior firstRepeated migration → pilot on a small representative sample firstDiff reshaping → separate mechanical cleanup from semantic follow-up If the user mainly needs help designing the entire validation program, route to testing-strategies.
Step 4: Build the smallest credible cleanup plan Keep the plan reviewable.
rename / move / extract work
duplicated or dead-code cleanup
mechanical migration or codemod rollout
semantic follow-up only if still needed
verification + handoff
goal
behavior to preserve
evidence / guardrail
risk edge
whether another skill owns the next step
Prefer a sequence of boring diffs over one heroic rewrite.
Keep structural cleanup and semantic behavior changes separate when possible.
For migrations, define source pattern, target pattern, known exceptions, and rollback path before scaling up.
Step 5: Use the right mode packet
local cleanup packet
fragile legacy / freeze-first packet
repeated migration / codemod packet
diff-shaping packet
local-safe-refactor → rename unclear concepts, extract pure logic, move side effects to edges, collapse close duplicationbehavior-freeze-first → capture examples, add characterization tests, identify one seam, refactor behind that seamrepetitive-migration-codemod → define source/target pattern, sample first, inspect false positives, expand only after the pilot is trustworthydiff-shaping-cleanup → split cleanup from semantic changes, isolate generated or mechanical edits, leave review notes about remaining hotspots
Step 6: Verify and route remaining work Do not stop at “looks cleaner.”
## Refactor Brief
- Primary mode:
- Behavior to preserve:
- Guardrail used:
- Smallest planned slices:
- Risks still open:
- Recommended next move:
what behavior was intended to stay the same
what evidence was used to verify that
what still remains risky or out of scope
which neighboring skill should own the next step when the job shifts
Output format ## Cleanup Packet
- Current artifact:
- Primary mode:
- Why this mode fits:
## Behavior Guardrail
- Intended behavior to preserve:
- Evidence available:
- Missing evidence:
## Planned slices
1. ...
2. ...
3. ...
## Verification
- Fast checks:
- Higher-risk checks:
## Route-outs
- Use `debugging` for:
- Use `code-review` for:
- Use `testing-strategies` for:
- Use `performance-optimization` for:
- Use `codebase-search` for:
Examples
Example 1: Oversized service handler Input: "Refactor this 180-line checkout handler into something readable without changing behavior."
choose local-safe-refactor
preserve coupon / tax / out-of-stock behavior explicitly
extract validation, pricing, and persistence helpers
keep tests / typecheck as guardrails
split structural cleanup from later semantic follow-up
Example 2: Fragile legacy module Input: "This reporting service is impossible to maintain, but we barely trust the tests. Help me refactor it safely."
choose behavior-freeze-first
capture characterization cases before broad cleanup
identify one seam at a time instead of redesigning everything
route deep failure investigation to debugging if expected behavior is still unclear
Example 3: Repeated API migration Input: "We need to replace a deprecated client API across 220 TypeScript files before the framework upgrade."
choose repetitive-migration-codemod
define source and target patterns
pilot the transform on a subset first
keep mechanical rewrite separate from semantic follow-up
verify with tests, typecheck, and repo search
Example 4: Search-first route-out Input: "Before we refactor anything, find every call site and wrapper around this old helper so we can see the blast radius."
route the primary task to codebase-search
do not present a full refactor plan as the main answer
keep code-refactoring positioned as the cleanup lane after the impact map exists
Best practices
Start from the packet the user actually has, not an idealized cleanup workflow.
Pick one primary mode before proposing actions.
Make behavior preservation explicit; do not assume it.
Prefer small, reviewable slices over one giant cleanup diff.
Use codemods or structural rewrites only when repetition justifies the setup cost.
Keep diagnosis, review judgment, test-policy design, performance tuning, and symbol inventory routed to neighboring skills instead of absorbing them.
Preserve evidence of what was verified and what still remains risky.
References 