mui

mui skill の概要

mui skill は、React プロジェクトで Material UI v7 を扱うための実践ガイドです。特に、汎用的な React UI の助言ではなく、正しい sx スタイリング、テーマ準拠のコンポーネント、レスポンシブなレイアウト、そして v7 に即した最新パターンが必要な場面で力を発揮します。@mui/material をすでに使っているフロントエンド開発者、AI コーディング支援の利用者、バージョン固有のミスを減らしつつ実装速度を上げたいチームに向いています。

mui skill でできること

この mui skill は、「MUI をゼロから学ぶ」こと自体が目的ではなく、コンポーネント、ページ、レイアウト、テーマ、移行作業を安全に進めたいときに使うのが適しています。特に強いのは次のような用途です。

• MUI コンポーネントを、MUI らしい import パターンで実装する
• 場当たり的な CSS ではなく sx prop でスタイリングする
• spacing、palette、typography などの theme token を使う
• レスポンシブな breakpoints を無理なく適用する
• 古いサンプルでは崩れやすい MUI v7 の変更点に対応する

この mui skill を導入すべき人

次に当てはまるなら、この skill は有力な選択肢です。

• すでに React は使っていて、AI エージェントからより良い MUI コードを引き出したい
• フロントエンド作業で繰り返し使える mui ガイドがほしい
• MUI v6 から移行中で、古い書き方を減らしたい
• テーマに一貫した UI コードを生成するプロンプトを使いたい

逆に、そもそも MUI を使っていないなら、この skill はかなり特化しすぎています。

汎用プロンプトより役立つ理由

たとえば “make a Material UI form” のような素朴な依頼だと、バージョンが混在したコード、浅い theme 活用、MUI の流儀を無視したスタイリングが返ってきがちです。mui skill は、次の点に実務的なガードレールを置きます。

• MUI v7 のコンポーネントパターン
• 主要なスタイリング手段としての sx
• package import の選び方
• responsive props の使い方
• theme 起点の設計判断

そのぶん、最初の生成結果を後から掃除する手間が減りやすくなります。

いちばん重要な差別化ポイント

この mui skill の価値は、網羅性の広さではありません。むしろ、MUI ユーザーが本当に気にするパターンへエージェントをしっかり絞り込める点にあります。

• v6 からの breaking changes を含む、v7 前提のガイダンス
• Box, Typography, Paper, Button, Grid2, Stack など、実際のアプリ UI でよく使う部品を中心にした例
• resources/styling-guide.md にある具体的なスタイリング指針
• resources/theme-customization.md にある実用的な theme 設定パターン

skill が明示している重要なバージョン注意点

この skill は、AI 生成コードでつまずきやすい MUI v7 の現実的な注意点をはっきり押さえています。

• deep import はもはや安全なデフォルトではなく、package exports を優先すべき
• Modal の onBackdropClick は削除されているため、onClose を使う
• slots と slotProps のパターンが標準化されている
• Tailwind v4 と enableCssLayer のような構成では CSS layers 対応が重要になる

こうした点だけでも、古いブログ記事や断片的な例に頼るよりこの skill を使う理由になります。

mui skill の使い方

mui skill のインストール方法

次のコマンドで、エージェントの toolkit context に skill を追加します。

npx skills add softaworks/agent-toolkit --skill mui

別の skills loader を使う環境でも、repo と skill slug は同じままにしてください: softaworks/agent-toolkit, skill mui。

mui skill を使う前に最初に読むべきもの

まずは次のファイルをこの順番で確認するのがおすすめです。

1. skills/mui/SKILL.md
2. skills/mui/resources/styling-guide.md
3. skills/mui/resources/component-library.md
4. skills/mui/resources/theme-customization.md
5. skills/mui/skill-rules-fragment.json

この順番に意味があるのは、resources 側に具体的な実装パターンがまとまっており、rules file ではどんなプロンプトやファイルが mui skill の発火対象になるのかが分かるためです。

mui skill に必要な入力

mui skill は、エージェントが適切なコンポーネント、レイアウト、theme パターンを選べるだけのフロントエンド文脈があるほど精度が上がります。特に有効なのは次の情報です。

• 作りたいコンポーネントまたはページ
• 使用中の MUI バージョン。特に migration 中なら重要
• スタイリングを sx、theme overrides、styled のどれで行うか
• xs, sm, md などのレスポンシブ要件
• form、dialog、card、navigation、layout の振る舞い
• src/theme.ts のような既存 theme ファイルのパス
• accessibility やデザイン上の制約

弱い入力:

• “Make this look better with MUI”

強い入力:

• “Create a responsive MUI v7 settings page using Container, Paper, Stack, TextField, and Switch, styled with sx, using theme spacing and palette tokens, with mobile-first layout and no hardcoded colors.”

