Agent skill
refactoring
振る舞いを変えずにコード構造を改善する際に使用。
Install this agent skill to your Project
npx add-skill https://github.com/TakumiOkayasu/dotfile-work/tree/main/claude/skills/refactoring
SKILL.md
Refactoring
トリガー条件
以下のいずれかに該当するとき発動する:
- ユーザーが「リファクタリング」「リファクタ」「構造改善」「整理」と指示したとき
- コードスメルの解消を依頼されたとき(長いメソッド、重複コード、マジックナンバー等)
- PR/レビュー指摘の「設計改善」対応を依頼されたとき
- 機能追加前の「下準備」として構造整理を依頼されたとき
前提条件
| 条件 | 内容 |
|---|---|
| ✅ 必須 | テストが存在し、全てパスしていること |
| ✅ 必須 | 変更対象コードの動作を理解していること |
| ❌ 実施禁止 | デッドライン直前 |
| ❌ 実施禁止 | テストがない状態 |
| ❌ 実施禁止 | 動作を理解していない状態 |
鉄則
テストがある状態で始める。振る舞いは変えない。
手順
フェーズ1: 安全確認
1. テストを全て実行し、全PASSを確認
2. 変更スコープを宣言(どのファイル/関数を対象とするか)
フェーズ2: スメル特定
3. 対象コードのコードスメルを列挙する
4. 優先度順に並べる(影響範囲小・リスク低 → 先に着手)
フェーズ3: 小さく変更
5. 1つのスメルに絞って変更する
6. 無関係なコードには触れない
7. テストを実行し、全PASSを確認
フェーズ4: 繰り返し
8. フェーズ3を繰り返す(1変更 = 1テスト実行)
フェーズ5: 完了確認
9. 全テストPASSを確認
10. 変更前後でインターフェース(入出力・シグネチャ)が同一であることを確認
コードスメル
長いメソッド → 抽出
// ❌
function processOrder() { /* 100行 */ }
// ✅
function processOrder() {
validate();
calculate();
save();
}
条件分岐 → ポリモーフィズム
// ❌
if (type === 'a') { ... } else if (type === 'b') { ... }
// ✅
interface Handler { handle(): void }
class HandlerA implements Handler {}
class HandlerB implements Handler {}
マジックナンバー → 定数
// ❌
if (speed > 9.8)
// ✅
const GRAVITY = 9.8;
if (speed > GRAVITY)
禁止事項・制約
| 禁止 | 理由 |
|---|---|
| 振る舞いの変更 | リファクタリングの定義違反 |
| テストなしで進める | デグレ検出不能 |
| 複数スメルを同時に変更 | 失敗時の原因特定が困難 |
| 無関係なコードへの変更 | スコープ外は別PRで対応 |
| 既存エラーハンドリング・エッジケースの削除 | 暗黙の仕様が消失する |
| 過度な圧縮・巧妙化 | 可読性損失(明示的なコード > 短いコード) |
| 1回しか呼ばれない3行処理の関数化 | 抽出コストがメリットを上回る |
| ロジックの意味が変わる早期return | 振る舞い変更に該当 |
Maintain Balance(過剰な簡略化の防止)
- 「動いているが汚い」と「壊れる可能性がある変更」なら、前者を残す
- ネストを減らす早期returnは可。ただしロジックの意味が変わる変形は禁止
出力形式
リファクタリング完了後に以下を報告する:
## リファクタリング結果
### 変更内容
- [スメル名]: [変更前の構造] → [変更後の構造]
### テスト結果
- 変更前: [PASS数]
- 変更後: [PASS数]
### 振る舞い保証
- インターフェース変更: なし / あり(要確認 [要確認])
Recommended Agent Skills
Expand your agent's capabilities with these related and highly-rated skills.
performance-optimization
パフォーマンス最適化やプロファイリング時に使用。計測手法、ボトルネック特定、負荷テスト、レポート出力をカバー。
systematic-debugging
バグやテスト失敗に遭遇した際に使用。修正前の4フェーズ根本原因分析を強制。
interface-first-design
機能追加・クラス設計・interface設計・依存関係整理・責務分割時に使用。疑似コードから interface→クラス→TDD→実装の順で設計する。TDDスキルの前段。
consultation
実装中に判断が必要になった時、技術選定・設計相談が必要な時に使用。相談テンプレートで構造化された問題提示を強制。
test-coverage-guard
既存テストの信頼性を検証し、偽陽性を検出・排除するガードレール。テストがGREENになった後に発動する。
e2e-browser
ブラウザE2Eテスト生成・実行・レポート(Docker内Playwright+Bun+Knex.js)。UI操作+DB検証+全ステップスクショ。WSLg/noVNC/headless切替対応。プロジェクト非汚染。
Didn't find tool you were looking for?