tfl-journey-disruption

---
name: tfl-journey-disruption
description: Plan TfL journeys from start/end/time, resolve locations (prefer postcodes), and warn about disruptions; suggest alternatives when disrupted.
---

# TfL Journey Planner + Disruption Checks

Use this skill when the user wants a TfL journey plan and needs disruption awareness.

Reference: https://tfl.gov.uk/info-for/open-data-users/api-documentation

## Script helper

Use `scripts/tfl_journey_disruptions.py` for a quick journey + disruption check.

Examples:

```bash
python3 scripts/tfl_journey_disruptions.py \"940GZZLUSTD\" \"W1F 9LD\" --depart-at 0900
python3 scripts/tfl_journey_disruptions.py --from \"Stratford\" --to \"W1F 9LD\" --arrive-by 1800
```

Notes:
- If the API returns disambiguation options, pick one and retry with its `parameterValue`.
- If you have TfL API keys, set `TFL_APP_ID` and `TFL_APP_KEY` in the environment.

## Inputs to collect

- From: postcode, stop/station name, place name, or lat,lon
- To: postcode, stop/station name, place name, or lat,lon
- Time + intent: depart at or arrive by (and date if not explicit)
- Optional: mode or accessibility constraints if the user mentions them

If any of these are missing or ambiguous, ask the user for clarification.

## Resolve locations

Prefer postcodes when available. Otherwise, resolve place names and stations:

- If input looks like a UK postcode, use it directly as `{from}` or `{to}`.
- If input is lat,lon, use as-is.
- If input is a stop or station name, try `StopPoint/Search/{query}` and choose a hub or the relevant NaPTAN ID.
- If the search or journey result returns disambiguation, show the top options (common name + parameterValue) and ask the user to pick.
- When unsure, ask a clarifying question rather than guessing.

## Plan journeys

Call:

`/Journey/JourneyResults/{from}/to/{to}?date=YYYYMMDD&time=HHMM&timeIs=Depart|Arrive`

Guidelines:
- If the user says "arrive by" use `timeIs=Arrive`; otherwise default to `Depart`.
- If the date is not provided, ask. If the user implies "now", you can omit date/time.

## Extract candidate routes

From the response, take the first 1-3 journeys. For each, capture:
- Duration and arrival time
- Public transport legs (mode, line name, direction)
- Line IDs for disruption checks

Line IDs usually appear in `leg.routeOptions[].lineIdentifier.id` or `leg.line.id`. Ignore walking legs.

## Disruption checks

For each journey, collect unique line IDs and call:

`/Line/{ids}/Status`

Treat a route as disrupted if any line status is not "Good Service" or includes a reason. Summarize the severity and reason.

Optionally, check station-specific issues with `/StopPoint/{id}/Disruption` when relevant.

## Response strategy

- If the top route has no disruptions, recommend it and say no active disruptions were found.
- If the top route is disrupted, warn first, then propose 1-2 alternative routes from other journeys.
- If all routes are disrupted, still recommend the best option but list the disruption warnings and alternatives.
- If the journey is for a future time (later today or another day), note that disruption statuses are current and may change by the travel time (for example: "Minor Delays now; this may change by morning").
- Always invite the user to confirm a route or provide clarifications.