Requirements
- Target platform
- OpenClaw
- Install method
- Manual import
- Extraction
- Extract archive
- Prerequisites
- OpenClaw
- Primary doc
- SKILL.md
Plan TfL journeys from start/end/time, resolve locations (prefer postcodes), and warn about disruptions; suggest alternatives when disrupted.
Plan TfL journeys from start/end/time, resolve locations (prefer postcodes), and warn about disruptions; suggest alternatives when disrupted.
Hand the extracted package to your coding agent with a concrete install brief instead of figuring it out manually.
I downloaded a skill package from Yavira. Read SKILL.md from the extracted folder and install it by following the included instructions. Tell me what you changed and call out any manual steps you could not complete.
I downloaded an updated skill package from Yavira. Read SKILL.md from the extracted folder, compare it with my current installation, and upgrade it while preserving any custom configuration unless the package docs explicitly say otherwise. Summarize what changed and any follow-up checks I should run.
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
Use scripts/tfl_journey_disruptions.py for a quick journey + disruption check. Examples: 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.
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.
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.
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.
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.
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.
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.
Data access, storage, extraction, analysis, reporting, and insight generation.
Largest current source with strong distribution and engagement signals.