public-data-api-picker
Use when a task needs real, live data but the domain is vague or unstated - "I need real data for X", "is there a free API for this?", "pull actual data into this demo", "no mock data, use a real source", or picking a data source before building. Routes to the right Live Data skill (weather-climate, geo-places, finance-fx, space-earth-science, government-open-data, test-placeholder-data, language-reference, fun-content), every one backed by keyless liveness-verified APIs. Do NOT use when the domain is already explicit - a request naming weather, FX, earthquakes, or fake users goes straight to that skill; do NOT use for designing your own API - use api-design instead.
- License 许可
- MIT
- 最近更新
- 2026-10-14
- Stars
- ★ 25
- Forks
- 3
01 前言 Front Matter
- name
- public-data-api-picker
- metadata
- { "title": "Public Data API Picker" }
- description
- Use when a task needs real, live data but the domain is vague or unstated - "I need real data for X", "is there a free API for this?", "pull actual data into this demo", "no mock data, use a real source", or picking a data source before building. Routes to the right Live Data skill (weather-climate, geo-places, finance-fx, space-earth-science, government-open-data, test-placeholder-data, language-reference, fun-content), every one backed by keyless liveness-verified APIs. Do NOT use when the domain is already explicit - a request naming weather, FX, earthquakes, or fake users goes straight to that skill; do NOT use for designing your own API - use api-design instead.
03 SKILL.md 正文
Public Data API Picker
Route a vague "I need live data" request to the sibling skill whose APIs are liveness-verified - instead of deliberating over a directory or reaching for a key-walled API from training memory. This skill only routes; every URL template, response shape, and gotcha lives in the domain skill.
Routing table
| The task needs | Route to |
|---|---|
| Forecast, current conditions, historical weather, air quality, US weather alerts | weather-climate |
| Geocoding, reverse geocoding, city→coordinates, postal codes, country facts (capital, currency, flag) | geo-places |
| FX rates (current or historical), currency conversion, crypto prices and market caps | finance-fx |
| Earthquakes, NASA imagery (APOD, Earth full-disk), near-Earth asteroids | space-earth-science |
| Country statistics over time - GDP, population, inflation, emissions; EU-official figures | government-open-data |
| Fake products/users/posts for a demo or tutorial, placeholder images, teaching CRUD | test-placeholder-data |
| Word definitions, pronunciation, synonyms; Wikipedia summaries and search | language-reference |
| Trivia/quiz questions, animal pictures, advice, random facts | fun-content |
Tie-breakers
- "Weather in Paris" needing coordinates first → still weather-climate (it embeds the one city→lat/lon step); geo-places only when geography is the deliverable.
- Money: rates and prices → finance-fx; economic indicators over years → government-open-data.
- Images: layout filler → test-placeholder-data (Picsum); dog/cat content → fun-content; satellite Earth → space-earth-science.
- Facts about a country: static (capital, currency) → geo-places; time-series (GDP, population trend) → government-open-data; prose ("history of Japan") → language-reference.
- Demo needs realistic-looking data → test-placeholder-data; demo needs true data → the matching domain skill. Ask which one thing if genuinely unclear; never mix fake data into a real-data feature.
Worked routing example
Request: "Add a widget to this dashboard showing actual conditions for the user's city - no mock data."
Bad - deliberating instead of routing: listing OpenWeatherMap, WeatherAPI, and Open-Meteo with pros and cons, asking the user which they prefer, or starting from a key-signup page. The user asked for data, not a survey; two of those three options are key-walled dead ends.
Good - route and act: "Real conditions by city is a weather need with an embedded city→coordinates step - weather-climate." Then that skill's procedure runs: geocode the city via its one-step geocoder, call Open-Meteo's forecast endpoint with current= fields, render values with units from current_units. One skill fired, zero APIs evaluated, first call worked.
Counter-example the other direction: "Show each user's distance from HQ" mentions no weather - geography is the deliverable, so it routes to geo-places even though both skills touch coordinates.
Not covered - say so instead of improvising
No skill in this set covers: stock/equity quotes, IP geolocation, ISS position, or US Census microdata - the free options failed liveness or auth verification. Name the gap and the nearest paid/keyed alternative rather than citing a dead endpoint from memory.
Deliverable
A one-line route ("this is an FX-history need - finance-fx") and then the routed skill's procedure executed. If two skills genuinely apply, name both and the split.
Do NOT
- Do not execute API calls from this skill - templates and gotchas live in the domain skills; duplicating them here is how they drift.
- Do not fall back to OpenWeatherMap, Google Maps, Alpha Vantage, or other key-walled defaults from training memory - the routed skill names the verified keyless replacement.
- Do not dump API options for the user to evaluate - route to one default and act.
Sourced and liveness-verified from the public-apis project (MIT).
04 同仓库更多 Skills
有氧运动计划
zone-2-cardio-plan
当有人要求制定稳态有氧训练计划、进行有氧基础训练或达到第二区间、安排轻松或耐力型的每周有氧训练、按心率区间训练，或提高静息心率、最大摄氧量或耐力时，可以使用此方案。该方案构建了一个包含训练计划结构、训练方式选择和进度安排的心率区间有氧训练模块。本方案仅提供一般健身指导，不构成医疗建议。请勿用于设计力量或举重训练计划（请使用力量训练计划）、高强度间歇训练 (HIIT) 或循环训练（请使用体能训练和 HIIT 计划），或灵活性/柔韧性训练（请使用灵活性训练计划）。
youtube-script-writer
Writes retention-engineered long-form YouTube scripts on a hook/body/payoff architecture - a first-30-seconds hook that survives the retention cliff, a beat-sheet body with mini-hooks and bridges, timed pattern interrupts, and a payoff that over-delivers - with B-roll and editing cues marked inline. Use when someone says "script my next video", "my retention graph dies at the start", "tighten this draft", or "outline a video on X". Do NOT use for the 3-second opener of TikTok, Reels, or Shorts - use video-hook-writer instead; do NOT use for spoken voiceover synced to on-screen tutorial actions - use narration-script instead; do NOT use for a sales demo built on a buyer's discovery notes - use demo-script instead; do NOT use to design the thumbnail and title - use thumbnail-concept instead.
win-back-campaign
Designs segmented win-back email sequences for dormant users - dormancy tiers, a three-beat sequence with a single proportional incentive, and a suppression rule - and measures success by re-activation, not opens. Use when someone says "our users went quiet", "design a win-back campaign", "how do I re-engage lapsed customers", "should we email people who haven't logged in for months", or lifecycle messaging has stopped landing with a lapsed segment. Do NOT use for recovering an unfinished checkout - use abandoned-cart-sequence instead. Do NOT use for diagnosing and fixing why active customers cancel - use churn-reduction instead. Do NOT use for building always-on onboarding or nurture flows - use email-drip-builder instead.
wikipedia-style
Writes neutral, verifiable, encyclopedic prose following Wikipedia's core content policies and manual of style - NPOV, inline citations, notability-backed claims, and a strict ban on promotional language. Use when someone asks "write this like a Wikipedia article", "draft a Wikipedia page for this company or person", "make this neutral and encyclopedic", or "why does my article draft keep getting rejected". Do NOT use for persuasive or opinion writing - use op-ed-writer instead; for thesis-driven academic papers, use academic-essay; for verifying claims in existing text, use fact-checker.
whitepapers
Structures and writes authoritative B2B whitepapers - a standalone executive summary, a data-sized problem statement, methodology, evidence-driven findings, recommendations, and a soft call to action - flagging every claim that needs a real citation. Use when a marketer asks "write a whitepaper on this topic", "turn our research into a lead-gen asset", "make this credible enough for executives", or a draft reads like a product pitch instead of analysis. Do NOT use for customer-story-driven proof - use case-study-builder instead; for policy audiences, use policy-brief.
white-space-analysis
Finds unmet market gaps by ranking jobs-to-be-done on importance versus satisfaction, overlaying them against current solutions and workarounds, and validating that each gap is real, winnable, and worth winning. Use when someone asks "where are the gaps in this market", "what's underserved here", "where should we play next", or is hunting for product, feature, or market-entry opportunities. Do NOT use for profiling competitors and building battle cards - use competitive-intelligence instead; for putting a dollar figure on an identified opportunity - use market-sizing instead; for extracting jobs-to-be-done from raw customer interviews - use jtbd-extractor instead.