Skip to content

fix(skills): weather skill uses keyless wttr.in instead of key-gated APIs#351

Closed
initializ-mk wants to merge 1 commit into
mainfrom
fix/weather-keyless-wttr-349
Closed

fix(skills): weather skill uses keyless wttr.in instead of key-gated APIs#351
initializ-mk wants to merge 1 commit into
mainfrom
fix/weather-keyless-wttr-349

Conversation

@initializ-mk

Copy link
Copy Markdown
Contributor

Closes #349.

Problem

The bundled weather embedded skill could never work as shipped: its egress_domains allowed only api.openweathermap.org + api.weatherapi.com (both key-gated), yet it declared no API-key env at all — so the two hosts the egress gate permitted were exactly the two that reject an unauthenticated request. Its tool sections were also prose-only, with no runnable command.

Fix

Repoint the skill at wttr.in — free, keyless, and it takes a city name directly, so it maps 1:1 to the existing location (string) input with no geocoding step (the issue’s recommended option; also already the endpoint our own Skill Builder UI suggests at app.js:2902).

  • egress_domains: [wttr.in]; env.required: [] stays empty because none is needed; added jq to bins.
  • Two runnable scripts (matching the tavily-search convention — JSON arg in, shaped JSON out):
    • scripts/weather-current.sh ${apos}{"location":"Tokyo"}${apos}
    • scripts/weather-forecast.sh ${apos}{"location":"Tokyo","days":3}${apos}
    • Both validate input, URL-encode the location, check the HTTP status, and emit shaped JSON via jq. No API key, no env.
  • Rewrote SKILL.md tool sections with runnable curl/script bodies and an accurate output schema (forecast documented as capped at 3 days, wttr.in’s free limit).

Kept in sync (issue blast-radius)

File Change
forge-cli/internal/tui/steps/egress_step.go egress-wizard domain hint → wttr.in: "weather skill"
forge-skills/local/scanner_test.go fixture domain → wttr.in
.claude/skills/forge.md weather authoring example made keyless-consistent (bins: [curl, jq], required: [], egress_domains: [wttr.in])

Verification

  • Live-tested both scripts against wttr.in (current + forecast for Tokyo/London) — keyless, correct shaped JSON.
  • Scripts are shellcheck-clean; bash -n clean; committed 100755.
  • gofmt + golangci-lint clean on the touched packages; forge-skills/... and forge-cli/internal/tui/... suites green.

Note

This unblocks the forge try hero interaction in #350 (Phase 1 requires a keyless weather demo). #350’s transcript illustrates Open-Meteo; wttr.in is the simpler drop-in for a city-name skill. If a structured multi-day (7-day) forecast is later wanted, Open-Meteo + its geocoding host is the documented alternative in #349.

…APIs (#349)

The bundled weather skill allowed egress only to api.openweathermap.org
and api.weatherapi.com — both require an API key — yet declared no key
env at all, so it was dead on arrival. Its tool bodies were also prose
only, with no runnable command.

Repoint it at wttr.in (free, keyless, accepts a city name directly so it
maps 1:1 to the location input) and ship two runnable scripts:

- scripts/weather-current.sh  '{"location":"Tokyo"}'
- scripts/weather-forecast.sh '{"location":"Tokyo","days":3}'

Both use curl + jq, need no API key, validate input, check the HTTP
status, and emit shaped JSON. egress_domains is now [wttr.in].

Kept in sync: the egress-wizard domain hints (egress_step.go), the
scanner test fixture, and the weather example in .claude/skills/forge.md.

Verified live against wttr.in (current + forecast); scripts are
shellcheck-clean; forge-skills and forge-cli/internal/tui suites green.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Weather embedded skill points at key-gated APIs (never works) — switch to a keyless service

1 participant