responsive-design

responsive-design スキルの概要

responsive-design スキルは、container queries、fluid sizing、CSS Grid、Flexbox、モバイルファーストの breakpoints を使って、適応型インターフェースのための実装可能で現代的なガイダンスをエージェントに出させるのに役立ちます。responsive-design が特に向いているのは、実際の UI レイアウト、デザインシステムのコンポーネント、ダッシュボード、カード、ナビゲーション、あるいは大量データを扱う画面を構築していて、壊れやすいデバイス別 CSS を増やさずに複数の画面サイズへ対応したいケースです。

この responsive-design スキルが向いている人

単に「モバイル対応にして」で終わらない支援が必要なら、この responsive-design スキルが合います。フロントエンドエンジニア、実装レベルまで踏み込んで設計する UI デザイナー、そして一般的な media query の助言ではなく、コンポーネント単位の振る舞いまで含めた実践的な responsive patterns を求めるエージェント利用者に適しています。

実際にどんな仕事を進めやすくするのか

このスキルが本当に助けるのは、ざっくりしたレイアウト要件を responsive implementation strategy に落とし込む作業です。どこを fluid にすべきか、どこで breakpoints を切るべきか、viewport queries ではなく container queries を使うべき場面はどこか、そして異なるコンテキストでも再利用できるコンポーネントをどう保つか、といった判断を具体化できます。

汎用プロンプトと何が違うのか

汎用プロンプトだと、デバイス前提の breakpoints や media queries の増やしすぎといった、古い設計に寄りがちです。responsive-design スキルは、リポジトリ内で整理されている比較的新しい CSS パターンを軸にしており、とくに次の点が中心です。

• コンテンツ起点で考えるモバイルファーストの breakpoint 戦略
• 再利用可能なコンポーネントのための container queries
• clamp() を使った fluid typography と spacing
• viewport の課題とコンポーネント固有の課題を分けて考えるレイアウト設計

インストール前に最も確認したいこと

出力先が CSS、コンポーネント仕様、または UI 実装ガイダンスなら相性が良いです。一方で、見た目のモックアップだけが欲しい場合、no-code ツールの操作説明が欲しい場合、あるいは CSS の判断を伴わない framework 固有の抽象化だけが必要な場合には、あまり向きません。このリポジトリは reference 主体なので、価値の中心は自動化スクリプトではなく references/ にあるパターンと実例にあります。

responsive-design スキルの使い方

responsive-design のインストール前提

リポジトリルートの skill collection から次のコマンドでインストールします。

npx skills add https://github.com/wshobson/agents --skill responsive-design

upstream の skill には scripts や framework bindings が含まれていないため、インストールの主目的はこのガイダンスをエージェントから呼び出せるようにすることです。厳密な入力に基づいてコード生成するツールというより、ドキュメントとパターンを参照して使う skill だと考えるのが適切です。

最初に読むべきファイル

まずは次の順番で読んでください。

1. plugins/ui-design/skills/responsive-design/SKILL.md
2. plugins/ui-design/skills/responsive-design/references/container-queries.md
3. plugins/ui-design/skills/responsive-design/references/fluid-layouts.md
4. plugins/ui-design/skills/responsive-design/references/breakpoint-strategies.md

この順番には意味があります。コアの skill で対象範囲をつかみ、その後で reference を読んで実装の細部を補うことで、実際の出力品質が上がります。

このスキルに渡すべき入力

responsive-design スキルは、次の情報があると特に力を発揮します。

• コンポーネントまたはページの種類
• レイアウト上の制約
• 想定する画面コンテキスト
• responsiveness を viewport ベース、container ベース、または混在のどれで考えるか
• 利用する design system の tokens や breakpoint conventions
• browser support の要件

弱い入力:
“Make this responsive.”

より強い入力:
“Create a responsive card grid for a dashboard. Cards must work in a full-width page and in a narrow sidebar. Use container queries where component context changes, fluid spacing and type, and keep breakpoints aligned to our sm/md/lg token scale unless content forces a different threshold.”

曖昧な要件を強いプロンプトに変える方法

強い responsive-design usage のプロンプトは、たいてい次の 5 要素を含みます。

1. UI object: card list, nav bar, pricing table, form, data table
2. Behavioral changes: stack, wrap, collapse, resize, reorder, reveal
3. Constraint source: viewport, parent container, content width
4. System rules: token scale, grid rules, minimum tap size, accessibility needs
5. Output shape: CSS example, implementation plan, breakpoint rationale, refactor advice

プロンプト例:

