SKILL.md

---
name: kismet-guest-account
description: Signing in, guest accounts, and what being logged in unlocks on Kismet. Use whenever the guest asks to sign in, log in, or asks "am I logged in?"; asks why they should create an account; wants their saved properties or trip on another device; worries about losing a shortlist; asks about rates for account holders; or pastes a Kismet trip or handoff link. Covers when to offer sign-in (and when to stay quiet), the OAuth ceremony, privacy-clean profile reads, session saves vs durable saves, and trip handoff links.
---

# Kismet Guest Account

Signing in is a value moment, not a gate. Everything a guest needs to browse,
search, compare, and save works anonymously — so the skill here is knowing
what an account actually unlocks, offering it at the moments that matter, and
never nagging.

## What being signed in unlocks (say it in these terms)

- **Rates**: managers can extend better direct rates to signed-in guests
  where they offer them. Frame it as "where the manager offers them" — never
  promise a discount that a specific property has not shown you.
- **Saves that follow the guest**: anonymous saves live with the current
  session and may not survive a new conversation or device. Signed-in saves
  persist on the guest's Kismet account — same shortlist on web, phone, and
  future chats.
- **Trips and stays**: upcoming and past stays, and trip context carried by
  Kismet links, attach to the account and travel with the guest.

## When to offer sign-in — and when not to

Offer once, at a moment where the value is concrete:
- The guest has built a shortlist they clearly care about and the session is
  winding down ("want these saved to your account so they're on your phone
  too?").
- The guest asks how to see their saves or trip somewhere else.
- The guest asks about account or member pricing.
- The guest asks anything about their own account state.

Stay quiet otherwise. Browsing, searching, and saving all work without an
account; interrupting an anonymous guest who is mid-search to pitch login
reads as a wall, not a feature. One declined offer means the subject is
closed until the guest raises it.

## The ceremony

`sign_in` is the only way in. It triggers the host's own sign-in flow —
never ask for an email or password in the conversation, never compose a
login link by hand. After the ceremony completes, confirm with
`get_guest_profile` and greet the guest by first name.

"Am I logged in?" is always answered from `get_guest_profile`, never from
memory: the tool returns an explicit anonymous state when nobody is signed
in, and the honest answer builds trust either way.

## Privacy-clean by construction

Profile reads return *flags*, not raw contact details — "email verified",
"phone on file" — plus first name, memberships, saved properties, and stays.
Mirror that discipline in conversation: confirm THAT an email is on file and
verified; never guess, reconstruct, or echo the address itself.

## Saves: session vs durable

Anonymous saves are real but session-scoped, and how long a session lasts is
host-dependent. After saving anonymously, read the shortlist back before
promising it will be there later. If the guest wants the list to outlive the
conversation, that is the natural sign-in moment. After the ceremony
completes, re-save anything that must persist and read it back once —
confirming beats assuming, and it costs one call.

## Trip handoff links

When a guest pastes a Kismet link that carries trip context, load it with
`use_guest_token`: it restores the manager and any draft trip the link
carries. Treat the token as one-time context — use it, summarize what
loaded, and never display the token or the raw link contents back.