Menu
コードを触る前にリファクタの影響範囲・順序・ロールバック戦略を計画する。依存関係を洗い出し、安全に進められる小さなステップに分解する。「リファクタ計画立てて」「影響範囲調べて」「安全に直す手順を作って」などで起動。
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
| name | backend-refactor-planner |
| description | コードを触る前にリファクタの影響範囲・順序・ロールバック戦略を計画する。依存関係を洗い出し、安全に進められる小さなステップに分解する。「リファクタ計画立てて」「影響範囲調べて」「安全に直す手順を作って」などで起動。 |
リファクタに着手する前に、何を・どの順で・どう検証して 進めるかを明確化する。実装自体はこのスキルの範囲外。
ユーザーに以下を確認（必要なら 1-2 個だけ聞く）:
対象シンボル/ファイルに対して、以下を調査:
参照元が 20 箇所以上 ある場合は、一括変更ではなく段階的移行を強く推奨する。
以下のパターンから該当するものを選ぶ。
適する場合: 広範囲に影響、段階的に切り替えたい、ロールバック容易性が欲しい
適する場合: 公開 API を維持しつつ内部刷新
適する場合: 参照元が 10 箇所未満、影響が局所、テストが厚い
各ステップについて以下を明記:
以下のテンプレで出力:
## リファクタ計画: <タイトル>
### ゴール
<what / why / done>
### 制約
<変更禁止事項>
### 影響範囲
- 参照箇所: N 件
- テスト: <ファイル一覧>
- 外部契約: <ありなし>
### 戦略
<Parallel Change / Strangler Fig / In-place>（理由: ...）
### ステップ
1. <ステップ名>
- 変更: ...
- 検証: ...
- ロールバック: <revert 対象>
- PR: 独立 / まとめる
2. ...
### リスク
- <見落としがち項目>
- <テスト未カバー領域>
### 着手判断
この計画で進めて良いですか？ それとも手順を調整？
計画提示で終わる。ユーザーの承認なく実装に入らない。
docs/spec/ の仕様書を元に、docs/work/YYYYMMDD_<feature>.md として実装計画書を作成する。Phase 分解・影響範囲・テスト戦略・リスクを構造化し、実装前にユーザー承認を取る。「実装計画立てて」「work 書いて」「どう進めるか計画して」などで起動。
差分や指定コードを構造化されたレビュー観点（正確性・設計・テスト・可読性・セキュリティ）で読み、優先度付きで指摘する。修正は提案するが勝手に書き換えない。「レビューして」「コードレビュー」「セカンドオピニオン」などで起動。
未知のコードベースを最短で把握するための構造化探索を行う。言語・ビルドツール・アーキテクチャ・テスト方針・主要なエントリポイントを短時間でレポート化する。「このプロジェクト教えて」「コードベース調べて」「初見で入ったから概要ほしい」などで起動。
未コミットの変更を依存関係と関心事に基づいて適切な粒度のコミットに分割する。自動生成物・手動実装・テスト・ドキュメントを分離し、レビューしやすい履歴を作る。「コミット分けて」「良い粒度でコミット」「この変更コミットにして」などで起動。
バグ調査を場当たり的でなく体系的に進める。再現→仮説→検証→修正→回帰テストの順序を守り、仮説と事実を分けて記録する。「バグ調査して」「なぜか動かない」「デバッグ手伝って」などで起動。
汎用的な開発オーケストレーター。docs/spec/ の仕様と docs/work/ の実装計画書を軸に、Phase 分解と PDCA サイクルで実装を進める。自分は実装せず、各 Phase を Task で専門 agent / Explore / Plan に委託する。「開発進めて」「実装オーケストレートして」「機能実装して」などで起動。