Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add buildinternet/releases --skill parsing-changelogsgit clone --depth 1 https://github.com/buildinternet/releasesWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/buildinternet/releases/parsing-changelogs)<a href="https://agentmods.dev/skills/buildinternet/releases/parsing-changelogs"><img src="https://agentmods.dev/badge/skills/buildinternet/releases/parsing-changelogs/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/buildinternet/releases/parsing-changelogs"><img src="https://agentmods.dev/badge/skills/buildinternet/releases/parsing-changelogs.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector pass
What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00038 | $0.03423 |
| Opus 5 | $0.00019 | $0.01711 |
| Sonnet 5 | $0.00008 | $0.00685 |
| Haiku 4.5 | $0.00004 | $0.00342 |
Grade A, and why
parsing-changelogs scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 10d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 190 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Parsing Changelogs
How the Releases fetch pipeline converts changelog pages into structured release data.
Pipeline Overview
The fetch pipeline follows this priority order:
- Feed adapter — if the source has a known feed URL (in
metadata.feedUrl), fetch and parse the feed directly. Fastest and most reliable. - Markdown fetch — if
metadata.markdownUrlis set, fetch raw markdown instead of rendered HTML. - Fast fetch (static providers) — for providers known to serve pre-rendered HTML (Docusaurus, VitePress, WordPress, Ghost, Mintlify), fetch without headless browser rendering. Uses Cloudflare crawl API with
render: false. ~10-30x faster than full rendering. Controlled by providerstaticContenthint or per-sourcerenderRequiredmetadata. - Cloudflare rendering — for JS-heavy pages (React SPAs, Notion, etc.), use Cloudflare's browser rendering API to get the fully-rendered HTML. Fallback when fast fetch returns no content.
- Firecrawl monitoring — for sources behind a Cloudflare Managed Challenge that blocks even browser rendering (some vendor help/docs pages, e.g. OpenAI's), an external Firecrawl monitor scrapes the page on a schedule and POSTs changes to the backend, which extracts them through the same parse pipeline. This is a backend-only fetch backend, not a CLI fetch path: it's enabled per source via
metadata.firecrawlthrough the admin API (POST /v1/sources/:slug/firecrawl/sync { enabled: true }), not via metadata edits (that only patches the DB column and skips monitor creation). Seedocs/architecture/firecrawl-monitoring.md.
After fetching content, the pipeline parses it:
- Incremental parsing — if the source already has releases in the database, extract only new ones by comparing against known releases. This is the default for subsequent fetches.
- Bulk parsing — parse the entire page into releases. Used on first fetch or when
--fullis specified.
Fetching
Trigger a fetch for a source by ID or slug. CLI: releases admin source fetch <slug> [--dry-run] [--max <n>]. Typed tool: manage_source action "fetch" with identifier (ID or slug) param.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 10d ago First seen · 190 lines · 38 tokens per session scan A a486a6f9623a
parsing-changelogs is a skill published in the GitHub repository buildinternet/releases (6 stars, last pushed today), licensed Apache-2.0. It adds 38 tokens to every session and 3,423 once invoked, about $0.0002 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other skills, from other repositories
releases-cli
Use the releases CLI to search, browse, and read the Releases.sh changelog registry from the terminal — the keyless, agent-friendly peer of the Releases MCP. Activate when the user mentions "releases CLI", runs a releases command, asks how to install it, or wants to look up releases, sources, orgs, collections, or…
releases-mcp
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".
changelog-generator
Generate a polished CHANGELOG.md and release-notes.md from a local git repository (or a captured .git-log.txt dump). Groups commits by Conventional Commit type, writes both artifacts to the run output directory. Use when asked to draft release notes, summarize commits between tags, or produce a human-readable…
release-checklist
Walk the release checklist before tagging and publishing a version.
changelog-generator
Transform technical git commits into polished, user-friendly changelogs and release notes. Automatically categorizes changes, translates developer language into customer-friendly copy, and generates professional changelog entries.
release-readiness
Use this skill when preparing a tag, package, deployment, or public release.