ざっくりした要望を良い mui プロンプトに変える方法

mui skill をうまく使うプロンプトには、たいてい次の 5 要素が入っています。

1. 作りたい UI
2. 使うコンポーネント群
3. スタイリング方法
4. theme / responsive の制約
5. 出力形式

例:

“Using MUI v7, build a profile card component in TypeScript with Card, Avatar, Typography, and Button. Use sx only, reference theme palette and spacing, support xs to md responsive behavior, and return a self-contained component plus any extracted SxProps<Theme> styles.”

こうした依頼が汎用的な要望より優れているのは、MUI が想定するワークフローから逸れないよう、エージェントに明確な枠を与えられるからです。

実践的な mui skill の利用フロー

この mui skill で安定して結果を出しやすい進め方は次のとおりです。

1. タスクが component、layout、form、theming のどれかを切り分ける
2. 使いたい MUI primitives を具体的に指定する
3. 特別な理由がない限り、sx と theme token の使用を求める
4. レスポンシブ要件を明示する
5. 生成された import と v7 互換性を確認する
6. その後で spacing、variants、slot レベルの customization を詰める

この流れなら、最初のドラフトを本番に近い形に寄せやすくなります。

mui skill を呼び出しやすいトリガーフレーズ

repo 内の rule fragment では、次のような語を含むプロンプトが mui に特に適していると示されています。

• mui
• material-ui
• @mui/material
• sx prop
• ThemeProvider
• createTheme
• useTheme
• Dialog
• Drawer
• TextField
• Autocomplete

エージェントが skill を自動発火しない場合は、依頼文にこれらの語を意識して入れると有効です。

コンポーネント生成のベストプラクティス

エージェントには、この skill が重視するパターンに沿ったコードを出すよう求めましょう。

• @mui/material もしくは許容された package exports から import する
• スタイルを theme-aware に保つ
• スタイルの切り出しが再利用に効くなら SxProps<Theme> を使う
• Box, Stack, Container, Grid2 などの MUI レイアウト primitives を優先する
• レスポンシブ対応には sx 内の breakpoint object を使う

この組み合わせは、inline CSS、CSS modules、任意の utility classes を混在させるより、きれいな mui 出力になりやすいです。

theme 作業でのベストプラクティス

task が theme customization なら、対象範囲をはっきり伝えるのが重要です。

• palette のみ
• typography のみ
• component defaults
• dark mode
• アプリ全体の ThemeProvider 配線

プロンプト例:

“Update our MUI v7 theme to use a custom primary and secondary palette, Inter typography, rounded corners, and button text without uppercase. Show the createTheme object and the ThemeProvider integration.”

こうすると skill の theme resource と噛み合いやすく、theme に置くべき内容が場当たり的なローカルスタイルに散らばるのを避けられます。

この skill が特に対応しやすい repo ファイル

mui skill は、repo に次のようなファイルやシグナルがあると特に相性が良くなります。

• theme.ts or theme.tsx
• components/**/*.tsx
• *.styles.ts or *.styles.tsx
• @mui/material, @mui/icons-material, @mui/system からの imports

コードベースにすでにこうした要素があるなら、Frontend Development ワークフロー向けの導入候補としてかなり有力です。

最初の出力のあとに確認すべきこと

生成コードをそのまま受け入れる前に、次の点は必ずチェックしてください。

• imports が MUI v7 で有効か
• 非推奨の onBackdropClick が残っていないか
• responsive props が現行パターンで書かれているか
• 生の hex や px を多用せず、theme 値を使っているか
• Grid2 の使い方が、導入済み package の流儀と合っているか
• コンポーネントの customization に slots と slotProps を適切に使っているか

ここを先に確認すると、後で高くつく修正を早い段階で防げます。

mui skill FAQ

この mui skill は初心者にも向いていますか？

はい。React の基本が分かっているなら有用です。よくあるタスクに対して実践的な mui ガイドを提供してくれるので、いきなり公式ドキュメント全体を読み込まなくても進めやすくなります。ただし、React 自体が完全な初心者の場合は、component state、props、アプリ構成などで別途サポートが必要になることがあります。

mui skill は MUI の公式 docs の代わりになりますか？

いいえ。これは正式な API リファレンスの代替ではなく、実装を速めるための補助として使うのが適切です。より良い初稿を作り、バージョン違いのミスを避ける用途には向いていますが、境界的な props や細かな仕様は必要に応じて公式 docs で確認してください。

これは主に MUI v7 向けですか？

はい。それがこの skill を使う大きな理由のひとつです。古いサンプルが信用しづらくなる変更点を押さえているため、普段のプロンプトだと v5 や v6 時代のパターンが混ざってしまう人には特に有効です。

この mui skill を使わないほうがよい場面は？

次のような場合は見送って構いません。

