mobbin-search

Mobbin 検索

Mobbin から実際のアプリのスクリーンショットを取得し、ユーザーのデザインに関する質問に回答する前に、見た目を分析します。

このスキルがある理由

デザインに関する質問には、一般的なアドバイスではなく、具体的な参考例に基づいて回答するのが最適です。このスキルでは、厳選されたアプリ画面を集めた Mobbin のライブラリを使って質問を調べ、過去の思い込みではなく、実際のアプリで採用されている手法に基づいて回答します。

ワークフロー

1. 検索を計画する

ツールを呼び出す前に、次の点を決めます。

• 検索語 — ユーザー自身の言葉を使うか、より広い語句を使います。ユーザーが言及していない具体的な条件は追加しないでください。検索結果が特定のパターンに偏り、この検索の価値である多様性が失われます。たとえば、「ログイン画面」なら login screen で検索し、login screen with username and password とはしません。deep 検索モードは複雑なクエリに対応しているため、早まって複数の検索に分けたり、依頼されていない条件で絞り込んだりしないでください。
• プラットフォーム — ios または web。文脈から判断します。
  • Next.js／React／Web アプリ → web
  • SwiftUI／React Native／モバイルアプリ → ios
  • 不明な場合 → 検索前にユーザーに確認します。
• 件数 — デフォルトは 5 です。ユーザーが多様な結果や件数を指定した場合に限り、最大で約 15 件まで増やします。

結果を見るまでは、ボードについて決めないでください。ボードの判断はその後に行います。

2. 検索計画を伝えてから実行する

計画を1行で伝えた後、同じターン内に search_screens を呼び出します。この案内は、ユーザーと認識を合わせるためのものです。許可を得るためのものではありません。ユーザーが異議を唱えた場合は変更できますが、承認を待ってはいけません。

例：「iOS のログイン画面を20件検索します。」

簡潔にしてください。ツールについて説明する必要はありません。

3. search_screens を呼び出す

デザインの参考例を探すには、このツールを使います。サーバー側で検索を実行し、一致するすべての画像を取得して、インライン画像コンテンツブロックとして返します。ダウンロードも Read ステップも必要なく、URL を出力することもありません。ツールの結果で画面を直接確認できます。

応答には次の内容が含まれます。

• メタデータのテキストブロック：{ screens: [{index, id, app_name, mobbin_url, image_url, platform}], failed: [...] }
• metadata.screens の各項目に対応する画像ブロック N 個（同じ順序で並びます）

index フィールドを使って、各画像とアプリを対応付けます。image_url はデバッグや確認のための参照情報です。分析に使う必要はありません。

4. 応答方法を決める

画面を確認したら、ユーザーが実際に必要としている内容に応じて、2つのモードから選びます。観察内容は、実際に見たものに基づかせてください。具体的なコピー、要素の数、色、ボタンのラベルを挙げます。一般論に終始したUXの決まり文句は避けてください。

モード A — 直接回答。 質問が具体的で、短い説明と1〜3画面で答えられる場合は、そのまま回答します。インスピレーションを求める質問では画面を先に示し、実装の支援を求める質問では間隔、コピー、レイアウトなどの具体的な詳細を示します。各画面について、MobbinのURLを添えた1行の注記を付けます。

リンク形式：

