core

Generate and maintain .NET release notes from `features.json`. Uses `generate-changes` for authoritative shipped-change data, `generate-features` for scoring/triage, `update-existing-branch` for incremental reruns on populated branches, `editorial-scoring` for the shared rubric, `api-diff`/`dotnet-inspect` for API verification, and a multi-model `review-release-notes` pass for final editorial QA.

Refresh an existing .NET release-notes milestone branch set incrementally. Checks whether the VMR ref moved, regenerates `changes.json` only when needed, merges the delta into `features.json`, integrates new material into existing markdown clusters across the per-component branches, and responds to review feedback. USE FOR: reruns on a populated release-notes branch set. DO NOT USE FOR: first-pass generation of a new milestone (use generate-changes, generate-features, and release-notes).

Create and update per-distro package files in release-notes/{version}/distros/ that document .NET runtime dependencies and package availability for each Linux distribution. USE FOR: setting up distros/ for a new .NET version, updating dependency package names when distro versions change, auditing package data. DO NOT USE FOR: supported-os.json changes (use update-supported-os skill), os-packages.json (legacy format).

Create the GitHub release discussion in dotnet/core and the locked mirror announcement issue in dotnet/announcements for a .NET preview, RC, or GA release. USE FOR: publishing release discussions after release notes exist, mirroring a newly created discussion into dotnet/announcements, verifying an existing post, and re-running a partially completed publication safely. DO NOT USE FOR: writing release notes, generating changes/features.json, or retrying create commands blindly after cancellation.

Update the HAL+JSON release information graph when new .NET releases ship. Regenerates index files across the version hierarchy (root → major → patch), timeline hierarchy (timeline → year → month), llms.json, and downloads using graph generator tools. USE FOR: adding a new patch release to the graph, adding a new major version, updating timeline entries after a release, refreshing the graph after source data changes. DO NOT USE FOR: supported-os.json changes (use update-supported-os skill), querying the graph (use dotnet-releases skill on release-index branch), editing generated graph files by hand (update source data and regenerate).

Apply the shared reader-centric rubric used to rank candidate features for release notes, blog posts, and docs. Use this when you need scoring and cut guidance independent of any one output format or task.

Generate `changes.json` for a .NET release milestone by selecting the correct VMR base/head refs and running `release-notes generate changes`. Handles preview-only multi-branch targeting (`main` vs release branches vs tags) and emits the authoritative manifest of what shipped. DO NOT USE FOR: API verification/diffs (use api-diff), feature scoring (use generate-features), or writing markdown release notes (use release-notes).

Generate `features.json` from `changes.json` by ranking and annotating shipped changes. `features.json` keeps the same schema as `changes.json` and adds optional scoring fields so release notes, docs, and blog posts can apply different cutoffs. Uses the shared `editorial-scoring` rubric. DO NOT USE FOR: regenerating VMR diffs (use generate-changes) or writing final markdown (use release-notes).

Review `features.json` scores and draft release notes against the editorial examples and the shared `editorial-scoring` rubric. Use it to identify over-scored, under-scored, or missing features before publishing release notes. DO NOT USE FOR: generating `changes.json` or writing the first draft.

Audit and update os-packages.json/md files that document required Linux packages for each .NET release. Uses the release-notes tool to verify package names against distro archives and regenerate markdown. USE FOR: adding packages for new distro versions, fixing incorrect package names, periodic package audits. DO NOT USE FOR: supported-os.json changes (use update-supported-os skill), editing os-packages.md directly (it is generated from JSON).

Audit and update supported-os.json/md files to reflect current OS version support. Uses the release-notes tool for automated verification against upstream lifecycle data and markdown regeneration. USE FOR: adding new OS versions, moving EOL versions to unsupported, periodic support matrix audits. DO NOT USE FOR: os-packages.json changes (use update-os-packages skill), editing supported-os.md directly (it is generated from JSON).

Validate releases and release links: URL liveness, file hashes, CDN latest.version files, and aka.ms redirect targets. Uses release-notes verify and generate commands against the local release-notes directory. USE FOR: validate the latest release, validate release links, validating that all download links return HTTP 200, verifying SHA512 hashes match downloaded content, checking CDN latest.version files match releases.json, checking aka.ms redirects point to the correct download URLs, regenerating releases-index.json and releases.md after source data changes. DO NOT USE FOR: editing releases.json or release.json (edit source data directly), graph regeneration (use update-release-graph skill), supported-os changes (use update-supported-os skill).

Download, inspect, and diff .NET APIs for a given build or release. Use `dotnet-inspect` to verify that APIs actually exist in the shipped packages, detect missed reverts, and generate before/after API diffs. Use `RunApiDiff.ps1` when a full markdown diff report is needed.