一键导入
refactoring
Use when coordinating large changes across multiple files or performing significant code restructuring
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Use when coordinating large changes across multiple files or performing significant code restructuring
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Execute safe Git workflows — branching, committing, resolving conflicts, and managing PRs
Use when controlling AI spend, token budgets, model routing, or workflow efficiency before scaling usage
Use when handling incidents, outages, severe regressions, or operational emergencies before attempting broad fixes
Use when investigating latency, throughput, resource saturation, or performance regressions before changing implementation details
Use when reviewing code, preparing a PR for review, or processing review feedback
Use when diagnosing bugs, test failures, or unexpected behavior before attempting any fix
| name | refactoring |
| description | Use when coordinating large changes across multiple files or performing significant code restructuring |
Announce at start: "Following the refactoring skill for multi-file changes."
Interface first, implementation second. Define contracts before changing internals.
Before changing anything:
| Order | What | Why |
|---|---|---|
| First | Types/interfaces | Contracts must be stable before implementation |
| Second | Core logic | Internal changes behind stable interfaces |
| Third | Callers/consumers | Update after interfaces are settled |
| Last | Tests | Verify everything works together |
For each file in dependency order:
Do not batch multiple files into one uncommitted change.
| After Each File | After Each Layer | After All Changes |
|---|---|---|
| Type check passes | Build succeeds | Full test suite passes |
| Relevant tests pass | Integration tests pass | Manual verification |
| Git status is clean | No regressions | PR is reviewable size |
| Size | Recommendation |
|---|---|
| 1-50 lines | Ideal — easy to review |
| 50-200 lines | Acceptable — stay focused |
| 200-500 lines | Split if possible |
| 500+ lines | Must split into multiple PRs |
Before starting, define how to undo:
| Strategy | When |
|---|---|
git revert | Single-commit changes |
| Feature flag | Behavior changes |
| Separate revert PR | Multi-commit changes |
| Config toggle | Environment-specific |
| Signal | Action |
|---|---|
| Changing behavior during refactor | Separate into two PRs (refactor then feature) |
| Tests are failing and you don't know why | Stop, diagnose before continuing |
| Change touches more than 10 files | Break into smaller PRs |
| No test coverage for changed code | Add tests before refactoring |
| When | Invoke |
|---|---|
| Refactoring uncovers a bug | debugging |
| Need to update tests for refactored code | testing |
| Refactoring complete, ready to submit | pr-writing |
| Refactoring started without a plan | planning |
For principles, rationale, anti-patterns, and examples:
guides/multi-file-refactoring/multi-file-refactoring.md