adapt

adapt skill の概要

adapt ができること

adapt skill は、既存の UI を別の文脈向けに設計し直すためのスキルです。たとえば desktop から mobile、phone から tablet、web から print、mouse 前提から touch 前提へ、といったように、元の前提条件がそのまま通用しなくなるプラットフォーム移行に向いています。実運用では、adapt は単なる breakpoint 調整ではありません。対象デバイスや利用状況が変わるときに、レイアウト、操作方法、情報密度、ナビゲーション、タスクフローをどう再構成すべきかを整理して考えるための、構造化されたワークフローです。

adapt が向いている人

この skill は、デバイスやプラットフォームをまたぐ UI/UX 設計変更に取り組むデザイナー、PM、AI 支援でプロダクトを作る人に特に適しています。すでにデザインの方向性があり、それを別の文脈でも成立させたい場合、adapt は汎用的な design prompt より相性が良いです。理由は、元の前提、移行先の制約、そして adaptation のトレードオフを明示的に確認する作りになっているからです。

実際に解決したい課題

adapt for UI/UX Design を探している多くのユーザーが本当に知りたいのは、「この既存インターフェースを、使いやすさを損なわずに別のデバイスや利用文脈向けへどう変えるべきか」という実務的な判断です。adapt skill は、その判断を支えるために設計されています。「とりあえず responsive にして」という曖昧な依頼を、デバイス種別、入力方式、画面制約、実際の利用条件に結びついた具体的な adaptation plan に変えやすくします。

adapt が他と違う点

adapt の最大の違いは、いきなり解決案を出すのではなく、最初に文脈を集めることから始まる点です。上流では /frontend-design による事前の design context を前提としており、その文脈がまだない場合は、先に /teach-impeccable を実行するよう案内されます。一般的な prompt よりも運用がやや厳格に見えるかもしれませんが、そのぶん、レイアウト・操作・ユーザー期待がまとめて変わるような、簡単ではない adaptation で信頼性が上がります。

向いているケース / 向いていないケース

adapt skill を使うべきなのは、次のような場面です。

• 既存 UI を新しいデバイスやプラットフォームへ移行する
• 何を変えるべきか、何を維持すべきかを整理したい
• responsive behavior、touch target、navigation、density が重要な論点になっている

一方で、次の条件では強い結果は期待しにくいです。

• 元デザインの説明がほとんどない
• 移行先の文脈が明確になっていない
• 既存 UI の adaptation ではなく、まったく新しい product design が必要

adapt skill の使い方

インストール前提と adapt の場所

adapt skill は pbakaus/impeccable repository の .agents/skills/adapt に含まれています。GitHub から skill をインストールできる環境なら、通常の skill install フローでその repo と skill slug を指定してください。基本例は次のとおりです。

npx skills add pbakaus/impeccable --skill adapt

すでに agent 側で repo や bundled skills が使える状態なら、skill 名を指定して呼び出すだけで済む場合もあります。

まず読むべきファイル

最初に確認するのは次です。

• .agents/skills/adapt/SKILL.md

この skill には、提供されている tree 上で追加の script、reference、helper asset がありません。実務上のガイダンスのほぼすべてが SKILL.md に入っています。素早く評価しやすい一方で、セットアップ負荷は低いものの、自動化の仕組みは少なめです。

adapt を使う前の必須依存関係

導入時に重要なのは、adapt が単独実行を前提としていないことです。skill 内でも、design principles、anti-patterns、Context Gathering Protocol を含む /frontend-design を先に実行するよう明記されています。さらに、まだ design context が存在しない場合は、進める前に /teach-impeccable を実行するよう指示されます。

つまり、実際の adapt install 判断は、単に機能の有無ではなくワークフロー適合性の問題です。

• より広い impeccable design system を受け入れられるか
• adaptation 作業の前に構造化された design context を作りたいか
• agent が関連 skill を順番に呼び出せるか

ここが合わないと、adapt は one-shot prompt より窮屈に感じる可能性があります。

adapt に必要な入力

adapt skill を有効に使うには、最初から次の情報を渡すのが理想です。

