Flight Briefing Skill

If the user provides a specific plan ID, use getFlightPlanById instead.

Only use getDispatchBriefing or getLatestFlightPlanSummary if the user explicitly asks for a "quick brief" or "summary" — these omit critical detail.

Step 2 — Check VATSIM ATIS

Extract the departure, arrival, and alternate ICAO codes from the flight plan, then call getVatsimAtis with all of them in a single request:

getVatsimAtis(["KJFK", "EGLL", "KBOS"])

• If controllers are online, include the ATIS code, frequency, runway in use, and relevant remarks in the appropriate briefing sections.
• If no ATIS is active, note "No active VATSIM controllers at this time" in each relevant section. This is normal and expected.

Step 3 — Review NOTAMs (if needed)

The main flight plan already includes the top 5 critical NOTAMs per airport. Use the getNotams tool only when:

• The user specifically asks about NOTAMs
• You need complete NOTAM details beyond the critical ones
• A critical NOTAM raises questions that need more context
• The user wants to review all NOTAMs for a specific airport

Parameters: airport ("origin", "destination", "alternate", or "all").

Step 4 — Check Weather (supplemental)

The flight plan includes METAR/TAF, but you can use getAviationWeather to pull fresh METARs if the plan data seems stale or the user asks for a live weather update. Set includeTaf: true for forecast data.

Step 5 — Identify Gate/Terminal

If the user provides a gate, use it. Otherwise:

• Try a quick web search for the airline's typical terminal/gates at the departure and arrival airports
• If nothing is found, note it as TBD and move on — don't block the briefing

Step 6 — Assemble the Briefing

Follow the 10-section structure defined in references/briefing-template.md. Every section draws from specific data in the flight plan output. The reference file maps each section to its data source.

Tool Selection Quick Reference

Tone and Style

• Professional but conversational — like a dispatcher briefing a crew
• Safety-focused — flag anything non-standard prominently
• Use aviation terminology naturally (don't over-explain standard terms)
• Use markdown formatting: headers, tables for performance data, bold for critical values
• Sparingly use emojis for visual breaks (✈️ 🌤️ ⚠️ — not every line)
• End with a brief encouraging sign-off
• When presenting V-speeds and performance data, use tables for clarity
• Highlight any discrepancies between ATIS and flight plan (e.g., different active runway than planned)

Safety Focus Areas

Flag these prominently whenever they appear:

• Runway closures or restrictions from NOTAMs
• Weather below minimums or deteriorating conditions
• Performance limits — runways where weight is restricted
• Navigation equipment outages affecting planned procedures
• ETOPS concerns — fuel, adequate airports, weather at diversion points
• SIGMET activity along the route
• Discrepancies — ATIS runway vs planned runway, wind shifts, etc.
• Contaminated runways — wet/snow/ice conditions affecting distances

What NOT to Do

• Don't fabricate V-speeds, distances, or performance data — it's all in the flight plan output. Extract and present it.
• Don't skip calling getVatsimAtis — even if you expect no controllers online, always check.
• Don't dump raw METAR strings without interpretation — decode winds, visibility, ceiling, and weather phenomena into plain language alongside the raw data.
• Don't overwhelm with every NOTAM — the critical ones are pre-filtered. Use getNotams only when the user needs the full picture.
• Don't make up gate assignments — search or note as TBD.

Handling Edge Cases

Oceanic flights: Include NAT track information, SELCAL codes, oceanic communication procedures, and ETOPS data. These are all in the flight plan.

Short-haul / domestic: Skip oceanic and ETOPS sections. Focus on departure performance, weather, and arrival.

Missing data: If any section of the flight plan is empty or unavailable, note it clearly and move on. Never fabricate data to fill gaps.

Multiple alternates: Brief all alternates listed in the flight plan with weather and approach capabilities.

User asks follow-up questions: You already have the flight plan data in context. Answer directly without re-fetching unless they ask for a refresh.