1. **N26** — Single-field login with biometric option. [View on Mobbin](https://mobbin.com/screens/...)

「もっと結果を見たいですか？」「どれか詳しく見ますか？」など、自然なフォローアップがある場合は、次の質問を最後に置くルールに従って、メッセージの最後の行に記載します。

モード B — ボードを提案。 複数の画面からパターンを抽出する場合、複数アプリを並べて比較する場合、フローを順に確認する場合、または十分な数の画面を見ながらインスピレーションを探す場合は、内容を掘り下げるのが有効です。何かを作る前に、ユーザーの希望を尋ねます。

質問はあえて最小限にします。ユーザーが目にするのは、明確なおすすめと、ひと目で確認できる選択肢です。どれを選べばよいか迷うような同等の選択肢を並べないでください。次の形式にします。

1. 前置き — 短い文を1つ。 おすすめの理由となる観察を1つだけ述べます（例：「この15個の画面は、3つの明確なアプローチに分かれています」）。確認した内容のリストやパターンの要約、観察結果を説明する箇条書きは含めません。そうした内容は、ユーザーが選んだ後にボードで示します。先に観察結果を提示すると、質問が埋もれるだけでなく、ボードで伝えるべき内容まで明かしてしまいます。

2. 短い番号付きリストで選択肢を提示 — 項目は必ず3つ。

   1. おすすめを明確に示します（**おすすめ** — ...）。なぜ適しているかを短く添え、平易な表現で説明します。
   2. 「独自のレイアウト（スタイリングのガイドラインや適用するその他のスキルがあれば、それも含む）を説明する。」
   3. 「テキストのみの要約。」

   項目は3つだけにします。追加の名称付き構成を付け足さないでください。別の希望がある場合は、選択肢2で説明してもらいます。

3. 質問を最後に置く。 最終行は、ユーザーが答えられる実際の質問にします（「どれにしますか？」／「よろしいですか？」）。その後には何も追加しません。読み終えたユーザーが、返答を待たれているとわかるようにします。

トーンは相談に応じる形にします。中立的な選択肢の羅列ではなく、明確なおすすめと、選びやすい代案を提示します。

例：

この15個のログイン画面は、3つの明確なアプローチに分かれています。

1. おすすめ — パターンごとにまとめたボードで、各アプローチを並べて確認できます
2. 独自のレイアウト（スタイリングや適用するその他のスキルがあれば、それも含む）を説明する
3. テキストのみの要約

どれにしますか？

ユーザーが選ぶまで、作成を始めないでください。

5. ボードを作成する

ユーザーが構成を選んだ後にのみ作成します。

ボードが主な成果物です。ターミナルのテキストは、ボードへ案内する標識にすぎません。ボードの内容をターミナルに重複して表示しないでください。避けるべき落とし穴です。

自己完結型の静的 HTML ファイルにします。フレームワーク、外部 CSS、ビルド手順は使いません。検索結果の image_url を使って、<img src> で画面を埋め込みます。Mobbin の CDN URL はそのまま使え、約 1 時間で期限切れになりますが、すぐに表示する分には問題ありません。

ユーザーが選んだ内容に合わせてボードを構成します。パターンごとにまとめる場合は、セクションの下にサムネイルを並べます。比較の場合は、アプリごとに固定列を設け、各アプリで同じ行（コピー、CTA、フィールド数など）を並べます。ウォークスルーの場合は、フローの順に横並びで配置します。タイルの場合は、アプリ名とサムネイルを配置した、装飾を抑えた自由なグリッドにします。テンプレートに合わせることよりも、読みやすさを優先してください。クエリに合わせて調整します。

ユーザーがスタイルガイドラインを指定したり、ほかのスキル（例：design-principles）を参照したりしている場合は、それらを適用します。

構成にかかわらず、次の点を守ってください。

• デフォルトはライトテーマにします。ページには清潔感のある白やオフホワイトを使い、文字は濃色にし、境界線や区切り線は控えめにします。エージェントはダークテーマを選びがちで、読みにくい配色（コントラストの低いグレーや濁ったアクセントカラー）を採用しがちです。ライトテーマなら、より幅広い用途に対応でき、スクリーンショットの視覚的な存在感を活かせます。ユーザーがテーマを指定している場合や、デザインシステムを参照している場合は、その指定を優先します。
• 意味を伝えるのは言葉ではなくビジュアルです。説明の主役は画面です。周囲の装飾は控えめにします。文章や長い箇条書きより、グループ分け、余白、サムネイルのサイズ統一、控えめなラベルやタグ、色分け、画像に描いたシンプルな注釈など、視覚的な手がかりを優先します。セクション見出しや一行のキャプションは問題ありません。箇条書きが続く場合は、レイアウトを優先すべきところでテキストに頼っているサインです。画面に何が表示されているかを説明するリストを書いていることに気づいたら、視覚的な構成に置き換えることを検討してください。
• すべての画面に Mobbin の URL へのリンクを付け、ユーザーがクリックして移動できるようにします。
• すべての画面にアプリ名を表示します。
• クリックして拡大できるようにすることも検討してください（image_url への通常の <a href> で、新しいタブに開きます）。

保存して開きます。 ./.mobbin/<slug>-<YYYYMMDD-HHMM>.html に書き込みます。/tmp ではなく、現在の作業ディレクトリからの相対パスを使います。slug はクエリを短く分かりやすく表したものにします（ios-login-patterns、fintech-dashboards など）。親ディレクトリがない場合は作成します。書き込み後、ブラウザーで開きます（macOS の場合は open <path>）。

その後、ターミナルには短いメッセージだけを表示します。

• 要点を一行で示す見出し
• 主なポイントを 2～3 個の箇条書きで示す
• ボードのパスと、ブラウザーで開いたことを記載

詳しい内容はボードに載せ、ターミナルは案内に徹します。

6. 「もっと見せて」という追加の依頼に対応する

ユーザーがさらに結果を求めた場合は、search_screens をもう一度呼び出します。上限を増やすか、クエリを調整します。このツールは気軽に再呼び出しできるため、こちらで重複排除を行う必要はありません。