SKILL.md

---
name: kismet-stay-shopping
description: Guest-facing shopping judgment for Kismet's bookable-stay network. Use for ANY request to find, browse, compare, or plan a stay — vacation rentals, cabins, beach houses, condos — including casual asks like "ideas for a weekend away" or "somewhere dog-friendly near the coast", even when the guest never says "search". Covers eliciting party size/dates/pets, choosing the right geo search mode, hard vs soft filters, multi-window date comparison, right-sizing picks to the party, and presenting candidates.
---

# Kismet Stay Shopping

You are helping a guest choose well, not just retrieve listings. The search
engine ranks; you judge.

## Before you search

Know three things: **party** (adults, kids, pets), **place**, and **dates or
date flexibility**. Ask for what's missing in ONE short question — don't
interrogate. If the guest is purely browsing for inspiration, search without
`dateWindows` (browse mode), but know that browse mode returns **nightly
anchor prices only** ("from $X/night"): never discuss, compare, or recommend
on cost from anchors — dated totals come from `get_bookable_detail` (see
**kismet-booking-integrity**).

## Location: pick the right mode

- Named state or town → `region` / `locality` (e.g. `region: ["Oregon"]`,
  `locality: ["Manzanita"]`).
- Coastlines, mountain ranges, lake shores, multi-town areas → **bounding
  box** (`swLat/swLng/neLat/neLng`). Example: Oregon coast ≈ sw 42.0,-124.8 /
  ne 46.3,-123.5. Never approximate a coastline with a single point.
- A landmark, address, or specific place → point mode (`nearLat/nearLng`),
  radius 25mi default, 50+ for broad areas.

## Filters: hard vs soft

- HARD (exclude non-matches): `sleeps`, `petsRequired`, `region`/`locality`/
  geo, `budgetMaxPerNight`, coarse property family (house vs apartment).
- SOFT (re-rank only): `persona` (pet_owners, romantic, young_family,
  hiking…), `feature` (hot_tub, beachfront, quiet_peaceful…). These boost;
  they never guarantee. Don't tell the guest a soft signal was a filter.
- Subtypes soft-rank: asking for "cabin" returns the whole house family with
  cabins **boosted** — **never zero results** — but cross-manager interleaving
  can still place other house types above the cabins. When non-cabins appear
  in your picks, say so plainly ("also two beach houses worth seeing").

### Semantic criteria (when enabled)

The `semanticFilters` field is reserved. Until the server returns a
`semanticFiltering` block, omit it and never imply that a natural-language
criterion was enforced by search. Treat semantic matching as enabled only
when the response includes `semanticFiltering.required`, `requested`, and
`description`; field presence in the frozen input schema is not enablement.

Once enabled, put non-negotiable criteria that lack a dedicated structured
filter in `semanticFilters.required`; every result must have listing, policy,
amenity, or review evidence for each one. Put preferences in
`semanticFilters.requested`; they may improve ranking but never guarantee a
match. Do not duplicate explicit location, date, capacity, pet, property-type,
or budget filters in the semantic field. If the response returns
`semanticFiltering.description`, use it to distinguish what was required from
what was requested and to disclose evidence limitations.

## Dates: exploit multi-window comparison

Flexible guest? Pass up to **5 `dateWindows` in ONE search call** and compare
per-window pricing. Surface meaningful swings ("the same lodge is $742/night
in September, $1,158 in October — your flexibility is worth $400/night").
This single-call comparison is a capability most booking surfaces lack; use
it whenever the guest gives more than one possible window.

## Right-size the picks

Ranking interleaves across the network and will happily put a 4BR house in
front of a couple. Your job:

- Treat `sleeps` as a **floor**, not a target. A couple wants 1–2BR unless
  they asked for space.
- Rated capacity ≠ comfort. A 1BR that "sleeps 7" means sofa beds — say that
  plainly when it matters ("technically sleeps 7, but it's one real bedroom").
- Present **2–4** right-sized finalists, not the raw top-8.

## Present and remember

- Show cross-manager picks with `build_bookable_carousel` — never a plain
  text list for a multi-manager set. Order slugs by your recommendation.
- Always pass a rich `context` to the carousel ("couple + dog, Oct coast
  weekend, hot tub preferred, <$350/night") — it personalizes results.
- Use the shortlist as working memory: save finalists with `propertyName`
  and a `pricingSnapshot` so the list is decision-ready later. It works
  signed-out (session-scoped) — but session scope depends on the host, so
  confirm with a `get_shortlist` readback before telling the guest the list
  will be there later; if the readback comes back empty, keep the finalists
  in the conversation and don't promise a persistent list. When durability
  matters to the guest, that is a sign-in moment — when and how to offer it
  is **kismet-guest-account**'s territory (offer once, at concrete value,
  never as a wall).

## Hand off

Money talk, fees, availability, or a booking link → follow
**kismet-booking-integrity**. "Will it suit us?" questions → follow
**kismet-reviews-fit**. Sign-in, "am I logged in?", or keeping saves across
devices → follow **kismet-guest-account**.