git:20260504.0bc1f59 to git:20260925.0767e87

48 added, 31 removed. Audit A to A.

---

name: releases-mcp

description: Use when the user asks about recent releases, changelogs, what's new in a library, breaking changes, version updates, or wants to compare products. Activates for questions like "what changed in Next.js 15?", "latest Tailwind releases", "compare Bun vs Deno releases".

---

-

# Releases.sh — Changelog Lookup

- When the user asks about releases, changelogs, or version updates, use the Releases.sh MCP tools to fetch current data instead of relying on training data.

+ When the user asks about releases, changelogs, or version updates, use the Releases.sh MCP tools to fetch current data instead of relying on training data. Training data is stale for fast-moving libraries; these tools read the live registry.

## When to Use This Skill

Activate when the user:

- Asks what's new or changed in a library/product ("What changed in Next.js 15?")

- Wants recent releases or changelogs ("Show me the latest Tailwind releases")

- Asks about breaking changes or migration ("Were there breaking changes in Prisma 6?")

- Wants to compare release activity between products ("Compare Bun vs Deno releases")

- - Mentions version updates, release notes, or changelogs in the context of a specific product

+ - Mentions version updates, release notes, or changelogs for a specific product

+ - Asks about a curated topic feed ("what's new across the AI labs?")

+ ## The Tools

+ The hosted server exposes these tools. There is no AI summarization or comparison tool — you synthesize those yourself from the data below.

+ - `search` — unified search across four sections: orgs, catalog (products + standalone sources), collections, and releases. Your default entry point.

+ - `get_latest_releases` — recent releases, optionally scoped by `organization` or `product`. Use `since` / `until` for time windows.

+ - `list_organizations` / `get_organization` — browse and inspect orgs.

+ - `list_catalog` / `get_catalog_entry` — browse and inspect catalog entries. Each entry carries `entryType: "product" | "source"`. `get_catalog_entry` also serves CHANGELOG slices (see below).

+ - `get_release` — fetch one release in full by its `rel_` id (ids come from `search` / `get_latest_releases`).

+ - `list_collections` / `get_collection` / `get_collection_releases` — curated cross-org "playlists" (e.g. "Frontier AI Labs", "Coding Agents") independent of the category taxonomy.

+ - `lookup_domain` — resolve a URL/domain to the org that owns it. Use when you have a URL-shaped input rather than a name.

+ - `whats_changed` (**beta**) — the changelog entries between two versions of a package: `whats_changed(package, from, to)` returns the releases in `(from, to]` with summaries, breaking-change verdicts, and migration notes. Use it to plan an upgrade instead of reading many changelog pages. `package` is a tracked source slug or a GitHub `owner/repo`. No sign-in needed.

+ The server also exposes **signed-in account tools**. They act on the user's own account, need an authenticated connection (a "Sign in with Releases" OAuth token or a `relu_` user API key), and return an error for anonymous clients. The reader tools above need no auth.

+ - `follow` / `unfollow` / `list_follows` and `get_personalized_feed` — the user's follows and their feed. Reach for these only when the user asks about *their* follows or feed. For general "what's new in X" questions, the reader tools answer without sign-in.

+ - `list_webhooks` (read-only) and `manage_webhook` (`create` / `update` / `delete` / `test` / `rotate_secret`) — the user's release webhooks. Pass `workspace` (an id or slug) to work on a shared workspace's webhooks instead; `list_webhooks` with no `workspace` also lists the user's workspaces. Workspace owners and admins can change workspace webhooks; members can list and test them. Workspace webhooks target one org (no follows scope). `create` needs `format` (`json`, `slack`, or `discord`). A `json` webhook's signing key is shown only once, on create or rotate — tell the user to store it right away. Slack and Discord webhooks have no signing key. Only create, change, or delete a webhook when the user asks for it.

## How to Look Up Releases

- ### Step 1: Find the Organization or Catalog Entry

+ ### Step 1: Resolve the entity

- Call `list_organizations` with the library/product name as the `query` parameter. For product-specific questions, browse the catalog (products + standalone sources) with `list_catalog` and fetch detail with `get_catalog_entry` — these replaced the older `list_products` / `get_product` / `list_sources` / `get_source` tools, which still exist as deprecated aliases.

+ Start with `search` and the product or company name — it returns orgs, catalog, collections, and releases in one call, so you usually don't need a separate lookup. Narrow with `type` (e.g. `type: ["catalog"]` for a fast registry-only lookup, `type: ["releases"]` for pure release content).

- The unified `search` tool is also available — it returns `orgs`, `catalog`, and `releases` sections in one call. Catalog hits carry a `kind: "product" | "source"` discriminator, so you can route a click to either a product page or a standalone source. (Older API responses send the same array under a deprecated `products` alias; new clients should consume `catalog`.)

+ If a name doesn't resolve, try variations:

- If the query returns no results, try variations:

- - The company name instead of the product name (e.g., "Vercel" instead of "Next.js")

- - The GitHub org name (e.g., "supabase")

- - A domain (e.g., "tailwindcss.com")

