Update to PositionGuard

{
  "description": "Answer questions about PositionGuard groups, named areas, member presence, and area counts while respecting independent member consent and presence freshness.",
  "included_files": [],
  "name": "presence",
  "skill_md_contents": "---\nname: presence\ndescription: Answer questions about PositionGuard groups, named areas, member presence, and area counts while respecting independent member consent and presence freshness.\n---\n\n# PositionGuard presence\n\nUse the connected PositionGuard MCP tools for area-level presence questions.\nThe production server enforces privacy before returning information. This skill\ndoes not grant access or replace those controls.\n\n## Connection\n\nUse the host's supported remote MCP OAuth connection to\nhttps://mcp.positionguardai.com/mcp. The user approves the assistant through the\nPositionGuard mobile app using the provider's displayed QR code or code.\nPreserve the existing PositionGuard and Firebase identity flow. Do not request\nAPI keys, extract tokens, invent OAuth scopes or endpoints, create accounts on\nthe user's behalf, or introduce alternate authentication. If access fails or is\nrevoked, report the failure and direct the user to the supported connection flow.\nNever interpret an authentication failure as empty groups or absent members.\n\n## Tools\n\n- list_groups: discover available groups and IDs.\n- list_areas: discover named areas and IDs, optionally within a group.\n- where_is_member: look up an established member nickname, optionally in a group.\n- who_is_at_area: obtain consenting members' confirmed and last-known presence.\n- count_members_at_area: obtain the server-provided count without identities.\n\nPrefer returned IDs to ambiguous names. Clarify group or area ambiguity when\nneeded. For \"Where am I?\", use an already established PositionGuard nickname;\notherwise ask for it. No self-identity tool is established by this package.\n\n## Interpret results\n\n- Each member independently authorizes AI sharing. The requesting user's consent\n  does not authorize access to other members. Respect group and area visibility.\n- unknown means unknown, never absent or away. Do not guess hidden presence.\n- A missing area in inside_areas is not evidence that the member is outside it.\n- Keep confirmed and last_known lists separate. Report last-known information\n  with last_confirmed_seconds_ago as an age, never as current presence.\n- since indicates entry time, not freshness. Do not invent duration when absent.\n- Relay count_note, undisclosed_note, and freshness notes. Do not present partial\n  names as everyone, infer undisclosed identities, or reconstruct hidden presence.\n- When stale_count or undisclosed_count is nonzero, report member_count as\n  \"at least N\" with the server's qualifications and how many counted members\n  are not recently confirmed. Do not label stale members as currently there.\n- count_unavailable is unknown, never zero. no_such_area or no_such_member does\n  not establish anyone's absence.\n- not_at_area supports only the scope explicitly stated by the server; do not\n  extrapolate it to hidden areas or an exact location.\n\nDo not provide coordinates, routes, location history, continuous monitoring,\nor privacy bypasses. These tools cannot change settings or send messages.\nSharing and individual assistant revocation are managed in PositionGuard.\n"
}