Mobbin

Use Mobbin MCP as the only primary source of design inspiration for UI/UX pattern work. Mobbin is a curated library of shipped mobile and web screens/flows — not portfolio mockups. The MCP returns real references (images + metadata + Mobbin links) so agents stop guessing generic UI.

Hard gate: Do not propose, sketch, or implement new UI direction until Mobbin MCP has returned references for this task — or until the user explicitly waives the gate after you reported MCP unavailable.

Workflow

1. Confirm Mobbin MCP — Discover the Mobbin MCP server and its tools. If the server is missing, unauthorized (needsAuth), or errors, stop UI invention and follow mcp-setup.md. Authenticate when required; do not proceed on memory.
2. Frame the design question — Product surface, platform (ios | web), user job, constraints (brand, density, a11y), and whether you need a single screen, a multi-step flow, or a marketing/site section. Ask only the clarifying questions that change search intent.
3. Search with the right tool — Follow search-playbook.md:
   • search_screens — one screen / layout / component composition
   • search_flows — multi-step journeys (onboarding, checkout, KYC, permissions)
   • search_sections — website sections (pricing, footers, heroes, feature grids)
4. Inspect results — Open/read returned images and mobbin_url links. Prefer concrete UI structure, hierarchy, CTAs, and empty/error states over vague “looks modern.”
5. Synthesize, don’t clone — Extract patterns (hierarchy, progressive disclosure, trust signals, motion of the flow) and adapt to the project’s brand/system. See synthesis.md.
6. Iterate searches — If results are weak, repeated, or off-domain, rewrite the query (more UI detail, named peer apps, exclude prior screen IDs). Run a second/third focused search before designing.
7. Only then design or code — Ground proposals in cited Mobbin references (app name + link). Keep fidelity appropriate (low/mid wire first unless asked for polished UI).