Back to Details

mobbin-search

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Mobbin Search

Mobbin 搜索

Pull real app screenshots from Mobbin and visually analyze them before answering the user's design question.
从Mobbin获取真实应用截图，并在回答用户的设计问题前对其进行视觉分析。

Why this skill exists

本技能的存在意义

Design questions are best answered with concrete references, not generic advice. This skill routes those questions through Mobbin's library of curated app screens so your response is grounded in what real apps actually do rather than prior assumptions.
设计问题最好用具体参考来解答，而非通用建议。本技能将这类问题引导至Mobbin的精选应用界面库，让你的回复基于真实应用的实际做法，而非先入为主的假设。

Workflow

工作流程

1. Plan the search

1. 规划搜索

Before calling any tool, figure out:
  • Query terms — use the user's own words, or go broader. Never add specifics the user didn't mention — you'll bias results toward one pattern and miss the variety that makes this useful. E.g. "login screens" → search 
    login screen
    , not 
    login screen with username and password
    . The 
    deep
    search mode handles complex queries already; don't prematurely split into multiple searches and don't narrow with unrequested specifics.
  • Platform — 
    ios
    or 
    web
    . Infer from context:
    • Next.js/React/web app → 
      web
    • SwiftUI/React Native/mobile app → 
      ios
    • Unclear → ask the user before searching.
  • Limit — default to 
    5
    . Bump up (max ~15) only if the user asks for variety or specifies a count.
Don't decide about a board yet — that comes after you've seen the results.
调用任何工具前，需明确：
  • 查询关键词 — 使用用户的原话，或更宽泛的表述。切勿添加用户未提及的细节——这会让结果偏向某一种模式，错失多样参考的价值。例如：“登录界面” → 搜索
    login screen
    ，而非
    login screen with username and password
    。
    deep
    搜索模式已能处理复杂查询；不要过早拆分为多个搜索，也不要用未请求的细节缩小范围。
  • 平台 — 
    ios
    或
    web
    。根据上下文推断：
    • Next.js/React/web应用 → 
      web
    • SwiftUI/React Native/移动应用 → 
      ios
    • 不明确 → 搜索前询问用户。
  • 数量限制 — 默认设为
    5
    。仅当用户要求更多样性或指定数量时，可增加（最多约15）。
暂不决定是否制作看板——这要等查看结果后再确定。

2. Announce the plan, then proceed

2. 告知计划，然后执行

State the plan in one line, then call 
search_screens
in the same turn. The announcement is for expectation alignment, not permission — the user can redirect if they disagree, but don't pause for approval.
Example: "Searching 20 iOS login screens."
Keep it terse. Don't explain the tool.
用一句话说明计划，然后在同一轮调用
search_screens
。告知计划是为了对齐预期，而非请求许可——用户若不同意可提出修改，但无需等待批准。
示例：“正在搜索20个iOS登录界面。”
表述简洁，无需解释工具。

3. Call 
search_screens

3. 调用
search_screens

This is the tool to use for design reference. It runs the search server-side, fetches every matching image, and returns them to you as inline image content blocks — no download step, no Read step, no URL emission. You see the screens directly in the tool result.
The response contains:
  • A metadata text block: 
    { screens: [{index, id, app_name, mobbin_url, image_url, platform}], failed: [...] }
  • N image blocks, one per entry in 
    metadata.screens
    , in the same order
The 
index
field correlates each image with its app. 
image_url
is a debug/sanity-check reference — you don't need it for analysis.
这是用于设计参考的工具。它在服务器端运行搜索，获取所有匹配的图片，并将其作为内嵌图片内容块返回——无需下载步骤、无需读取步骤、无需输出URL。你可直接在工具结果中查看界面截图。
响应包含：
  • 元数据文本块：
    { screens: [{index, id, app_name, mobbin_url, image_url, platform}], failed: [...] }
  • N个图片块，与
    metadata.screens
    中的条目一一对应，顺序一致
index
字段将每张图片与其所属应用关联。
image_url
是用于调试/验证的参考——分析时无需使用。

4. Decide how to respond

4. 决定响应方式

