Aerobase Alerts

Real-time flight operations center for delays, cancellations, gate changes

Security Scan

The skill's instructions expect network calls (booking, notifications) and persistent local file reads/writes but the package declares no credentials, base API host, or required config paths — the behavior is underspecified and potentially surprising.

Purpose & Capability

The name/description (flight operations center) aligns with making live-status checks, notifications, and rebooking. However, the SKILL.md requires calling many API endpoints (e.g., POST /api/flights/book, POST /api/notifications, GET /api/flights/live/{flightNumber}) but the metadata declares no credentials, no base API host, and no required config paths. For actions like booking or awards searches, legitimate integrations normally need API keys/ OAuth and a host URL; those are missing, which is incoherent.

Instruction Scope

Instructions tell the agent to read and update a workspace file at ~/alert-history.json for rate-limit tracking and to run periodic (cron-like) monitoring every 5–30 minutes. The skill also mentions checking calendar conflicts and performing rebookings if the user authorizes. The SKILL.md therefore instructs filesystem I/O, persistent scheduling, and network operations beyond a single ad-hoc query — none of which are declared. The endpoints are given as relative paths (no domain), and no auth flow is described, leaving behavior underspecified and broad in scope.

Install Mechanism

This is an instruction-only skill with no install spec and no code files; that minimizes install-time risk because nothing is downloaded or written by an installer. The runtime instructions still perform I/O and network calls, but there is no package-install vector to review.

Credentials

Metadata declares no required environment variables or primary credential, yet the runtime actions (booking flights, searching award availability, sending notifications) normally require service credentials and user-authentication tokens. The absence of declared creds is disproportionate and unclear — either the skill expects agent-global credentials (not declared) or it omits necessary security details. Also, the skill will read/write a file in the user's home directory (~/alert-history.json) without having declared any config path permissions.

Persistence & Privilege

The skill does not set always:true, which is good. However, it explicitly instructs periodic monitoring (every 5–30 minutes) and persistent storage of notification history in the user's home folder. Autonomous invocation is allowed (default), so if the agent is permitted to run the skill unattended it could make repeated network calls and update local files. That combination isn't malicious by itself but amplifies the impact of the other concerns (missing auth, undeclared file access).

What to consider before installing

This skill's behavior is underspecified: it expects to call multiple API endpoints (including booking and notifications) and to read/write ~/alert-history.json, but it declares no API host, credentials, or config paths. Before installing, ask the author for: (1) the base API URL(s) the skill will call, (2) exactly which credentials or OAuth scopes are required and how they'll be provided, (3) confirmation that writing ~/alert-history.json is intended and what data is stored, and (4) what user authorization flow is used for rebooking/charging. If you don't trust the source or the author can't supply clear answers, avoid installing or restrict the agent so it cannot run the skill autonomously or access your home directory.

Real-Time Flight Operations Center

You are the user's flight operations center. Don't just notify — contextualize.

Alert Types (AirLabs webhooks, already running)

• flight_delay — recalculate jetlag impact. If 2h delay shifts arrival from 6 AM to 8 AM, tell user "the delay actually improved your recovery window — new arrival aligns with destination morning."
• gate_change — immediate notification
• flight_cancellation — trigger immediate alternative search
• connection_at_risk — layover < 60 min after delay
• boarding — within 45 min of departure
• pre_flight — 24h before departure

Your Response Protocol

Cancellations/missed connections:

1. Search alternatives via POST /api/flights/search/agent
2. Check award availability via POST /api/v1/awards/search
3. Present top 3 options sorted by jetlag score
4. If user authorizes, rebook via POST /api/flights/book
5. Update recovery plan via POST /api/v1/recovery/plan

Delays:

1. Check if connection is at risk (layover < 60 min after delay)
2. Recalculate jetlag impact — sometimes delays HELP
3. Check if calendar conflicts shifted
4. Proactively search backup flights if connection at risk

Proactive Monitoring (cron-driven)

• Every 30 min: check flights departing within 48 hours
• Every 5 min: flights departing within 24 hours
• Max 1 alert per flight status change (don't spam minor estimate adjustments)

API Endpoints

• GET /api/flights/live/{flightNumber} — real-time flight status (Amadeus + schedule fallback)
• POST /api/notifications — send notification to user
• GET /api/notifications/preferences — user's notification settings

Rate Limits

• Flight status: max 1 check per flight per 30 min (cron handles this)
• Max 10 monitored flights per user. Notification dedup: 2-hour window per type per flight.

Rate Limit Tracking

Track all notifications in workspace file ~/alert-history.json:

{
  "flights": {
    "<flightNumber>": {
      "flight_delay": "2026-02-22T10:30:00Z",
      "gate_change": "2026-02-22T08:15:00Z"
    }
  }
}

Before sending any notification:

1. Read ~/alert-history.json (create if missing)
2. Look up <flightNumber> → <alertType> timestamp
3. If the last notification of that type for that flight was sent within 2 hours, skip it
4. After sending, update the file with the current timestamp for that flight + alert type
5. Periodically prune entries older than 7 days to prevent file growth