refactor-safely

Previews, applies, and verifies code renames, extractions, and removals with full reference enumeration.

2|Updated Jul 18, 2026
One-click install
npx skills add https://github.com/Arasz/ai-badger --skill refactor-safely-arasz
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: refactor-safely
Source: https://github.com/Arasz/ai-badger/tree/main/features/common/skills/refactor-safely
Command: npx skills add https://github.com/Arasz/ai-badger --skill refactor-safely-arasz

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Renaming, moving, or deleting code without knowing every affected call site leads to broken references, silently deleted live code, and failures misattributed to the refactor. This Skill enforces a preview-apply-verify discipline so every affected location is known before the first edit. ## Core Features & Use Cases - Complete reference enumeration: Builds the full edit list via code-graph rename-preview tools, IDE rename-refactoring, or grep-based baselines before any change is applied. - Blast-radius and dead-code checks: Traces callers toward entry points, flags auth/payment/public-API exposure, and verifies zero reachable callers (including dynamic dispatch) before removals. - Test-bracketed application: Runs the project's test command before and after applying, so pre-existing failures cannot be mistaken for regressions. - Use Case: Before renaming a shared utility function used across a codebase, generate the complete edit list, confirm no critical path is affected, apply the previewed refactor, and verify with test runs on both sides. ## Quick Start Ask the agent to preview renaming a function everywhere it is used, check its blast radius, then apply the change and run the test suite before and after.

Frequently Asked Questions about refactor-safely

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I rename a function safely across an entire codebase?

Enumerate every reference first using a code-graph rename-preview, the IDE's rename-refactoring, or grep with manual review of each hit. Apply only from that verified list, then run the test suite before and after the change.

How to check if code is dead before deleting it?

Confirm zero reachable callers, not just zero grep hits. Grep the whole tree including tests and check dynamic-dispatch registration such as DI containers, route tables, reflection lookups, and config-driven plugin lists.

Does this refactoring workflow require a code-graph server?

No. Every step has a tool-agnostic baseline: IDE rename-refactoring, grep-based reference enumeration, manual caller tracing, and direct test-command runs work without any graph server.

Why run tests before applying a refactor?

A pre-refactor test run establishes a baseline so a pre-existing failure cannot be mistaken for one the refactor caused. Without it, a failure after the apply is unattributable.

When should I not use this refactoring workflow?

Do not use it when a feature's implementation has drifted from its intended design. That is a design question for differential-feature-refactor; this skill handles mechanical refactors whose scope is already known.