Finding Changelogs 的用途是判断如何从变更日志页或发布说明页获取结构化发布数据，很多页面背后存在 RSS/Atom feed、原始 markdown 或 API 等更规整的数据源，找到它们可免去解析渲染 HTML 的复杂度。
主要能力与优先级：官方给出的优先级为知名文件 > link relations > feeds > GitHub Releases API > 原始 markdown > 页面抓取。知名文件按 / .well-known/changelog.json、/.well-known/releases.json、/.well-known/changelog.txt、AGENTS.md/AGENTS.txt、以及根目录 changelog.md 等顺序级联探测；link relations 支持 rel="changelog|releases|release-notes"，带 feed 类型属性时按 feed 处理。github 源在每次抓取时会同时摄取打标签的 release 与仓库根目录的 CHANGELOG.md（或 CHANGES/HISTORY/RELEASES/NEWS.md），无需另加第二个源。
使用方式：CLI 可用 releases admin discovery evaluate <url> --json 评估 URL，输出 recommendedMethod、recommendedUrl、feedUrl/feedType、githubRepo、confidence、alternatives 等。跟踪后可通过 REST GET /v1/orgs/:orgSlug/sources/:sourceSlug/changelog、MCP 工具 get_catalog_entry（include_changelog: true）或 CLI releases admin source changelog <identifier> 读取。支持按标题对齐切片：token 模式（changelog_tokens/--tokens，cl100k_base，推荐 2000/5000/10000/20000）与字符模式（changelog_limit/--limit），两者同时传入时 token 优先；可用 changelog_path 指向 monorepo 内文件，用 changelog_offset 配合返回的 nextOffset 分页，默认响应会列出每个文件及其字节大小。
评估与源选择：evaluate 前会做服务商指纹识别、feed 发现（约 15 个常见路径及 link rel="alternate"）和服务商特定探测；若 confidence 为 low 或推荐 scrape，可自行用 WebFetch 查看源码、找 feed/GitHub 仓库/原始 markdown 并判断页面结构。每个 org 建议 3–5 个高信号源，只索引自有产品而非生态插件；对停滞或低价值源应添加并设为 --priority paused，而非直接跳过。多产品 org 可用产品与标签管理分组，并可将公司级总览变更日志标记为主源（每 org 仅一个）。使用 --crawl 适用于索引页逐条链接到单独发布页的情况，单页变更日志或 feed 不用 crawl。静态服务商可走快路径 render: false；渲染无法绕过 bot 挑战，可用外部 Firecrawl 后端。发现 feed 后必须抽样核对条目确为发布内容，警惕指向 /blog/、标题像教程、无版本号、站点级 feed 等红旗。为控制上下文，避免一次拉取超大文件。具体服务商列表、命令与参数以资料为准；本资料未提供收费、价格等信息。