| name | react-refactor-component |
| description | Refactor React components to follow project conventions. Use when reorganizing, splitting, or cleaning up existing React component files. |
| argument-hint | [file-path or component-name] |
| allowed-tools | AskUserQuestion, Bash(biome:*), Bash(eslint:*), Bash(git diff:*), Bash(git mv:*), Bash(git status:*), Bash(nix:*), Bash(nix-fast-build:*), Bash(npm:*), Bash(pnpm:*), Bash(prettier:*), Bash(tsc:*), Bash(yarn:*), Edit, Glob, Grep, Read, Write |
Reactコンポーネントリファクタリング
指示されたReactコンポーネントを、
react-component-conventionスキルで定めるルールに沿ってリファクタリングします。
使い方
/react-refactor-component <ファイルパス または コンポーネント名>
$ARGUMENTSで指定されたコンポーネントと、
その周辺で同じファイルに同居している関連コンポーネントを読み取り、
ルール違反を検出してリファクタリングを行います。
$ARGUMENTSが省略された場合は、
IDEで開いているファイル/ユーザーが直前に話題にしたコンポーネントを対象とします。
ワークフロー
対象を読む
$ARGUMENTSで指定されたコンポーネントファイルをReadで開きます。
ファイル名から責務がわからない場合は、import元の使用箇所もあわせて確認します。
違反項目を洗い出す
以下のチェックリストでコードを点検し、違反箇所を列挙します。
加えてweb-tasukeプラグインの他スキルで定義されているTypeScriptの規約にも違反していないか確認してください。
変更の見取り図をユーザーに提示する
リファクタリングを実行する前に、何をどう変更するつもりかを箇条書きで提示し、合意を取ります。
具体的には次を含めます。
- 切り出す予定のカスタムフック/子コンポーネントとそのファイル名
- 元ファイルの最終的な構成、デザイン定義・props・コンポーネントの配置
- リネームが発生する場合は旧ファイル名 → 新ファイル名のマッピング
フック名やファイル名の好み、分割粒度などユーザーの方針判断が必要な箇所があれば、
ここでAskUserQuestionを使って確認します。
段階的に編集する
合意が取れたらEdit/Writeでリファクタリングを行います。次の順序で進めると壊れにくいです。
- カスタムフックや子コンポーネントなど切り出し先の新規ファイルを作成する
- 元ファイルから切り出した実装を取り除き、新規ファイルからimportする
- デザイン定義 → props → コンポーネントのファイル順序を整える
- ファイル名のリネームが必要な場合は、それを最後に行い、import元をすべて更新する
検証
リファクタリング後、プロジェクトのリンターとビルドを実行して壊していないことを確認します。
エラーが出た場合は、原因を読み取った上で根本修正します。
相談のない// eslint-disable-next-lineやas anyでの回避は禁止です。
報告
最後に、ユーザーへ次を簡潔に報告します。
- 検出した違反項目とその対応
- 新規作成/リネーム/削除されたファイル
- リンターとビルドの結果
- 動作確認が必要な箇所。
リファクタリングなので振る舞いは変わらない想定だが、念のため確認してほしい点を伝える
やってはいけないこと
- バグ修正・仕様変更・最適化など振る舞いの変更を伴うリファクタリングを、
明示的な指示なしに混ぜ込まない
- いずれかのルールを「これは例外でOK」と独断で判断しない。
どうしても例外にせざるを得ない場合は必ずユーザーに確認する
- 「将来こうなるかもしれないから」という理由で抽象化を増やさない。
今ある具体に対して必要最低限の分割だけを行う
svaやpanda CSSのトークンなど既存の命名規約・デザイントークンを勝手に変更しない- 切り出した結果、importの循環参照やファイル間の責務の逆流が起きる構造にしない