“Use the responsive-design skill to propose a responsive strategy for a product comparison table. Prioritize small screens first, avoid horizontal overflow where possible, use content-based breakpoints, and explain whether container queries or viewport media queries should control each part. Include sample CSS for typography, spacing, and layout transitions.”

container queries を依頼すべきタイミング

コンポーネントがブラウザ幅だけでなく、配置される場所によって振る舞いを変える必要があるなら container queries を使うべきです。これは特に、再利用可能なカード、サイドパネル、ウィジェット、埋め込みモジュール、デザインシステムのコンポーネントで重要です。

コンポーネントが複数の親レイアウトに現れるなら、リポジトリ内の references/container-queries.md が最も役立つ参照先です。実用的な syntax、named containers、browser support に関する注意点まで含まれています。

breakpoints を増やすより fluid layouts を頼むべき場面

UI の課題が主にテキスト、余白、幅をなめらかにスケールさせることにあるなら、まず agent を fluid techniques に寄せるのが有効です。references/fluid-layouts.md は、硬い breakpoint の切り替えを増やすよりも、clamp()、relative units、intrinsic sizing を使って自然にリサイズさせたいときに役立ちます。

通常、次のような部分で改善しやすくなります。

• 見出しと本文テキスト
• セクション間の余白
• カードサイズ
• いきなり snap する前に余裕を持って伸縮してほしい grid

breakpoint ガイダンスをうまく使う方法

このリポジトリは、デバイス一覧ベースではなく、コンテンツ起点かつモバイルファーストの breakpoints を強く推しています。実務では、各 breakpoint をレイアウト上の圧力で説明させるのが有効です。たとえば line length、カードの窮屈さ、table の overflow、nav の折り返し、タップターゲットの問題などです。

チームですでに Tailwind や Bootstrap の breakpoint tokens を使っているなら、その点も明示してください。reference には一般的なスケールも載っているため、恣意的な値を新たに作るのではなく、既存システムに現代的な戦略を接続しやすくなります。

実案件でのおすすめ workflow

実践的な responsive-design guide の進め方は次のとおりです。

1. コンポーネントの内容と、小さいサイズ・大きいサイズでの failure modes を説明する。
2. いきなりコードを求める前に、まずレイアウト戦略を聞く。
3. 何を fluid にするか、何を snap させるか、何を reflow させるか決める。
4. 戦略が妥当だと確認できてから example CSS を求める。
5. ブラウザのプリセット幅だけでなく、実際の container widths で出力を検証する。
6. 初回の提案が抽象的すぎる場合は、スクリーンショット、DOM 構造、現在の CSS を渡して詰める。

最初から完成版の CSS を求めるより、この順序のほうが良い結果になりやすいです。

相性の良い出力フォーマット

次のような output shape を指定すると使いやすいです。

• responsive implementation plan
• breakpoint rationale table
• CSS starter pattern
• component refactor strategy
• audit of an existing layout
• “container query vs media query” decision

“give me responsive code” のような曖昧な依頼よりも、こうした形式のほうが判断が明確になります。

出力品質を上げる実践的なコツ

より良い responsive-design for UI Design の結果を得るには、次の情報を含めるのが有効です。

• レイアウトの関係性が重要なら、現在の HTML structure を含める
• コンテンツ量や文字数のばらつきが大きいかどうかを明記する
• 最低限読みやすい文字サイズと、最低限必要な interactive target size を伝える
• コンテンツの並べ替えを許容するかどうかを伝える
• container-query を多用する提案をさせる前に、legacy browser の制約を共有する

これらがないと、技術的には新しくても、実際の support matrix や component architecture に合わないパターンを選んでしまうことがあります。

responsive-design スキル FAQ

responsive-design スキルは初心者向けですか？

はい、基本的な CSS を理解していれば使えます。ただしこの skill は初心者向けチュートリアルというより、現代的な考え方を前提にした内容です。そのため、CSS を読めて、responsive に関する判断の質を上げたい人に最も向いています。初心者でも使えますが、container queries、intrinsic sizing、fluid scales といった用語は出てきます。

このスキルは framework 固有のコードを生成しますか？

主目的ではありません。リポジトリの内容は CSS パターン中心です。React、Vue、Tailwind、plain CSS 向けに調整してもらうことはできますが、コアの価値は framework integration の細部ではなく、responsive strategy のほうにあります。

responsive-design は普通の UI プロンプトより優れていますか？

responsive 対応がタスクの中心なら、多くの場合はこちらのほうが有利です。一般的なプロンプトは、古い breakpoint の癖や「モバイルでは縦積みにする」といった浅い助言に寄りがちです。responsive-design skill を使うと、レイアウト判断に対して、より明確で最新寄りの語彙と観点をエージェントに与えられます。