- - A `{org}/{repo}` GitHub coordinate (e.g., "vercel/next.js" or "github:vercel/next.js"). When `search` finds no entity match for a coordinate-shaped query, the registry probes GitHub on demand and the response includes a `lookup` field with status `indexed` / `existing` / `empty` / `not_found` / `deferred`. Coordinate matching is case-insensitive, so `Shopify/toxiproxy` and `shopify/toxiproxy` resolve identically.

+ - The company instead of the product ("Vercel" rather than "Next.js")

+ - The GitHub org ("supabase")

+ - A domain — or use `lookup_domain` directly (e.g. "tailwindcss.com")

+ - A `{org}/{repo}` GitHub coordinate ("vercel/next.js"). When nothing matches a coordinate-shaped query, the registry probes GitHub on demand and the response carries a `lookup` field with status `indexed` / `existing` / `empty` / `not_found` / `deferred`. Coordinate matching is case-insensitive.

- ### Step 2: Choose the Right Tool

+ ### Step 2: Pick the right follow-up

- - **"What's new?" / "Latest releases"** → Use `get_latest_releases` with the organization or product identifier (typed ID like `org_…` / `prod_…` / `src_…`, slug, or `org/slug` coordinate)

- - **Specific feature or keyword across orgs + catalog + releases** → Use `search` (unified) with a descriptive query; narrow via `type: ["releases"]` etc.

- - **Releases-only search** → Use `search_releases` (kept for back-compat) when you only want release rows

- - **Single release by id** → Use `get_release` when you already have a `rel_` id (search results include ids)

- - **Catalog deep-dive (product or standalone source)** → Use `get_catalog_entry` for metadata, tags, and linkage

- - **Organization detail** → Use `get_organization`

- - **Canonical CHANGELOG.md from a GitHub repo** → Use `get_catalog_entry` with `include_changelog: true` when the user wants the full maintained file, not just the tagged releases (refreshed on every fetch). For large files, pass `changelog_tokens` (cl100k_base budget, e.g. 5000 or 10000) to get a heading-aligned slice that fits a known context window; chain via the returned `nextOffset`. Every response reports `totalTokens` so you can plan how many calls you need upfront.

- - **Compare two products** → Fetch each product separately with `get_catalog_entry` (and `get_latest_releases` for recent activity), then synthesize the comparison from the returned data. The hosted MCP server does not expose AI summarization tools.

+ - **"What's new?" / "Latest releases"** → `get_latest_releases` with `organization` or `product`. Add `since` (e.g. `"30d"`, `"6m"`, or an ISO date) for "last month" / "since v4" style asks.

+ - **Keyword across the whole registry** → `search` with a descriptive query; narrow with `type`.

+ - **One release in full** (to quote a note verbatim) → `get_release` with the `rel_` id from search results.

+ - **Entity metadata** → `get_catalog_entry` (products/sources) or `get_organization` (orgs, with an AI overview preview; `include_overview: true` for the full briefing).

+ - **Full maintained CHANGELOG.md** → `get_catalog_entry` with `include_changelog: true`. This only applies to **source** entries that track a checked-in CHANGELOG.md — products and tag-only repos (e.g. Next.js, which ships GitHub releases but no CHANGELOG file) return none. For large files, pass `changelog_tokens` (recommended brackets: 2000 / 5000 / 10000 / 20000) to get a heading-aligned slice, then chain via the returned `nextOffset`. Every response reports `totalTokens` so you can budget calls upfront.

+ - **A curated topic feed** → `list_collections` to discover, `get_collection_releases` for the interleaved cross-org feed.

- ### Step 3: Present Results

+ ### Step 3: Compare products (no built-in tool)

- - Lead with the most relevant information for the user's question

- - Include version numbers and dates when available

- - Quote key changes directly from the release notes

- - If results are sparse, mention that the product may not be fully indexed yet

+ There is no `compare_products` or `summarize_changes` tool on the hosted server. To compare, fetch each product separately (`get_catalog_entry` for metadata, `get_latest_releases` for recent activity) and synthesize the comparison yourself. Both products must be indexed — if one isn't found, say which is missing rather than guessing.

+ ### Step 4: Present results

+ - Lead with what answers the user's question.

+ - Include version numbers and dates when available.

+ - Quote key changes from the release notes (keep quotes short).

+ - If results are sparse, say the product may not be fully indexed yet — don't fabricate release info.

## Guidelines

- - Pass the user's full question context into query parameters for better relevance

- - When the user mentions a time range ("last month", "since v4"), use the `days` parameter on `get_latest_releases`

- - If a product isn't found, say so clearly — don't fabricate release information

- - For comparison questions, both products must be indexed; if one isn't found, explain which is missing

+ - Pass the user's full question into query parameters for better relevance.

+ - For time windows, use `since` / `until` on `get_latest_releases` and `search` (relative shorthand like `"90d"` or ISO dates).

+ - The `kind` filter (`platform|sdk|mobile|desktop|docs|integration|tool`) behaves differently by surface: on **release** results a source inherits its parent product's kind, so `kind: "sdk"` returns content under any SDK product; on **catalog** results it matches the row's own kind only. Reach for it when a query is explicitly scoped to one kind ("which SDKs shipped this week").

+ - If a product isn't found, say so clearly — don't invent releases.