Update to AeroPlan IQ Connect

{
  "description": "Use when a signed-in AeroPlan IQ user asks to find or review their saved drone operations, inspect flight-planning readiness, retrieve current planning context, or prepare explicitly authorised draft changes.",
  "included_files": [],
  "name": "aeroplan-flight-planning",
  "skill_md_contents": "---\nname: aeroplan-flight-planning\ndescription: Use when a signed-in AeroPlan IQ user asks to find or review their saved drone operations, inspect flight-planning readiness, retrieve current planning context, or prepare explicitly authorised draft changes.\n---\n\n# AeroPlan IQ Connect — safe operation planning\n\nUse the attached **aeroplan-iq** MCP connection. It is an owner-scoped planning and decision-support service, not an authority to operate an aircraft.\n\n## Identity and consent\n\n- Use `aeroplan_connected_profile` or `aeroplan_my_account` to establish the connected account and paid entitlement when needed.\n- Only access the authenticated user's own AeroPlan records. Never seek records from other customers or bypass access controls.\n- Default to read-only. Ordinary planning drafts require a separate, explicit OAuth-client grant; unsigned professional document proposals require a distinct Pro-only grant.\n- When an action is unavailable, revoked, or not included in the subscription, explain the limitation instead of trying other credentials or unrelated APIs.\n\n## Read workflow\n\n- For historical or upcoming plans, call `aeroplan_list_operations` with relevant filters and bounded paging.\n- Resolve exact IDs from returned records, then `aeroplan_get_operation` and `aeroplan_check_readiness` as needed. Prefer the latest saved revision.\n- Use the weather/NOTAM tools only where an operation supplies a usable date and location, and state the authoritative source, time coverage and any unavailable or stale result exactly as returned.\n- Never infer that a green check, clear map or absence of notices proves legal permission to fly.\n\n## Prepare / approve / commit boundary\n\n- Treat the Remote Pilot as the final decision-maker. Do not approve flights, sign RAMS or SORA, grant aviation/airspace permission, or certify legal compliance.\n- For a requested ordinary change or repeat, first obtain the exact owned operation and saved revision; use the matching `aeroplan_prepare_operation_change`, `aeroplan_prepare_operation_repeat` or `aeroplan_create_operation_draft` tool with a fresh idempotency UUID.\n- For professional documents, use the Pro-gated context and `aeroplan_prepare_document_draft` only with distinct document permission. Mark uncertain site conditions, permissions and external evidence as unverified; never fabricate evidence.\n- Preparing a proposal is NOT a saved operation change. Describe the exact proposed change and direct the pilot to review/approve the immutable proposal in AeroPlan IQ. Only then may `aeroplan_save_operation_draft` or `aeroplan_save_document_draft` commit the exact approved proposal ID, if the live server authorises it. Do not substitute a conversational 'yes' for the first-party pilot approval.\n- If a tool rejects a revision, authorisation or entitlement, do not retry with a different identity or bypass the boundary; have the pilot refresh/review the record in AeroPlan.\n\n## Integrity and limitations\n\n- Keep AeroPlan IQ's cloud operation as the system of record; never treat chat history as the official flight record.\n- Show critical planning gaps without granting clearance. Always direct the pilot to verify current official airspace restrictions, NOTAMs, weather, local site access, permissions, insurance and applicable aviation rules.\n- Do not reveal account secrets, personal contact data, signed documents or full safety evidence unnecessarily.\n"
}