Air France - KLM

Track Air France flights using the Air France–KLM Open Data APIs (Flight Status). Use when the user gives a flight number/date (e.g., AF007 on 2026-01-29) and wants monitoring, alerts (delay/gate/aircraft changes), or analysis (previous-flight chain, aircraft tail number → cabin recency / Wi‑Fi). Also use when setting up or tuning polling schedules within API rate limits.

Security Scan

The skill's behavior matches its stated purpose (tracking AF/KLM flights) but the registry metadata omits the API credentials the code actually requires and there are a few minor scope/credential handling details you should review before installing.

Purpose & Capability

The code and SKILL.md implement exactly what the description promises: calling the Air France–KLM Open Data Flight Status API, polling/watch logic, previous-flight chain handling, and optional aircraft enrichment via a public Planespotters endpoint. However, the registry metadata declares no required credentials while the runtime explicitly requires an AFKL API key (AFKL_API_KEY) and optional secret — this mismatch is unexpected and should be corrected or justified.

Instruction Scope

Runtime instructions are focused and specific: obtain an AFKL API key, provide it via env vars or files in a state dir, call api.airfranceklm.com, respect rate limits, write small caches under a state directory, and optionally enrich tail numbers via Planespotters. The scripts do not attempt to read arbitrary system files or other credentials beyond the declared state dir/env vars. The only minor scope note: the skill suggests storing credentials in plaintext files under the state dir (it recommends chmod 600), which is functional but has security implications.

Install Mechanism

There is no installer and no external downloads; this is instruction + included Node.js scripts. No third-party packages are fetched at install time. No remote install URLs or archive extraction are used.

Credentials

The skill requires an AFKL API key (AFKL_API_KEY) and optional AFKL_API_SECRET at runtime, but the registry metadata lists no required environment variables/primary credential — this is an inconsistency. The scripts also read CLAWDBOT_STATE_DIR or AFKL_STATE_DIR (or fall back to ./state) and may create cache/state files there; that file I/O is expected but the state-path fallback includes a hard-coded host path (/home/cwehrung/clawd/state) which is environment-specific and should not be assumed on other hosts. Overall, the requested secrets are proportional to the purpose, but the metadata omission and plaintext-file guidance merit attention.

Persistence & Privilege

The skill does not request persistent platform privileges (always:false). It writes caches and state files only under its state directory (user-configurable), which is normal for a watcher. It does not modify other skills or system-wide configs. Autonomous invocation is allowed by default (normal for skills) and not in itself flagged.

What to consider before installing

This skill appears to do what it says (poll AF/KLM Open Data and enrich tail numbers). Before installing: 1) Expect to supply a valid AFKL API key/secret — the skill needs AFKL_API_KEY (and optionally AFKL_API_SECRET) but the registry metadata does not declare this; confirm you’re comfortable providing that key. 2) Prefer environment variables over plaintext files; if you store credentials in files in the state dir, ensure correct permissions (chmod 600) and that the state dir is not shared or world-readable. 3) Review/override the state dir (set CLAWDBOT_STATE_DIR or AFKL_STATE_DIR) to avoid accidental use of host-specific paths (the code falls back to /home/cwehrung/clawd/state if it exists). 4) The scripts call only api.airfranceklm.com and a public Planespotters endpoint — if you require stricter network controls, run them in a constrained environment. 5) Ask the publisher to correct registry metadata to list AFKL_API_KEY / AFKL_API_SECRET as required credentials so the permissions are transparent. If you want a higher assurance level, request a signed publisher identity or run the code in an isolated environment first.

Air France (AFKL Open Data) flight tracker

Quick start (one-off status)

1. Create an API key (and optional secret)

• Register on: https://developer.airfranceklm.com
• Subscribe to the Open Data product(s) you need (at least Flight Status API)
• Generate credentials (API key; some accounts also provide an API secret)

2. Provide API credentials (do not print them):

• Preferred: env vars AFKL_API_KEY (and optional AFKL_API_SECRET)
• Or files in your state dir (CLAWDBOT_STATE_DIR or ./state):
  • afkl_api_key.txt (chmod 600)
  • afkl_api_secret.txt (chmod 600, optional)

2. Query flight status:

• Run: node skills/airfrance-afkl/scripts/afkl_flightstatus_query.mjs --carrier AF --flight 7 --origin JFK --dep-date 2026-01-29

Notes:

• Send Accept: */* (API returns application/hal+json).
• Keep within limits: <= 1 request/sec. When making multiple calls, sleep ~1100ms between them.

Start monitoring (watcher)

Use when the user wants proactive updates.

• Run: node skills/airfrance-afkl/scripts/afkl_watch_flight.mjs --carrier AF --flight 7 --origin JFK --dep-date 2026-01-29

What it does:

• Fetches the operational flight(s) for the date window.
• Emits a single message only when something meaningful changes.
• Also follows the previous-flight chain (flightRelations.previousFlightData.id) up to a configurable depth and alerts if a previous segment is delayed/cancelled.

Polling strategy (default):

• 36h before departure: at most every 60 min

• 36h→12h: every 30 min
• 12h→3h: every 15 min
• 3h→departure: every 5–10 min (stay under daily quota)
• After departure: every 30 min until arrival

Implementation detail: run cron every 5–15 min, but the script self-throttles using a state file so it won’t hit the API when it’s not time. The watcher prints no output when nothing changed (so cron jobs can send only when stdout is non-empty).

Input shorthand

Preferred user-facing format:

• AF7 demain / AF7 jeudi

Interpretation rule:

• The day always refers to the departure date (not arrival).

Implementation notes:

• Convert relative day words to a departure date in the user’s timezone unless the origin timezone is explicitly known.
• When ambiguous (long-haul crossing midnight), prefer the departure local date at the origin if origin is known.

(For scripts, still pass --origin + --dep-date YYYY-MM-DD.)

Interpret “interesting” fields

See references/fields.md for:

• flightRelations (prev/next)
• places.* (terminal/gate/check-in zone)
• times.* (scheduled/estimated/latest/actual)
• aircraft (type, registration)
• “parking position” / stand-type hints (when present)
• Wi‑Fi hints and how to reason about cabin recency

Cabin recency / upgrade heuristics

When aircraft registration is available:

• Use tail number to infer sub-fleet and likely cabin generation.
• If data suggests older config (or no Wi‑Fi), upgrading can be more/less worth it.

Be conservative:

• Open Data often doesn’t expose exact seat model; treat this as best-effort.