{"id":46771,"plugin_id":"plugin_asdk_app_6ac8e57de9848191ae058d271d90184b","kind":"skill","collection_source":"plugin_package","comparison_source":null,"observed_at":"2026-10-24T13:31:03.140Z","digest":"bd4d2108f5004f8f50c77b449ae7fc6e19171378fbb6a03733449641233448c5","against":null,"payload":{"description":"Find active listings matching a client brief and build a shortlist. Use when the user asks about find listings, property search, homes or apartments for sale or rent, client shortlist.","included_files":[{"relative_path":"references/popety-kit.html","size_in_bytes":17333}],"name":"listing-hunter","skill_md_contents":"---\nname: listing-hunter\ndescription: \"Find active listings matching a client brief and build a shortlist. Use when the user asks about find listings, property search, homes or apartments for sale or rent, client shortlist.\"\ndisable-model-invocation: false\n---\n\n<!-- GENERATED FROM api/popety-mcp/src/prompts.ts — do not edit; run pnpm --filter @popety-io/mcp generate:integrations -->\n\n# Listing hunter\n\nFind active listings matching a client brief and build a shortlist.\n\n**Arguments to collect from the user:**\n\n- `location` — Commune (municipality) name, e.g. \"Nyon\". (required)\n- `deal_type` — \"sale\" or \"rent\". Defaults to \"sale\". (optional)\n- `budget_max_chf` — Maximum price in CHF (optional). (optional)\n- `rooms_min` — Minimum number of rooms (optional). (optional)\n- `property_type` — One of: apartment, house, commercial, land, parking (optional). (optional)\n\n## Workflow\n\nShortlist current on-market sale listings in <municipality> for a client. Follow these steps exactly:\n\n1. BUILD THE FILTERS\n   Call search_entities with:\n   { entity_type: \"listings\", filters: { area: { municipality: \"<municipality>\" },\n     transaction_type: \"sale\", active: true } }\n   ALWAYS keep active: true — the client wants current inventory, not the ~8M historical listings.\n\n2. PREVIEW FIRST (free)\n   Run the call above with preview: true. This search bills per returned object — if object_count is large, tighten the filters (budget, rooms_min, living_area_min_m2) BEFORE the paid call.\n\n3. RUN THE FULL SEARCH\n   Repeat the call without preview, passing the query_id from step 2, sort: \"listing_timestamp_desc\", and limit: 10.\n\n4. THE DOCUMENT\n   Structure the shortlist document as:\n   - Title + a one-line recap of the brief (location, deal type, budget, rooms).\n   - Shortlist as PHOTO CARDS (kit card primitive): the listing's first image (urls_image[0]), price bold, then rooms · m² · CHF/m² · bedrooms and parking where present · listing age — and the portal link (portals[].url) as \"View on <portal>\". Client briefs are often written in bedrooms: match against bedrooms when present but NEVER exclude listings missing it (coverage ~1 in 3; absence = unknown, not zero).\n   - Standouts: the best fits and why, flagging listings priced above the commune's asking median — optionally cross-check with entity_stats { entity_type: \"listings\", filters: { municipality: \"<municipality>\", deal_type: \"sale\" }, section: \"price_per_room\" } (0.50 credits) and compare each listing to the median of its room band (section figures span the full listing history, not only active ads).\n   - Next-step line: offer the neighborhood_profile prompt on a favourite or the value_estimate prompt to sanity-check an asking price — whichever fits the brief.\n   Notes-line material: results are advertised listings — availability changes fast; verify with the lister before presenting to the client.\n\nPRESENTATION — how to write the final answer (applies to every step above):\n- The answer is a client-ready document that will be shared as-is. Not a chat log, not an analysis diary.\n- Open with a title line (subject + commune + date) and a one-line verdict a reader would pay for. Never open with method, tool narration, or what you are about to do.\n- The reader is a real-estate professional (broker, investor, developer). Every section closes with ONE analyst paragraph stating the professional implication — pricing, absorption, sourcing, underwriting — never a definition or a tutorial sentence. Show sample sizes and visibly de-emphasise figures resting on fewer than 3 observations.\n- 3–6 titled sections, ordered by what matters most to the reader; one idea per section. Prefer short prose with embedded figures; use a table only when comparing 3+ items across 2+ dimensions, max ~6 rows, one comparison per table. Select the figures that change the reader's decision — do not dump every number you retrieved.\n- Swiss formats: CHF 1'250'000 (apostrophe thousands), m², CHF/m²; official Swiss real-estate terminology in the reader's language. Write the whole document in the language the user wrote in.\n- Caveats: at most ONE short \"Notes\" line at the end of the document (e.g. coverage gaps, asking ≠ realised prices). Never inline a disclaimer after a figure. Never mention tools, credits, section ids, API mechanics, or observations \"for the platform team\" inside the document — if you have a genuine data/product observation, put it after the document under a separate \"---\" divider, in one or two lines.\n- Close the document with at most ONE \"Next step\" line offering the single most relevant follow-up — an offer, not a menu.\n- In clients that support artifacts/canvas, render the document as a styled artifact (clean typography, generous spacing, no emojis) and keep the chat reply to a two-line summary; otherwise use clean markdown with real headings.\n\n---\n\nRequires the Popety connector (bundled with this plugin — authenticate on first use). Follow the workflow's cost gates: free/preview steps before any paid call.\n\n## Building the document\n\nWhen the client supports artifacts, render the final document as a plain HTML artifact (NEVER React/JSX — a JSX rewrite loses the stylesheet) built from `references/popety-kit.html` (bundled with this skill): read the kit FIRST, paste its ENTIRE <style> block verbatim as the stylesheet (never write your own CSS), give every SVG mark its literal hex fill/stroke attribute PLUS the kit mark class (mk1-mk4, mkband, mktick, mkline), and follow its primitives, helpers and rules — Popety brand in both themes, Swiss number formats, inline-SVG charts with tooltips, one analyst paragraph per section written for a real-estate professional. The finished document must visibly carry the Popety cyan (brandbar, kicker, verdict block, KPI accents, chart fills) — a grey/monochrome document means the kit was not applied. Without artifact support, apply the same structure in clean markdown.\n"},"changes":[],"summary":"First saved snapshot. No earlier version is available for comparison.","summary_kind":"deterministic","summary_metadata":{}}