openweathermap-api-integrationlisted

Use this skill whenever integrating OpenWeatherMap's free-tier API into an app — current weather, 5-day/3-hour forecast, geocoding (city name to coordinates and back), or securely configuring the API key (local.properties, BuildConfig, request interceptor). Trigger on mentions of "OpenWeatherMap", "openweathermap.org", "forecast5", "data/2.5/weather", "data/2.5/forecast", "geo/1.0/direct", "geo/1.0/reverse", "OWM", or "OpenWeatherMap API key". Also trigger for the general technique of aggregating interval-based forecast data (e.g. 3-hourly) into daily buckets, which generalizes beyond weather to any interval-sampled forecast/timeseries API. Covers the free endpoints, which name/ID-based lookups are deprecated in favor of geocoding, the client-side daily-aggregation logic the free tier requires, and safe API key storage. Not a tech-stack tutorial — pair with whatever networking/DI/caching pattern the project already uses (e.g. an offline-first caching skill).
rajedev/AIWeatherApp · ★ 0 · API & Backend · score 62

Install: claude install-skill rajedev/AIWeatherApp

# OpenWeatherMap API Integration ## Free-tier endpoints — the only ones this skill uses No card, no subscription activation required for any of these: | Endpoint | Gives you | |---|---| | `api.openweathermap.org/data/2.5/weather` | Current conditions | | `api.openweathermap.org/data/2.5/forecast` | 5 days, 3-hour steps (40 points) | | `api.openweathermap.org/geo/1.0/direct` | Name → lat/lon (forward geocoding) | | `api.openweathermap.org/geo/1.0/reverse` | Lat/lon → name (reverse geocoding) | These four endpoints fully cover current + short-range forecast + city resolution. ## Deprecated: city name / city ID directly on weather endpoints ``` # Deprecated — still works, but no further bug fixes or updates: GET /data/2.5/weather?q={city name}&appid={key} GET /data/2.5/forecast?id={city id}&appid={key} ``` Don't build new integrations on `q=`/`id=` against the weather/forecast endpoints. Use the dedicated Geocoding API to resolve a name to coordinates first, then call weather/forecast with `lat`/`lon` only — that's the supported, maintained path. ## Geocoding — forward (search) and reverse (resolve-from-coordinates) ``` GET /geo/1.0/direct?q={city name},{state code},{country code}&limit=5&appid={key} GET /geo/1.0/reverse?lat={lat}&lon={lon}&limit=5&appid={key} ``` - `limit` matters on the forward call: same-named places are common (London, UK vs. London, US) — always request `limit>1` and let the user disambiguate rather than silently taking the first result. - State c