update-climate-data
Skill160 starsChanged 6 months agoMITView on GitHub
Run OWID's monthly climate data update. Bumps all updateable climate-namespace datasets to one common version in a single PR with one announcement, skipping the frozen sources. Use when the user wants to update climate data or run the monthly climate update. For a wildfires-only refresh during fire season, use the update-wildfires-data skill instead.
We split this skill into the rules it gives an agent
7 rules. About 0 are common, 3 are distinctive, and 4 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈3
Distinctive · estimate
This author's own choices. Worth a look.
4
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 11
All OWID climate data is updated once a month as a single batch: every updateable climate-namespace dataset is bumped to one common version …
- Distinctive: line 69
If a frozen source's producer ever republishes, that is a separate, deliberate version bump — not part of the monthly run.
- Very specific: line 78
Run all grapher steps and the climate_change explorer (the explorer stays latest).
- Very specific: line 86
Create the branch + draft PR with etl pr "📊 Update climate data" data.
- Very specific: line 88
Run each updateable chain through the /update-dataset flow on that branch, all targeting today's date as <new_version> so they land on a …
- Very specific: line 102
If the old entries were already removed, restore them: git checkout <base> -- <old folders> dag/archive/climate.yml, and append the old …
- Distinctive: line 146
After these land, update this skill's inventory if any short_names or namespaces changed.
≈ “Common” is an estimate: at least 1 in 5 of the 308,232 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Climate update (monthly umbrella update)
All OWID climate data is updated once a month as a single batch: every updateable
climate-namespace dataset is bumped to one common version date, in one PR, with one
Slack announcement. This skill owns which datasets, in what order, and the
single-PR / single-announcement discipline. It delegates the per-dataset mechanics
(snapshot → meadow → garden → grapher, diffs, metadata checks, chart upgrade) to
/update-dataset — run each chain through that flow on
the same branch.
The matching reminder lives in owid-issues/.github/workflows/update-climate.yml
(one monthly issue on the 10th). Wildfires is the one dataset with a reminder of its
own on top of that: update-climate-wildfires.yml fires weekly from May to the end of
September.
Modes
- Full monthly update (default): bump every updateable dataset below to a common new version date.
- Wildfires-only subset: bump just
weekly_wildfires(and optionallyyearly_burned_area) to a new version, for the weekly in-season refresh. Follow/update-wildfires-data, which covers the source's weekly grid, its provisional last data point, and the snapshot's silent per-country failure mode. Come back here only if you are bumping the whole batch.
Updateable datasets (climate.yml "UPDATEABLE" section)
Grouped by source. Bump all of these to the same new version date.
| Source | Garden dataset(s) | Snapshot(s) | Cadence |
| Copernicus ERA5 | surface_temperature | surface_temperature.zip | monthly |
| Copernicus ERA5 | total_precipitation | total_precipitation.zip | yearly |
| GWIS | weekly_wildfires | weekly_wildfires.csv | continuous (fire season) |
| GWIS | yearly_burned_area | yearly_burned_area.csv | yearly |
| NOAA (Equatorial Pacific) | sst | sst.csv | monthly |
| NOAA GML | ghg_concentration | co2/ch4/n2o_concentration_monthly.csv | monthly |
| NSIDC | sea_ice_index | sea_ice_index.xlsx | monthly |
| NASA Ozone Watch | nasa_ozone_hole | nasa_ozone_hole_p1/p2.txt | yearly |
| Rutgers Global Snow Lab | snow_cover_extent | snow_cover_extent_*.csv | monthly |
| Hawaii Ocean Time-series | ocean_ph_levels | hawaii_ocean_time_series.csv | monthly |
| Met Office Hadley Centre | sea_surface_temperature | sea_surface_temperature_*.csv | monthly |
| Met Office Hadley Centre | near_surface_temperature | near_surface_temperature_*.csv | yearly |
| NOAA NCEI | ocean_heat_content | ocean_heat_content_*.csv | monthly |
Plus two derived/aggregate datasets with no snapshot of their own:
long_run_ghg_concentration(combines NOAAghg_concentrationwith the frozen EPA series)climate_change_impacts(the aggregate; pulls most of the rows above)
The yearly sources usually show no change in a given month — that is expected, not a bug.
Frozen — NEVER bump these (climate.yml "NOT UPDATEABLE" section)
Skip entirely. They receive no new data and several feed climate_change_impacts:
- EPA 2024-04-17:
ghg_concentration,ocean_heat_content,ice_sheet_mass_balance,mass_balance_us_glaciers global_sea_level(2024-01-28, NOAA Climate.gov)ipcc_scenarios- The 12 migrated legacy chains (one-off papers / historical sources, dates 2017-2022)
If a frozen source's producer ever republishes, that is a separate, deliberate version bump — not part of the monthly run.
Dependency order
- Bump and run the leaf source chains (snapshot → meadow → garden) for every updateable
dataset above.
climate_change_impacts's frozen deps (EPA, global_sea_level) stay on their old versions — reference them unchanged. - Bump and run
long_run_ghg_concentration, then theclimate_change_impactsaggregate. - Run all grapher steps and the
climate_changeexplorer (the explorer stayslatest).
The grapher families to rebuild: the 7 surface_* graphers, total_precipitation_annual,
the 4 wildfire graphers, sst/sst_by_month, nasa_ozone_hole, the 3 sea_ice_*
graphers, climate_change_impacts_annual/_monthly, and yearly_burned_area.
Procedure
- Create the branch + draft PR with
etl pr "📊 Update climate data" data. One branch and one PR for the whole batch. - Run each updateable chain through the
/update-datasetflow on that branch, all targeting today's date as<new_version>so they land on a common version. Follow the dependency order above, so the aggregate picks up the new versions once rather than repeatedly. Keep the DAG's nesting and comment headers: version-substitute the existing UPDATEABLE block instead of keeping the flat blocketl updateappends. Do not remove or archive the old steps yet. The previous versions (their step files, their snapshot folders and their
dag/climate.ymlentries) stay active until the review is done. Two things depend on them being present:- The reviewer compares consecutive versions with the
compare-previous-versionVS Code extension, which diffs each step file against the same-named file in the nearest lower version folder. Delete the old folders and there is nothing to compare against. - The chart remap (step 4) finds each dataset's predecessor through the version tracker,
which reads only the active DAG. Remove the old DAG entries first and
etl indicator-upgrade autoreports "No dataset migrations detected".
If the old entries were already removed, restore them:
git checkout <base> -- <old folders> dag/archive/climate.yml, and append the old UPDATEABLE block todag/climate.ymlunder a comment that says it is kept until the review is done.- The reviewer compares consecutive versions with the
Chart remap on staging via the Indicator Upgrader. The version bump mints new variable IDs for every grapher dataset, and charts do not follow on their own; until the remap, Chart Diff shows nothing. With both versions in the DAG, automatic detection works:
STAGING=1 .venv/bin/etl indicator-upgrade auto --dry-run STAGING=1 .venv/bin/etl indicator-upgrade autoIt detects 18 of the 20 pairs. The two
climate_change_impacts_*grapher steps are declared only under the explorer'sviz://entry and the version tracker does not list them; remap those two by hand (match -old <id> -new <id> --perfect-match-only, thenupgrade; dataset ids fromdatasetson staging, whosecatalogPathhas nographer/prefix). Staging can hold two old wildfire versions (the batch's and the last weekly one): pair the one that carries charts. Afterwards, check that no old dataset still carries a chart and that the per-dataset chart counts on staging equal production's. Watch the once-off cases: any dataset changing namespace needs its remap reviewed explicitly (see below).- Hand off for review. In the PR body and in the chat, list exactly which files changed in
content relative to the previous version, so the reviewer does not have to open all ~110
files. Compute it with
cmpbetween the old and new version folders; in a normal month only the snapshot folder differs (the.dvcfiles and any edited snapshot script), and every meadow, garden and grapher file is byte-identical to its predecessor. Then Anomalist + Chart Diff on staging (enable "Show all charts"). - Only when the user says the review is done, archive the old versions, as the last
commits before merge: remove the old block from
dag/climate.ymland the old step and snapshot folders (git rm -r) → commit →etl archive-dag(it reads committed history) → commitdag/archive/climate.yml. It should add exactly the old climate steps (48 for a full batch). Remind the user of this step at the end of every hand-off; it is easy to forget and the PR must not merge with both versions active. - One announcement: run
/draft-data-update-slack-postfor the combined batch, post to #data-updates-comms, and draft the single/latestpost. Do not produce per-dataset announcements.
One-off migrations (only on the first run after the refactor)
These are structural moves that happen once, then the dataset behaves like any other updateable one:
ipcc_scenarios: namespaceemissions→climate, and EPA 2024-04-17: namespaceepa→climate(retires theepanamespace). ipcc also moves its standalone explorer. EPA has no charts of its own (it only feedsclimate_change_impacts), so its move is chart-free; ipcc's needs an explorer/chart remap.
After these land, update this skill's inventory if any short_names or namespaces changed.
In this repository39 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- .github/instructions/copilot-instructions.mdCopilot instructions
- add-gdp-scatterSkill
- add-ivs-indicatorsSkill
- add-provider-regionsSkill
- babysit-prSkill
- check-chart-previewSkill
- check-empty-entitiesSkill
- check-hardcoded-yearsSkill
- check-metadata-styleSkill
- check-metadata-typosSkill
- check-outdated-practicesSkill
- create-chartSkill
- create-datasetSkill
- create-etl-stepsSkill
- create-explorerSkill
- create-snapshotSkill
- create-static-vizSkill
- develop-vscode-extensionSkill
- develop-wizard-appSkill
- draft-data-update-slack-postSkill
- edit-faust-metadataSkill
- fact-check-datasetSkill
- find-chart-referencesSkill
- fix-dependabotSkill
- generate-metadataSkill
- map-charts-to-mdimSkill
- map-explorer-to-mdimSkill
- migrate-explorer-to-etlSkill
- profile-etl-stepSkill
- query-grapher-dbSkill
- remap-ghost-variablesSkill
- report-indicator-changesSkill
- review-data-prSkill
- sync-grapher-schemaSkill
- tool-owlSkill
- update-datasetSkill
- update-wildfires-dataSkill
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
Reviews can't be read right now.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