• source context: 現在の design が何向けに作られているか
• target context: どの device、platform、medium に adaptation するのか
• input method: touch、mouse、keyboard、voice、remote など
• screen constraints: サイズ、向き、密度、viewport の制約
• usage context: ぱっと確認する用途か、集中作業か、移動中か、低 bandwidth か
• current pain points: 現在どこが壊れているか、どこで体験が劣化しているか
• must-preserve elements: タスク、brand pattern、navigation model、hierarchy など維持必須の要素

これらがないと、出力は generic な responsive advice に寄りがちです。

adapt の依頼文の組み立て方

この skill には、次の argument hint があります。

[target] [context (mobile, tablet, print...)]

弱い依頼の例:

• Use adapt on this dashboard

より良い依頼の例:

• Use adapt for our analytics dashboard from desktop web to mobile touch. Preserve core reporting tasks, quick KPI scanning, and drill-down access. Assume portrait phone, intermittent mobile connection, and one-handed use.

後者が機能しやすいのは、source、target、constraints、success criteria がそろっているからです。

ラフな要望を完成度の高い prompt にする

adapt usage の質を上げたいなら、prompt は次の順で組み立てると効果的です。

1. 現在の interface を説明する
2. 新しい context を示す
3. ユーザーが引き続き完了できるべき主要 task を挙げる
4. 環境上の制約を明記する
5. 単なる layout 変更ではなく、tradeoff の提示を求める

例:

“Use adapt for UI/UX design. We have a desktop SaaS settings page with left-nav, dense forms, inline help, and comparison tables. Adapt it for tablet and mobile touch use. Users mainly update profile, billing, team roles, and API keys. Preserve security-critical clarity. Assume portrait-first mobile, occasional poor connection, and shorter sessions. Recommend what to collapse, reorder, paginate, or defer.”

adapt が分析しやすいポイント

skill の記述を見る限り、adapt は主に次の観点を評価する設計です。

• 元の design assumptions
• target device と usage expectations
• 文脈間での interaction の違い
• adaptation 上の課題と tradeoff

特に価値が出やすいのは、変化が viewport size だけにとどまらないケースです。たとえば desktop-to-mobile touch、web-to-print、mouse-first から keyboard-first への移行は、「このページを少し狭くしたい」といった相談よりも adapt に向いています。

手探りを減らす実践的なワークフロー

adapt guide を使うなら、次の流れが安定しやすいです。

1. /frontend-design を実行する
2. 必要に応じて /teach-impeccable で design context を集める、または作る
3. 現在の UI を見た目だけでなく task ベースで要約する
4. target context と constraints を添えて adapt を呼ぶ
5. 提案内容を、見た目の良し悪しではなく task が維持されているかで確認する
6. 初回出力が generic なら、優先順位を明確にして再実行する

この順序が重要なのは、adapt の品質が、agent が元の design intent を理解できているかに大きく左右されるためです。

出力品質でユーザーが最も重視する点

良い adapt の出力では、少なくとも次が分かるべきです。

• 元デザインのどの前提がもう成立しないか
• 単なるサイズ変更で済む部分と、再設計が必要な部分
• input method の変化が interaction design にどう影響するか
• information hierarchy をどう変えるべきか
• 新しい context に合わせて何を簡略化し、隠し、移すべきか

もし出力が breakpoints と flexible grids の話だけに終始するなら、その skill の価値を十分に引き出せていません。

UI/UX Design で adapt が特に役立つ場面

adapt for UI/UX Design が特に有効なのは、次のようなケースです。

• desktop 向け admin tool を mobile でも使えるようにする
• 機能の多い web app を tablet workflow に適応させる
• touch target や density の見直しが必要な interface
• attention span や connection quality の違いに対応すべき layout
• 画面サイズだけでなく、platform ごとの期待値そのものが変わる移行

adapt skill FAQ

adapt は responsive design prompt と同じですか

いいえ。adapt は responsive design も扱いますが、実際の範囲はもっと広く、device context、input method、platform expectations、usage conditions まで含みます。CSS の layout 調整だけでなく、振る舞いや task flow の adaptation が問題になるときに、より役立ちます。