responsive-design を使わないほうがよいのはいつですか？

次のようなタスクが中心なら、無理に使わなくて大丈夫です。

• visual branding
• static mockup generation
• animation-heavy interaction design
• framework setup unrelated to layout
• adaptive behavior の判断を伴わない pixel-perfect recreation

また、チームが modern CSS features を使えず、IE 時代の互換性パターンを必要とする場合にも適合度は低めです。

browser support の懸念もカバーしていますか？

部分的にはカバーしています。reference には、特に container queries を中心に modern support への言及があり、graceful fallbacks もある程度示唆されています。ただし、これは compatibility matrix を専門に扱う skill ではありません。browser support が重要なら、最低対応ブラウザをプロンプトに明示してください。

design systems にも役立ちますか？

はい。breakpoint philosophy、token に揃えた spacing と typography、そしてコンテナをまたいで再利用できるコンポーネントの振る舞いを考えるのに適しています。とくに、ページごとの場当たり的な調整を減らし、より持ち運びやすいコンポーネントへ寄せたい design system で効果的です。

responsive-design スキルを改善するには

responsive-design スキルには実際の制約を渡す

品質が最も大きく上がるのは、制約条件を具体化したときです。実際の width、token 名、content sample、UI state を渡してください。“Responsive dashboard card” では曖昧ですが、“card used in 320px sidebar and 1200px main grid with long titles and two actions” なら判断可能な材料になります。

コードだけでなく判断を求める

より良いプロンプト:
“Use the responsive-design skill to decide which parts should use fluid sizing, which need breakpoints, and where container queries are justified.”

こちらのほうが、次のような依頼より強い reasoning を引き出せます。
“Write responsive CSS.”

リファクタリング時は既存 CSS を渡す

すでにレイアウトコードがあるなら、現在の CSS を貼り付けたうえで、単純化するよう依頼してください。そうすると、不要な media queries を削り、壊れやすい width 前提を見つけ、必要に応じて viewport-only のロジックをコンポーネント文脈に合ったルールへ置き換えやすくなります。

よくある失敗パターンに注意する

最初の出力が弱くなるのは、たとえば次のような場合です。

• コンテンツ上の根拠なしに breakpoints を推測している
• viewport rules のほうが単純なのに container queries を使っている
• fluid typography に min/max bounds がない
• レイアウト変更が accessibility や読みやすさを無視している
• 見本としてはきれいでも、実際の DOM structure に合っていない

こうした点は、各ルールの rationale を求め、どの UI の問題に対応しているのかを結びつければ修正しやすくなります。

初稿のあとに iteration prompts を使う

有効な follow-up prompts の例:

• “Reduce unnecessary breakpoints and explain what can be fluid instead.”
• “Refactor this so the component works in both narrow sidebar and wide content areas.”
• “Add fallbacks for teams that cannot rely fully on container queries.”
• “Audit this layout for overflow, cramped text, and awkward wrap points.”

最初から全面的な書き直しを求めるより、こうした追加入力のほうが実運用に載せやすい改善につながります。

画面サイズだけでなくコンポーネント文脈で検証する

responsive-design スキルの重要な洞察のひとつは、多くの失敗が viewport width だけを見て検証していることから起きる、という点です。結果を改善したいなら、同じコンポーネントを次のような場所でも確認してください。

• full page content
• sidebar
• modal
• dense dashboard grid
• embedded marketing section

コンテナによって振る舞いが変わるなら、その事実を最初から伝えることで、適切な responsive mechanism を選びやすくなります。

reference files をプロンプトの起点にする

より踏み込んだ出力がほしいときは、リポジトリの reference を直接指定してください。

• references/container-queries.md for component responsiveness
• references/fluid-layouts.md for smooth scaling
• references/breakpoint-strategies.md for mobile-first breakpoint decisions

これは、エージェントから generic frontend advice ではなく、より根拠のある responsive-design usage を引き出す最も簡単な方法のひとつです。

受け入れ基準を具体化して結果を改善する

次のような具体的な成果を目標として指定すると、この skill はぐっと使いやすくなります。

• media queries を減らす
• 指定幅未満で horizontal overflow を出さない
• 読みやすい line length を保つ
• container size をまたいで再利用できる components にする
• token に揃えた spacing と type を使う
• breakpoints 間の layout shift を最小化する

受け入れ基準が明確だと、responsive-design スキルは本番向けの UI 実装でより実用的になります。