Keyless Weather Lookup

Problem to solve

When an engineer needs weather in a script, agent, or tooling chain, they usually do not want to register an API key, manage quotas, or add complex config for a one-off lookup. This skill targets a narrow job: get weather from public services while keeping a programmatic JSON path available.

How it works

The core path has two layers:
- Primary wttr.in: good for human-readable terminal output and quick checks; supports ?0 for current, ?1 for today, ?m for metric, ?u for USCS, plus location forms such as New+York or JFK, and can export PNG.
- Fallback Open-Meteo: good for scripts; resolve city coordinates first, then request JSON with fields such as temperature, wind speed, and weathercode.
This mix lets the skill print readable weather now and still support threshold checks, logging, or automation later.

Boundaries

It depends on external service availability, and data accuracy depends on coordinates and provider quality; do not rely on it alone for real-time decisions, professional meteorology, or high-availability SLAs. Encode spaces in city names, and fail clearly when coordinate lookup fails instead of silently continuing.