Printing Press CLI for Flight Goat. Search real Google Flights fares, cheapest dates, Kayak routes, and FlySoar price checks with no API key — plus optional FlightAware AeroAPI flight status, delay, and alert data.

<! GENERATED FILE — DO NOT EDIT. This file is a verbatim mirror of library/travel/flight goat/SKILL.md, regenerated post merge by tools/generate skills/. Hand edits here are silently overwritten on the next regen. Edit the library/ source instead. See the repository agent guide, section "Generated artifacts: registry.json, cli skills/". Flight Goat — Printing Press CLI Prerequisites: Install the CLI This skill drives the flight goat pp cli binary. You must verify the CLI is installed before invoking any command from this skill. If it is missing, install it first: 1. Install via the Printing Press installer. It defaults binaries to $HOME/.local/bin on macOS/Linux and %LOCALAPPDATA%\Programs\PrintingPress\bin on Windows: 2. Verify: flight goat pp cli version 3. Ensure the reported install directory is on $PATH for the agent/runtime that will invoke this skill. If the npx install fails (no Node, offline, etc.), fall back to a direct Go install (requires Go 1.26.9 or newer). This installs into $GOPATH/bin (default $HOME/go/bin ), so add that directory to $PATH instead: If version reports "command not found" after install, the runtime cannot see the binary directory on $PATH . Do not proceed with skill commands until verification succeeds. Unique Capabilities: fare search without an API key The headline commands hit consumer fare sources directly and need no credentials — do not present the CLI as AeroAPI gated. FlightAware AeroAPI (documented below) is secondary and optional. flight goat pp cli flights <origin <destination <date — Google Flights fare search: real prices, legs, airlines. Round trip with return , multi city with repeated segment , batch probes with repeated trip . flight goat pp cli dates <origin <destination — cheapest date scan across a travel window. flight goat pp cli explore <airport / flight goat pp cli longhaul <airport — Kayak nonstop and long haul route discovery. flight goat pp cli soar <origin <destination <date — FlySoar (Duffel NDC/GDS) second price opinion with booking handoff. flight goat pp cli award <origin <destination — Seats.aero award (mileage) availability: miles + taxes redemption options across cabins. Comma separated airport and cabin lists are accepted. Requires SEATS AERO API KEY (an eligible Seats.aero Partner API key); commercial API use needs written permission from Seats.aero. Read only. flight goat pp cli wifi flight <flightNumber / wifi airline <IATA / wifi airlines / wifi rollouts [IATA] / wifi speed <flight / wifi airline speed <IATA / wifi search <query — SeatWifi in flight WiFi predictions, Starlink rollout status, and crowdsourced speed reports. No API key. Public JSON at https://seatwifi.com. Read only. flight goat pp cli assess — delayed flight/rebooking decision support. Booking deeplinks in each result's booking urls quote the same currency the search ran in. award is the exception: it quotes mileage/points, not cash, and does not produce booking deeplinks. Bulk fare probes: use trip with pace, never a shell loop Google rate limits fare traffic per IP. Parallel shell loops over flights invocations trigger HTTP 429 blocks that can outlast 15 minutes. Run bulk probes in one paced invocation instead: trip takes ORIG DEST@DEPART or ORIG DEST@DEPART@RETURN (same grammar family as segment ) and replaces the positional args; all filter flags ( currency , stops , class , airlines , time , return time , passengers ) apply to every trip. Per trip rows land in the envelope's results[] with status ok / error / skipped . Round trips can constrain each leg's departure window independently: time sets the outbound window, return time sets the return leg's window (falls back to time when unset). Both take the same H H 24h form, e.g. flight goat pp cli flights SEA HNL 2026 08 01 return 2026 08 10 time 6 12 return time 17 23 for a morning outbound and evening return. Round trip: return alone does not return return leg options return alone shows outbound itineraries only . Each one's price already bundles Google's own auto picked "cheapest return" total, but no return leg flight (times, airline, duration) is ever shown — do not read the outbound list as containing both directions, and do not assume the price is for the outbound leg alone. To see and choose real return leg options, run the true two step flow Google's own UI uses. Step 1, flight goat pp cli flights LHR BCN 2027 03 01 return 2027 03 18 agent , returns outbound options with flights[0].direction == "outbound" — note the 1 based position of the one you want. Step 2, flight goat pp cli flights LHR BCN 2027 03 01 return 2027 03 18 select outbound 1 agent , returns real return options priced against that specific outbound: flights[] now has direction == "return" with independent prices, and the envelope's selected outbound echoes which outbound they're paired with. select outbound N is 1 based, counted in the order step 1 returned them. It requires return (round trip only) and does not combine with trip or segment ( =2). Each Flight also carries selection token on round trip outbound rows — the same value the CLI itself uses internally to build the step 2 request — for callers building their own selection flow instead of a fixed index. Rate limit semantics: Transient 429s are retried automatically (2s/5s/12s backoff) before a command fails. On a persistent 429 a batch stops early — continuing would deepen the IP block — the partial envelope is still emitted, and the exit code is 7 (rate limited). While Google is blocked, soar and explore / longhaul use different backends and keep working; doctor documents the same contract under google flights . Round trip cheapest dates: dates round duration dates scans one way prices by default. Add round duration N to scan round trip totals instead — each row is the cheapest combined round trip price for departing that day and returning N nights later, not a separate outbound/return price pair: flight goat pp cli dates SEA HNL round duration 7 sort agent . duration is required with round and must be greater than zero. Each result row carries return date ( departure date + duration ) alongside price , which is already the round trip total. Introduction AeroAPI is a simple, query based API that gives software developers access to a variety of FlightAware's flight data. Users can obtain current or historical data. AeroAPI is a RESTful API delivering accurate and actionable aviation data. With the introduction of Foresight™, customers have access to the data that powers over half of the predictive airline ETAs in the US. Categories AeroAPI is divided into several categories to make things easier to discover. Flights: Summary information, planned routes, positions and more Foresight: Flight positions enhanced with FlightAware Foresight™ Airports: Airport information and FIDS style resources Operators: Operator information and fleet activity resources Alerts: Configure flight alerts and delivery destinations History: Historical flight access for various endpoints Miscellaneous: Flight disruption, future schedule information, and aircraft owner information Development Tools AeroAPI is defined using the OpenAPI Spec 3.0, which means it can be easily imported into tools like Postman. To get started try importing the API specification using [Postman's instructions](https://learning.postman.com/docs/integrations/available integrations/working with openAPI/). Once imported as a collection only the "Value" field under the collection's Authorization tab needs to be populated and saved before making calls. The AeroAPI OpenAPI specification is located at:\ https://flightaware.com/commercial/aeroapi/resources/aeroapi openapi.yml Our [open source AeroApps project](/aeroapi/portal/resources) provides a small collection of services and sample applications to help you get started. The Flight Information Display System (FIDS) AeroApp is an example of a multi tier application using multiple languages and Docker containers. It demonstrates connectivity, data caching, flight presentation, and leveraging flight maps. The Alerts AeroApp demonstrates the use of AeroAPI to set, edit, and receive alerts in a sample application with a Dockerized Python backend and a React frontend. Our AeroAPI push notification [testing interface](/commercial/aeroapi/send.rvt) provides a quick and easy way to test the delivery of customized alerts via AeroAPI push. Command Reference aircraft — Manage aircraft flight goat pp cli aircraft <type — Returns information about an aircraft type, given an ICAO aircraft type designator string. airports — Manage airports flight goat pp cli airports get — Returns information about an airport given an ICAO or LID airport code such as KLAX, KIAH, O07, etc. flight goat pp cli airports get all — Returns the ICAO identifiers of all known airports. flight goat pp cli airports get delays for all — Returns a list of airports with delays. flight goat pp cli airports get nearby — Returns a list of airports located within a given distance from the given location. alerts — AeroAPI alerting can be used to configure and receive real time alerts on key flight events. With customizable alerting offered by our alert endpoints, AeroAPI empowers users to selectively pick various types of events/filters to alert on. By doing so, you can receive specially tailored alerts delivered to you for events such as flight plan filed, flight departure (out and off), flight arrival (on and in), and more! To get started with alerting, the PUT /alerts/endpoint endpoint must first be used to set up the account wide default URL that alerts will be delivered to. This step must be done before any alerts can be configured and will serve as the fallback URL that all alerts will be sent to for the account if a specific delivery URL is not designated on a particular alert. If this is not performed before configuring alerts, then you will receive a 400 error with an error message reminding you of this step when trying to interact with the POST /alerts endpoint. Once a URL is set via the PUT /alerts/endpoint endpoint, then alerts can be configured using the POST /alerts endpoint. The GET /alerts endpoint can also be used to retrieve all currently configured alerts associated with your AeroAPI key. The GET /alerts endpoint will allow you to easily retrieve the id of any specific alerts of interest configured for the account which can let you use the GET PUT and DELETE /alerts/{id} endpoints to retrieve, update, and delete specific alerts. When configuring an individual alert, the target url field can be set to a URL that’s different than the account wide target endpoint set via the PUT /alerts/endpoint . If the target url field is set on an alert, then that specific alert will be delivered to the specified target url rather than the default account wide one. If this field is not configured for the alert, then the alert will be delivered to the default account wide endpoint. By setting this field, one can easily target different alerts to be received by different endpoints which can be useful for configuring per application alerts or sending alerts to an alternate development environment without having to adjust a production alert configuration. For each alert configured, one to many ‘events’ can be set for alert delivery. While most events will result in one alert delivery, both the arrival and the departure events can result in multiple alerts delivered (referred to as bundled). The departure event bundles the departure (actual OFF the ground) alert, along with the flight plan filed alert and up to 5 per departure changes which can include a

pp-flight-goat