• プロジェクトで MUI を使っていない
• フレームワーク非依存の design system の回答がほしい
• 生の CSS、Tailwind-first な出力、あるいは React 以外の UI 解決策がほしい
• task の中心が見た目ではなく business logic にある

こうしたケースでは、特化のメリットがあまり出ません。

直接 “Material UI code” と頼むのと何が違いますか？

普通のプロンプトだと、MUI の styling model やバージョン差分が抜け落ちがちです。mui skill は、sx、theme integration、responsive breakpoints、現行の component conventions にエージェントを寄せることで、出力の精度を上げます。結果として、書き直しの時間を減らしやすくなります。

mui skill は migration 作業にも使えますか？

はい。たとえば次のような migration 寄りの依頼と相性が良いです。

• deprecated API の置き換え
• imports の更新
• styling を sx に寄せる
• 古い customization コードを slots と slotProps に合わせて調整する

migration タスクでは、現在のバージョンと移行先バージョンを必ず明示してください。

mui skill をより良く使うには

エージェントに、より具体的な UI 仕様を渡す

mui 出力を最も手早く改善する方法は、「いい感じの component を作って」ではなく、次を具体的に定義することです。

• レイアウト構造
• component primitives
• responsiveness
• 見た目の方向性
• state の振る舞い
• theming のルール

たとえば “make a settings page.” ではなく、“two-column desktop, one-column mobile, Paper sections, primary CTA, TextField validation state, and theme-based spacing” のように指定したほうが、結果は大きく安定します。

どの styling path を使うか明示する

MUI には複数のスタイリング手段がありますが、この skill は大半の component 作業で sx を明確に優先しています。ここを指定しないと、出力がぶれやすくなります。

有効な指示:

• “Use sx for all local styling and keep values theme-aware.”

この 1 行だけでも、一貫性はかなり上がります。

既存の theme と design token を渡す

プロジェクトにすでに theme があるなら、関連する palette 名、spacing scale、typography の方針、component overrides を共有してください。mui skill は、架空の design system を作るより、実際の設計に合わせられると精度が大きく上がります。

共有すると効果が高い入力:

• theme.ts
• custom palette names
• typography variants
• dark mode requirements
• 優先したい radius と spacing のルール

style の切り出しは、意味があるときだけ求める

小さな component なら、inline の sx のほうが読みやすいことはよくあります。一方、再利用が多い、あるいは複雑なスタイルなら const styles: Record<string, SxProps<Theme>> を求める価値があります。ここを明示しないと、出力が細切れすぎるか、逆に詰め込みすぎになることがあります。

良い改善プロンプトの例:

• “Refactor repeated sx blocks into typed reusable style objects.”

よくある失敗パターンを見逃さない

mui の利用でよく起きる問題は次のとおりです。

• palette token ではなく色がハードコードされている
• theme spacing ではなく生の px が多すぎる
• 古い import や deprecated API が混ざる
• レスポンシブ対応が弱い
• MUI primitives で解決できるのに custom CSS を使いすぎる

こうした問題は、黙って後編集するより、プロンプトを締め直して直すほうが再現性が高いです。

ピンポイントの追加入力で反復する

最初のドラフトのあとに “improve this” とだけ言うのは避けましょう。1 回につき 1 種類の改善に絞るほうが有効です。

• “Make the layout mobile-first using breakpoint objects.”
• “Replace hardcoded colors with theme palette tokens.”
• “Convert the modal behavior to v7-safe onClose handling.”
• “Use slotProps for internal part customization.”

このやり方のほうが、mui skill は安定して期待に沿いやすくなります。

resource files をプロンプトの拠点として使う

結果を改善する実践的な方法として、skill 内の resource が扱っているテーマを明示的に言及する手があります。

• component library patterns
• styling guide patterns
• theme customization patterns

エージェントが実際にそれらのファイルを開かない場合でも、その語彙で促すことで、意図された mui ガイドの振る舞いに寄せやすくなります。

Frontend Development チームでの出力品質を上げる

チーム運用では、次の項目をプロンプトで標準化すると効果的です。

• MUI version
• TypeScript requirement
• デフォルトの styling としての sx
• theme token の使用
• breakpoint の期待値
• accessibility の基本要件
• import conventions

こうすると mui skill は、その場しのぎの補助ではなく、再現性のあるフロントエンド実装ツールとして機能しやすくなります。

mui skill が役立っているかを判断する方法

次の状態になっていれば、この skill はきちんと機能しています。

• 生成コードが既存の MUI コードベースになじむ
• 現行の v7 互換パターンを使っている
• import や styling の修正が少なくて済む
• あなたの theme を尊重している
• React 一般論のスタイリングに脱線しない

もしそうなっていないなら、たいてい必要なのは skill を捨てることではなく、文脈をもっと具体的に渡すことです。