---
name: check-sdk-updates
description: Check whether tracked SDKs/libraries (listed in sdks.toml, e.g. SDL, box3d, imgui, entt) have newer releases than the version currently pinned in this project, and summarize what changed. Use this whenever the user asks to check for SDK/library updates, wants release notes for a dependency, or says things like "SDK 업데이트 확인해줘", "check for updates", "새 버전 나왔나" — even if they only name one library instead of "all of them".
---

# Check SDK Updates

Compare each tracked library's pinned version (in `sdks.toml`, next to this file) against its latest release, and report only what actually changed.

## Steps

1. Read `sdks.toml`. Each `[[sdk]]` entry has `name`, `type` (`github` or `url`), and `current_version`. If the user names a specific library, only check that one; otherwise check all.

2. For each entry, fetch its latest release:
   - **`type = "github"`**: use `gh api repos/{repo}/releases` (via Bash) to list releases — this gives structured, reliable data (tag names, bodies, dates). Prefer this over scraping the HTML releases page.
   - **`type = "url"`**: use WebFetch on the given `url`, since there's no repo to query via `gh`. Parsing quality depends on how the page is structured, so double check the extracted version number looks sane before reporting it.

3. Compare the latest tag against `current_version`. Versions may not sort alphabetically (e.g. `3.4.10` > `3.4.9`) — compare numeric segments, not strings.

4. If there's no newer version, say so briefly for that library — don't pad the report with "no changes" filler beyond one line.

5. If there's a newer version, collect the release notes for **every version between `current_version` (exclusive) and latest (inclusive)** — not just the latest tag's notes, since intermediate releases can contain fixes the user cares about. Summarize the changes, grouping by theme (e.g. graphics/rendering, platform-specific, breaking changes) rather than just listing raw bullet points per release. Call out anything that looks breaking or notable (API removals, default behavior changes, security fixes) before routine bugfixes.

## Output format

For each library checked, report:
- Name, current version → latest version (or "up to date")
- If updated: a short thematic summary of what changed across the skipped versions, most notable items first

Keep it scannable — this is a status check, not a full research report. Don't fetch or summarize unrelated project history.

## Notes

- Do not edit `sdks.toml`'s `current_version` automatically after reporting — that's the user's call once they've actually upgraded the dependency in the project.
- If the user says they've upgraded a library, offer to update its `current_version` in `sdks.toml` accordingly.