用途：这是发布说明流水线的分诊阶段，把记录“发布了什么”的 changes.json 转成“哪些值得讲”的 features.json，供下游写作使用。
主要能力：features.json 与 changes.json 保持同一 schema（release_version、release_date、changes、commits 及 id、repo、product、commit 键结构），便于合并、diff 和比较；仅在变更条目上增加可选字段，如 score、score_reason、score_breakdown、breaking_changes、reverted_by、reverts。评分建议用 0-10 一致标度，并遵循 editorial-scoring 评分标准，不另立重要性定义。breaking_changes 与 score 分离，低分但影响升级的变更仍可标记。
使用方式：从 changes.json 出发，不得凭记忆或路线图编造。先做机械式 revert 排查，例如用 jq 筛选标题含 revert/back out 的条目，再用 gh search prs 在源仓库查找后续合并的回退 PR，找到后标注 reverted_by/reverts，并将原条目分数设为 0（除非确认构建仍含该功能）。随后按新公开 API、行为变化、开发者效率、性能影响、兼容迁移等信号评分，降权基础设施与依赖变动、纯测试、内部重构等。可用 api-diff / dotnet-inspect 验证 API 是否真实存在。若已有 features.json，应增量合并，保留原有评分与人工编辑，只评新增或实质变化的 ID。输出通常位于 release-notes/{major.minor}/preview/{previewN}/features.json 或 release-notes/{major.minor}/{major.minor.patch}/features.json。
适用场景：为发布说明、博客等下游流程提供排序后的候选功能列表。
限制：资料未提供具体安装命令、收费、平台与效果信息；评分细则需参考 editorial-scoring 与 feature-scoring.md。