adapt は初心者にも使いやすいですか

ある程度は使いやすいですが、前提として現在の design をはっきり説明できる必要があります。skill 自体が構造化されているので、初心者でも「mobile-friendly にして」で終わる浅い依頼を避けやすいのは利点です。ただし、上流の /frontend-design による context を前提とするため、完全な初心者にはそのワークフロー理解が最初のハードルになります。

どんなときに adapt を使うべきではありませんか

adapt skill は、ゼロから product を考えるとき、visual style を決めたいとき、あるいは generic な UI inspiration が欲しいときには向きません。強みが出るのは、すでに既存 interface があり、そこから具体的な target context に向けて設計を変えたい場合です。

adapt は普通の prompting と何が違いますか

通常の prompt は、すぐ解決案に飛びがちです。adapt は、source assumptions を特定し、target context を定義し、何を変えるべきかを論理立てて考えるよう促します。その結果、表面的な提案が減り、design tradeoff の質が上がりやすくなります。

adapt には code や実装用 asset も含まれますか

提供されている repository の範囲では、ありません。この skill はガイダンス中心で、主要 asset は SKILL.md、skill folder 内に補助 script や reference は見当たりません。内容を確認しやすい反面、自動で implementation scaffolding までしてくれることは期待しないほうがよいです。

adapt は mobile 専用ですか

いいえ。argument hint と skill の記述には mobile、tablet、print、そのほかの context も含まれています。adapt は、layout、input、user behavior が変わる意味のある環境変化全般に使えます。

adapt skill を改善するには

source context の説明をもっと具体的にする

adapt の結果を最も手早く改善する方法は、現在の interface を次の観点で説明することです。

• primary user tasks
• layout structure
• interaction patterns
• pain points
• 現行 design が置いている assumptions

たとえば “dashboard page” よりも、“dense table with hover actions and side-by-side filters” のほうがはるかに有用です。

target device だけでなく target constraints まで指定する

“Mobile” だけでは広すぎます。より良い入力例は次のようなものです。

• portrait phone
• one-handed use
• touch-only
• weak connection
• short sessions
• outdoor glare
• keyboard access required

こうした条件で、skill が提案すべき内容は大きく変わります。

守るべき優先事項を明示する

adapt には、何を壊してはいけないのかを伝えてください。

• critical workflows
• visibility of key information
• compliance や security の明確さ
• navigation discoverability
• comparison ability
• editing efficiency

これにより、スペースや操作制約のために単純化が必要な場合でも、skill がより適切な tradeoff を出しやすくなります。

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

主な failure mode は、浅い adaptation です。列を縦に積み、card を縮め、それで終わりにしてしまう状態です。最初の出力が generic な responsive advice に見えるなら、次の観点で再検討するよう依頼してください。

• 新しい context での user intent の変化
• desktop 前提の assumptions の除去
• navigation の再構成
• target input method に合わせた interaction redesign

アイデアだけでなく判断を求める

より実用的な adapt guide の出力を得るには、次のような問い方が有効です。

• What should be removed from the first screen?
• What should become progressive disclosure?
• Which tasks need a different flow on touch devices?
• What desktop patterns fail in the target context?

こうした聞き方をすると、広い原則論ではなく、実行可能な adaptation 判断に寄りやすくなります。

1 回目の後は具体的な artifact を足して改善する

初回実行の後は、次のような情報を追加すると結果がかなり具体化します。

• 画面一覧
• component list
• ラフな wireframe の説明
• テキストで要約した screenshots
• 現在の user complaints

抽象的な product label ではなく、実際の interface structure をもとに考えられるようになると、skill の精度は大きく上がります。

adapt を design judgment の代わりではなく補助として使う

adapt の最も良い使い方は、構造化された reviewer 兼 planner として使うことです。前提や redesign の圧力点を洗い出すのには役立ちますが、提案内容は必ず自分たちの product constraints、implementation cost、user research と照らして検証してください。特に、複雑な enterprise 向け UI や workflow-heavy な interface を adaptation する場合は、この確認が重要です。