Refactor React components to follow project conventions. Use when reorganizing, splitting, or cleaning up existing React component files.
Scanned 5/27/2026
Install via CLI
openskills install ncaq/konoka---
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`スキルで定めるルールに沿ってリファクタリングします。
## 使い方
```text
/react-refactor-component <ファイルパス または コンポーネント名>
```
`$ARGUMENTS`で指定されたコンポーネントと、
その周辺で同じファイルに同居している関連コンポーネントを読み取り、
ルール違反を検出してリファクタリングを行います。
`$ARGUMENTS`が省略された場合は、
IDEで開いているファイル/ユーザーが直前に話題にしたコンポーネントを対象とします。
## ワークフロー
### 対象を読む
`$ARGUMENTS`で指定されたコンポーネントファイルをReadで開きます。
ファイル名から責務がわからない場合は、import元の使用箇所もあわせて確認します。
### 違反項目を洗い出す
以下のチェックリストでコードを点検し、違反箇所を列挙します。
- [ ] 構造順序: import → デザイン定義 → props定義 → コンポーネントの順序になっているか
- [ ] 1ファイル1コンポーネント: ファイル内のコンポーネントは1つだけか
- [ ] 1ファイル1コンポーネント補足: 新規または大幅書き換え対象のファイル名が`index.tsx`/`index.ts`ではないか
- [ ] 肥大化: 関数の冒頭から最初のJSX、つまり`return`の直前までが肥大化していないか
- [ ] 肥大化: JSX内に重複する構造、深い条件分岐、外側の準備変数の多さ、複数ドメイン概念の混在などの読みづらさが同居していないか
加えてweb-tasukeプラグインの他スキルで定義されているTypeScriptの規約にも違反していないか確認してください。
### 変更の見取り図をユーザーに提示する
リファクタリングを実行する前に、何をどう変更するつもりかを箇条書きで提示し、合意を取ります。
具体的には次を含めます。
- 切り出す予定のカスタムフック/子コンポーネントとそのファイル名
- 元ファイルの最終的な構成、デザイン定義・props・コンポーネントの配置
- リネームが発生する場合は旧ファイル名 → 新ファイル名のマッピング
フック名やファイル名の好み、分割粒度などユーザーの方針判断が必要な箇所があれば、
ここでAskUserQuestionを使って確認します。
### 段階的に編集する
合意が取れたらEdit/Writeでリファクタリングを行います。次の順序で進めると壊れにくいです。
1. カスタムフックや子コンポーネントなど切り出し先の新規ファイルを作成する
2. 元ファイルから切り出した実装を取り除き、新規ファイルからimportする
3. デザイン定義 → props → コンポーネントのファイル順序を整える
4. ファイル名のリネームが必要な場合は、それを最後に行い、import元をすべて更新する
### 検証
リファクタリング後、プロジェクトのリンターとビルドを実行して壊していないことを確認します。
エラーが出た場合は、原因を読み取った上で根本修正します。
相談のない`// eslint-disable-next-line`や`as any`での回避は禁止です。
### 報告
最後に、ユーザーへ次を簡潔に報告します。
- 検出した違反項目とその対応
- 新規作成/リネーム/削除されたファイル
- リンターとビルドの結果
- 動作確認が必要な箇所。
リファクタリングなので振る舞いは変わらない想定だが、念のため確認してほしい点を伝える
## やってはいけないこと
- バグ修正・仕様変更・最適化など振る舞いの変更を伴うリファクタリングを、
明示的な指示なしに混ぜ込まない
- いずれかのルールを「これは例外でOK」と独断で判断しない。
どうしても例外にせざるを得ない場合は必ずユーザーに確認する
- 「将来こうなるかもしれないから」という理由で抽象化を増やさない。
今ある具体に対して必要最低限の分割だけを行う
- `sva`やpanda CSSのトークンなど既存の命名規約・デザイントークンを勝手に変更しない
- 切り出した結果、importの循環参照やファイル間の責務の逆流が起きる構造にしない
No comments yet. Be the first to comment!