After reading the screens, pick one of two modes based on what the user actually needs. Ground every observation in what you actually see — reference specific copy, element counts, colors, button labels. Avoid generic UX platitudes.
Mode A — Direct answer. The query is concrete and the answer lives in a short explanation + 1-3 screens. Just reply. Lead with the screens for inspiration asks, with concrete implementation details (spacing, copy, layout) for build-help asks. One-line notes per screen with Mobbin URLs.
Link format:
1. **N26** — Single-field login with biometric option. [View on Mobbin](https://mobbin.com/screens/...)
If there's a natural follow-up ("want more results?", "go deeper on any of these?"), make it the final line of your message — see the question-last rule below.
Mode B — Offer a board. The query benefits from dwelling: pattern extraction across a batch, side-by-side comparison of several apps, walkthrough of a flow, or inspiration browse with enough screens to warrant it. Ask the user what they want before building anything.
The ask is deliberately minimal — the user should see a clear recommendation with a couple of easy-to-scan escapes, not a paralysis-inducing menu of equal-weight choices. Shape it as:
  1. Preamble — one short sentence. A single observation that motivates your recommendation (e.g. "These 15 screens split into 3 clear approaches"). No findings list, no summary of patterns, no bullets describing what you saw. Save all of that for the board once the user picks. Front-loading findings buries the question and gives away the answer the board is supposed to carry.
  2. Options as a short numbered list — exactly 3 items. Numbered lists scan faster than prose when there are choices to make.
    1. Your recommendation, clearly labelled (
      **Recommended** — ...
      ) and described in plain English with a short reason it fits.
    2. "Describe your own layout (and any styling guidelines or other skills to apply)."
    3. "Just a text summary."
    Three items only — don't tack on additional named structures. If the user wants something different, they'll describe it under option 2.
  3. Question last. The final line is a real question the user can answer ("Which would you like?" / "Sound good?"). Nothing after it. The user should reach the end and know you're waiting on them.
Tone is consultative: one clear recommendation with easy escapes, not a neutral menu.
Example:
These 15 login screens split into 3 clear approaches.
  1. Recommended — a board grouped by pattern so you can scan the approaches side by side
  2. Describe your own layout (and any styling or other skills to apply)
  3. Just a text summary
Which would you like?
Wait for the user to pick before building.
查看截图后，根据用户实际需求选择两种模式之一。所有观察都要基于实际看到的内容——引用具体文案、元素数量、颜色、按钮标签。避免通用的UX陈词滥调。
模式A — 直接回答。查询内容具体，答案可通过简短说明+1-3张截图呈现。直接回复即可。若用户寻求灵感，先展示截图；若用户需要构建帮助，先给出具体实现细节（间距、文案、布局）。每张截图配一行说明及Mobbin链接。
链接格式：
1. **N26** — 带生物识别选项的单字段登录。[在Mobbin查看](https://mobbin.com/screens/...)
若有自然的后续问题（“需要更多结果吗？”、“要不要深入了解其中某一个？”），将其放在消息的最后一行——遵循“问题后置”规则。
模式B — 提供看板选项。查询内容需要深入分析：批量截图的模式提取、多款应用的并排对比、流程演示，或有足够多截图可供浏览的灵感需求。在构建任何内容前，先询问用户需求。
询问需简洁明了——用户应看到清晰的推荐和几个易于选择的选项，而非让人纠结的等权重菜单。格式如下：
  1. 开场白——一句话简短说明。一个能支撑你推荐的观察结论（例如：“这15张截图分为3种明确的设计方案”）。不要列出发现、总结模式，也不要用项目符号描述所见内容。这些内容留到用户选择后再放到看板中。提前展示结果会掩盖问题，也会让看板失去应有的价值。
  2. 选项为简短编号列表——恰好3项。编号列表比 prose 更易快速浏览选择。
    1. 你的推荐，明确标注（
      **推荐** — ...
      ），用简单易懂的语言描述并说明适配理由。
    2. “描述你自己的布局（以及任何样式指南或其他需应用的技能）。”
    3. “仅提供文字总结。”
    仅保留3项——不要添加额外的命名结构。若用户有其他需求，他们会在选项2中描述。
  3. 问题后置。最后一行是用户可回答的真实问题（“你想要哪一种？” / “这样可以吗？”）。之后无其他内容。用户看到结尾时应知道你在等待他们的回复。
语气要具有咨询性：给出一个明确的推荐和简单的替代选项，而非中立的菜单。
示例：
这15张登录界面截图分为3种明确的设计方案。
  1. 推荐 — 按模式分组的看板，方便你并排浏览不同方案
  2. 描述你自己的布局（以及任何样式或其他需应用的技能）
  3. 仅提供文字总结
你想要哪一种？
等待用户选择后再构建看板。

5. Build the board

5. 构建看板

Only after the user has picked a structure.
The board is the main artifact; the terminal text is just a signpost pointing to it. Do not duplicate the board's content in the terminal — that's the trap to avoid.
Self-contained static HTML file. No frameworks, no external CSS, no build step. Embed screens via 
<img src>
using 
image_url
from the search response — Mobbin CDN URLs work directly and expire roughly an hour later, fine for immediate viewing.
Structure the board for what the user picked. Pattern grouping → sections with thumbnail rows beneath each. Comparison → fixed columns per app, same rows across (copy, CTA, field count, etc.). Walkthrough → horizontal sequence in flow order. Tile → loose grid, app name + thumbnail, minimal chrome. Legibility over template-matching — adapt to the query.
If the user specified styling guidelines or pointed to other skills (e.g. 
design-principles
), apply them.
Regardless of structure:
  • Light theme by default — clean whites/off-whites for the page, dark text, subtle borders and dividers. Agents often overreach with dark themes and pick illegible colour combinations (low-contrast greys, muddy accents); a light theme is more forgiving and lets the screenshots carry the visual weight. Override if the user specifies a theme or points at a design system.
  • Let visuals carry the meaning, not words. The screens are the explanation — your chrome should recede. Prefer visual cues — grouping, whitespace, consistent thumbnail sizes, subtle labels/tags, colour coding, simple callouts drawn on images — over paragraphs or long bullet lists. Section headers and one-line captions are fine; a wall of bullets is a tell that you've defaulted to text when you should've defaulted to layout. When you catch yourself writing a list explaining what screens show, try to rework it as visual structure instead.
  • Link every screen back to its Mobbin URL so the user can click through
  • Include the app name on each screen
  • Consider click-to-enlarge (a plain 
    <a href>
    to 
    image_url
    opening in a new tab)
Save and open. Write to 
./.mobbin/<slug>-<YYYYMMDD-HHMM>.html
— relative to the current working directory, not 
/tmp
. Slug is a short readable description of the query (
ios-login-patterns
, 
fintech-dashboards
). Create the parent directory if missing. Open in the browser after writing (
open <path>
on macOS).
Then a short terminal message — that's it:
  • One-line headline finding
  • 2-3 bullets of top-level takeaways
  • Path to the board and a note that it's open in the browser
The depth lives in the board; the terminal is a signpost.
仅在用户选定结构后进行。
看板是核心产物；终端文本只是指向它的路标。不要在终端中重复看板内容——这是需要避免的陷阱。
生成独立的静态HTML文件。无需框架、无需外部CSS、无需构建步骤。使用搜索响应中的
image_url
通过
<img src>
嵌入截图——Mobbin CDN URL可直接使用，有效期约1小时，足以满足即时查看需求。
根据用户选择的结构构建看板。按模式分组→每个分组下显示缩略图行。对比→每个应用设固定列，各行内容一致（文案、CTA、字段数量等）。流程演示→按流程顺序水平排列。平铺→松散网格，显示应用名称+缩略图，尽量减少装饰。优先保证可读性，而非匹配模板——根据查询调整结构。
若用户指定了样式指南或指向其他技能（如
design-principles
），请应用这些要求。
无论采用何种结构：
  • 默认浅色主题 — 页面使用干净的白色/米白色，深色文本，细微边框和分隔线。AI Agent常过度使用深色主题，导致难以辨认的配色组合（低对比度灰色、浑浊的强调色）；浅色主题更宽容，能让截图成为视觉焦点。若用户指定主题或指向某个设计系统，可覆盖默认设置。
  • 让视觉元素传递信息，而非文字。截图本身就是解释——你的装饰元素应弱化。优先使用视觉提示——分组、留白、统一的缩略图尺寸、简洁的标签/标记、颜色编码、图片上的简单标注——而非段落或冗长的项目符号列表。章节标题和一行说明是可行的；大段项目符号说明截图内容，说明你默认使用文字而非布局来呈现信息。当你发现自己在写列表解释截图内容时，尝试将其重构为视觉结构。
  • 每张截图都要链接回其Mobbin URL，方便用户点击查看详情
  • 每张截图都要显示应用名称
  • 考虑添加点击放大功能（使用指向
    image_url
    的普通
    <a href>
    ，在新标签页打开）
保存并打开。保存至
./.mobbin/<slug>-<YYYYMMDD-HHMM>.html
——相对于当前工作目录，而非
/tmp
。Slug是查询内容的简短可读描述（如
ios-login-patterns
、
fintech-dashboards
）。若父目录不存在则创建。保存后在浏览器中打开（macOS使用
open <path>
）。
然后发送简短的终端消息——仅此而已：
  • 一行核心结论
  • 2-3个要点总结
  • 看板路径及已在浏览器中打开的提示
详细内容在看板中；终端只是路标。

6. Handle "show me more" follow-ups

6. 处理“展示更多”的后续请求

If the user wants more results, call 
search_screens
again — higher limit, or a refined query. The tool is cheap to re-call; no dedup logic needed on your end.
若用户需要更多结果，再次调用
search_screens
——增加数量限制，或优化查询词。工具调用成本低；无需进行去重逻辑。