---
name: handout-access-handover
description: Interpret an Owner or Property Manager's request to share a property, remove access, sell a house or change management. Choose the matching Handout invitation or handover workflow, inspect dependencies and preview access/history effects. Not Tenant or SP self-service.
metadata:
  version: 1.1.3
---

# Handout Access and Handover

## Check for Skill Updates

At each activation, read `https://handout.us/oauth/agent-setup` and compare this package's `metadata.version` with `skill_release.versions` for its name. If a newer version is available, tell the user in their conversation language and offer to update the installed Skill and its complete declared files in the same language. Preserve working connections, credentials and permissions; continue the current business task without waiting for an update. Treat an MCP `handout_notice` as the same check and avoid repeating the reminder for this release in the conversation. Report installation only after the host confirms it. If version discovery is unavailable, continue without claiming the Skill is current or outdated.

Language: English. [中文说明](https://handout.us/skills/handout-access-handover/zh-CN/SKILL.md). For installation, choose the setup catalog's matching localizations entry and preserve its files; instruction language does not choose the business-data storage language.

Audience: Owner and Property Manager (PO/PM) workflows only. Tenant and SP Skills are not available. Confirm the caller's intended PO/PM workflow; managed Tenant profiles do not create Tenant logins or grant access.

Use MCP under the user's own account. For installation follow [Handout Connection Guide](https://handout.us/skills/handout-connect/SKILL.md); credentials remain in secure client settings. Read live `me.get` and `app_schema.get` for `property_access` or `handover`, including action-specific data schemas.

A query-only connection permits reads, not staging changes. If the user requests a write, ask for the required write authorization without silently upgrading access or deleting a working connection.

## Understand the Request First

- "Let Alice see this house" describes sharing, not transferring ownership. Propose viewer only if the user means read-only; clarify operational access when unclear.
- "I manage this for its Owner" does not prove the current caller owns it. Inspect memberships and prepare an invitation for the actual recipient/role; a typed Owner name alone grants nothing.
- "Remove Alice" means revoke a pending invitation or remove an accepted membership depending on current state. Read first; explain any independent history/finance grants that remain.
- "I sold it" or "a new manager is taking over" starts a relationship handover, not a delete or a standard invite. Ask ownership versus management, recipient and desired history only where missing.
- Extract names/emails from the user's own facts, resolve real records, and ask only for blocking information. Do not ask the user for user IDs, checklist keys or a completed access form.

Explain proposed access and data effects in the user's language. Use the [event-to-record guide](https://handout.us/skills/tobby-landlord/references/event-to-record.md) for mixed record/financial requests. A story or incoming invitation is not consent to accept/grant broader permissions.

## Consent and Dependencies

Resolve the actual property, member/invitation or handover. Show human-readable names, recipient, exact role or selected history, and what access changes. Correct missing inputs before staging. Use `prepare_*`, obtain explicit approval of its returned preview, then matching `confirm_*` with only `action,preview_id,user_confirmed:true`. Role, recipient, history selection or revision changes require a new preview.

Sharing access and handing over an ownership/management period are different workflows. Creating a property, naming an Owner or entering an email does not prove title or grant another account access.

## Property Access

1. Owner/manager calls `property_access.list(property_id)` to inspect existing members and pending invitations.
2. `prepare_invite` takes `property_id,data:{invited_email,access_role}`. Roles are `owner / manager / viewer`; viewer is read-only. Only a matching authenticated recipient's acceptance grants access.
3. The recipient inspects `invitation(invite_id)` or the actual received invitation token, then prepares acceptance. Identity comes from their login, not a supplied user ID. Resolved previews retain an invite ID rather than the token. A new user need not already have a property.
4. `prepare_revoke(property_id,invite_id)` cancels a pending invitation. `prepare_remove(property_id,user_id,data:{access_role,next_primary_owner_user_id?})` removes accepted membership. These are not interchangeable.
5. The App protects the last Owner, primary Owner and property role conflicts. A replacement primary Owner must be an existing Owner. Independent history or finance grants are not silently revoked by membership removal.

Report invitation creation, `email_queued`/`email_status`, `email_sent`, and acceptance separately. `email_queued=true` means the backend accepted a delivery request; it does not mean sent or delivered. Do not recreate an invitation just because `email_sent=false`. If delivery failed, preserve the real invitation result and use its returned recovery instructions; do not create repeated invitations or declare access granted. Never put OAuth credentials, API keys or invitation secrets into logs.

## Handover

Query `handover.options/list`, then prepare `create` with `data:{property_id,kind,subject_user_id?}`. Kind is `owner` or `manager`. App currently requires a single confirmed Owner for ownership transfer. A PM can end only their own management relationship; appointing a successor requires Owner authorization.

- Continue a returned existing handover. `get(handover_id)` returns its checklist/revision and authorized private archive.
- Prepare `refresh` to update dependencies. Resolve actual items with `data:{key,resolution}` using `reviewed / stop / retain / external_cancelled`. Choose a supported resolution based on evidence. Stopping a reminder affects the live record; reviewing finances is not a transfer or automatic reconciliation.
- Query `history_options(handover_id,query?,type?)`; types are `maintenance / assets / documents`. Prepare `invite` with exact `data:{email,record_keys,allow_reshare?}`. Show each selected history record, recipient and resharing choice. Confirmation replaces pending invitations for this handover.
- Recipient prepares `accept(grant_id)` using the real invitation. Their matching verified email is required. Owner acceptance can create a successor property period that remains awaiting completion of the outgoing period.
- Prepare `end(handover_id)` only when checklist/dependencies allow it. Show relationship/archive effects before approval. Ending can remove management access or archive an ownership period, while retaining the permitted private archive.
- Prepare `revoke(handover_id)` follows App grant rules. Accepted history uses `received(grant_id)`; `file(grant_id,record_key)` provides short-lived access only to authorized files.

Property maintenance history can be shared as selected reference data. Financial records are not inherited; PM private archives are not the shared history package. A conflict requires rereading and preparing again, not replacing a revision to force the old approval.

Use the user's language for explanations; preserve personal names, addresses and exact record facts. Ask about storage language only when introducing new descriptive text. Never substitute an agent signature or bypass a user's identity verification.

## Tenant registration invitations (App flow)

When a PO/PM wants a tenant to register, direct them to Leases → open the lease → Tenants → Tenant invitation code; select a saved email and use Send invitation email in that panel, or send from that lease's tenant list. One code belongs to the lease and is shared by its tenants. Links use `https://handout.us/public/tenant-signup?code=...`. Each tenant links their own verified, listed email. Do not substitute property_access invitations or a Lease ID for the code. Registration without a code creates no lease access; the tenant can enter a code in “Link your lease” on their Dashboard later. Resends reuse the code. Codes expire after seven days; the PO/PM can reset or revoke them in the same entry. Reset/revoke invalidates the old link and code but retains already-linked accounts. Public MCP does not expose tenant invitation sending or Tenant self-service: do not claim to have sent or accepted these through an Agent.