mcpField
R
refactor-plan

refactor-plan

github.com/helderberto開発2047 回インストール6 日前に更新
リポジトリ

refactor-plan について

実装前に範囲と方針を明確にする、開発者向けのリファクタリング計画スキルです。コードベースが動作する状態を保つ小さな連続ステップに分け、計画をGitHub Issueに記録します。

主な機能

  1. 01問題と現状コードの確認
  2. 02対話による範囲の明確化
  3. 03方針とトレードオフの比較
  4. 04動作を保つ小さなコミットへの分割
  5. 05GitHub Issueでの計画作成

活用シーン

  1. 01大規模リファクタリングの手順計画
  2. 02着手前の対象範囲のテストカバレッジ確認
  3. 03承認された計画のGitHub Issueへの記録

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/helderberto/agent-skills --skill refactor-plan

インストール後、Claude Code で/refactor-planを入力して読み込まれたか確認します。

詳細

リファクタリングの計画

プロセス

1. 問題を理解する
  • ユーザーから詳細な説明を聞きます
  • 検討済みの解決策があるか尋ねます
  • コードベースを調査して現状を確認します
2. 範囲を定義する
  • 実装の詳細についてユーザーに質問します
  • 代替案を提示します。各案について、説明にトレードオフを含めた選択肢として示します。該当する場合は、プレビューを使ってコードのスケッチを提示します。AskUserQuestion が利用可能な場合は使用し、利用できない場合は番号付きリストで提示します。
  • 変更する内容と変更しない内容を正確に定義します
  • 影響を受ける領域のテストカバレッジを確認します
3. 作業を分割する

Martin Fowler の原則を適用します。「プログラムが常に動作していることを確認できるように、リファクタリングの各ステップをできる限り小さくします。」

  • 小さなコミットのリストを作成します
  • 各コミット後もコードベースが動作する状態にします
  • 並行ではなく、順番に変更します
4. GitHub Issue を作成する
gh issue create --title "Refactor: <title>" --body "$(cat <<'EOF'
## Problem Statement

The problem from the developer's perspective.

## Solution

The approach from the developer's perspective.

## Commits

Detailed plan broken into the tiniest commits possible. Each leaves codebase working.

1. Add new interface type
2. Update service to accept new interface (keep old code path)
3. Add tests for new code path
4. Update consumers to use new interface
5. Remove old code path

## Implementation Decisions

- Modules to build/modify and their interfaces
- Architectural decisions
- Schema changes
- API contracts

Do NOT include file paths or code snippets -- they go stale.

## Testing Decisions

- What makes a good test (behavior, not implementation)
- Which modules need tests
- Prior art: similar test patterns in the codebase

## Out of Scope

What is explicitly not included.
EOF
)"

ルール

  • 各コミット後もコードベースが機能する状態を維持します
  • 計画に実装の詳細を含めません（動作に焦点を当てます）
  • 作業を始める前にテストカバレッジを確認します
  • 方針についてユーザーの承認を得ます

エラー処理

  • gh issue create が失敗した場合 -- 認証を確認するため gh auth status を実行し、代わりに Markdown として出力することを提案します
  • テストカバレッジが不十分な場合 -- 不足箇所を記録し、「X のテストを追加する」を最初のコミットとして追加します
  • 範囲が想定より大きい場合 -- 続行する前にユーザーと計画を見直します

関連項目

  • tdd -- テスト駆動開発を使ってリファクタリング後のコードを実装します

コメント

Markdown 対応