Add VMR-first, whole-product release notes skill

Redesigns the release notes skill with two key principles:

1. VMR-first: Diff dotnet/dotnet release branches to determine what
   shipped, then trace back to source repo PRs for context. This
   inherently handles reverts (reverted code doesn't appear in the
   diff) and ensures only shipped code gets documented.

2. Whole-product: One invocation produces release notes for ALL
   components (libraries, runtime, ASP.NET Core, SDK, etc.) rather
   than requiring per-team invocations.

Pipeline: VMR branch diff → component classification → source repo
PR tracing → enrichment → dedup → authoring → code sample validation
→ reviewer suggestions.

Borrows editorial rules, code sample validation, formatting, and
reviewer suggestion patterns from #10282, adapted for multi-component
and VMR-first architecture. Team context files provide editorial
overrides only, not PR discovery.

16 files: SKILL.md + 15 reference files (1354 total lines).

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Author: richlander

.github/copilot-instructions.md

@@ -81,6 +81,15 @@ git push origin [branch-name]
 - `release-notes/releases-index.json` - Master index of all .NET releases
 - `CONTRIBUTING.md` - Links to actual contribution guidelines in dotnet/runtime
 
+### Copilot Skills
+
+This repository defines Copilot skills in `/.github/skills/`. Before performing any task, check if a matching skill exists and follow its process. Current skills:
+
+- `release-notes` - Generate .NET release notes for a preview, RC, or GA release (VMR-first, whole-product)
+- `api-diff` - Generate API diff between .NET releases
+- `update-os-packages` - Update OS package definitions
+- `update-supported-os` - Update supported OS matrices
+
 ## Common Tasks
 
 ### Adding New Release Notes

.github/skills/release-notes/SKILL.md

@@ -0,0 +1,131 @@
+---
+name: release-notes
+description: Generate .NET release notes for a preview, RC, or GA release. Diffs VMR release branches to determine what shipped, traces changes to source repo PRs, and produces formatted markdown for all components. Use when asked to write, update, or draft release notes, a changelog, or a what's new summary for .NET.
+compatibility: Requires GitHub MCP server or gh CLI, SQL tool for structured storage, and access to the dotnet/core repository clone.
+disable-model-invocation: true
+argument-hint: "[version] [preview]"
+---
+
+# .NET Release Notes Generator
+
+Generate release notes for a .NET preview, RC, or GA release. This skill produces release notes for **all components** in a single invocation, using the VMR (`dotnet/dotnet`) as the source of truth for what shipped.
+
+## Design principles
+
+- **VMR is source of truth** — the VMR release branch determines what shipped. If code is not on the release branch, it does not get documented.
+- **Reverts are inherently handled** — reverted code does not appear in the VMR branch diff, so it never enters the pipeline.
+- **Whole product** — one invocation produces release notes for all components (libraries, runtime, ASP.NET Core, SDK, etc.).
+- **Team contexts are editorial** — they define formatting, categorization, and content rules, not PR discovery.
+
+## Execution guidelines
+
+- **Do not write intermediate files to disk.** Use the **SQL tool** for structured storage and querying (see [sql-storage.md](references/sql-storage.md) for schema).
+- **Do not run linters, formatters, or validators** on the output.
+- **Maximize parallel tool calls.** Fetch multiple PR and issue details in a single response.
+- **Follow [GitHub tool guidance](references/github-tools.md)** for all GitHub API interactions.
+
+## Process
+
+### Step 1: Collect inputs
+
+Collect inputs **one at a time** — ask a single question, wait for the answer, then ask the next:
+
+1. **Release name** (e.g., ".NET 11 Preview 3"). Parse the major version, prerelease label, and preview number.
+2. **Previous release name** (e.g., ".NET 11 Preview 2"). This determines the base VMR branch for comparison.
+3. **Code Complete dates** — start date (previous release's Code Complete) and end date (this release's Code Complete) in ISO 8601. These are used for source repo PR searches as a secondary discovery method.
+4. **Output directory** — path for the release notes files. Default: `release-notes/<version>/preview/<preview>/` (e.g., `release-notes/11.0/preview/preview3/`).
+
+After collecting inputs, determine the VMR release branch names using the patterns in [component-mapping.md](references/component-mapping.md).
+
+### Step 2: VMR diff
+
+**[Diff the VMR release branches](references/vmr-diff.md)** — compare the previous and current VMR release branches to identify all code changes that shipped in this release. Group changes by component using the [component mapping](references/component-mapping.md).
+
+This step produces:
+- A list of components with changes (and an estimate of change magnitude)
+- Components with no meaningful changes (these get minimal stub release notes)
+
+### Step 3: Trace to source repos
+
+**[Trace VMR changes to source repo PRs](references/trace-to-source.md)** — for each component with VMR changes, find the source repo PRs that introduced those changes. Uses both VMR commit analysis and source repo PR searches, but only includes PRs confirmed present in the VMR.
+
+### Step 4: Enrich
+
+**[Fetch PR and issue details](references/enrich-prs.md)** — for each candidate PR, fetch the full body, linked issues, reaction counts, and Copilot summaries. Collect reviewer data for the suggestion step.
+
+### Step 5: Deduplicate
+
+**[Check against prior release notes](references/dedup-previous-releases.md)** — for each component, verify that candidate features are not already covered in an earlier preview's release notes. **Retain prior release notes in context** for theme continuation detection during authoring.
+
+### Step 6: Author
+
+Write release notes for each component that has meaningful changes:
+
+1. **[Categorize entries by impact](references/categorize-entries.md)** — group PRs into impact tiers. Reference prior release notes for theme continuations.
+2. **[Apply formatting rules](references/format-template.md)** — follow the standard .NET release notes document structure. Apply team context format overrides when specified.
+3. **[Apply editorial rules](references/editorial-rules.md)** — follow attribution, benchmark, naming, and ranking guidelines. Apply team context content rules when specified.
+
+For components with team context files (see table below), load the team context and apply its editorial overrides. Components without team context files use default rules.
+
+| Component | Team context | Notes |
+|-----------|-------------|-------|
+| Libraries | [team-libraries.md](references/team-libraries.md) | Area-label categorization, API diff review |
+| ASP.NET Core | [team-aspnetcore.md](references/team-aspnetcore.md) | Product-area grouping, milestone-based community queries |
+| SDK | [team-sdk.md](references/team-sdk.md) | VMR-native changes |
+
+For components with no meaningful changes, produce a minimal stub:
+
+```markdown
+# <Component> in .NET <VERSION> <PREVIEW> - Release Notes
+
+There are no new features or improvements in <Component> in this release.
+```
+
+### Step 7: Validate code samples
+
+**[Validate code samples](references/validate-samples.md)** — extract every code sample from the authored release notes, scaffold file-based .NET console apps, and verify each compiles and runs. Fix any failing samples with user confirmation.
+
+### Step 8: Suggest reviewers and finalize
+
+**[Suggest reviewers](references/suggest-reviewers.md)** — aggregate PR authors, assignees, mergers, and coauthors into component-grouped reviewer suggestions.
+
+Present the complete draft to the user:
+
+1. List of components with release notes (and components with stubs)
+2. Feature list per component with categorization
+3. Suggested reviewers grouped by component
+4. Any unresolved items (unmatched VMR changes, ambiguous PRs)
+
+Get user confirmation before writing the output files.
+
+## Example usage
+
+**User prompt:**
+
+> Write the release notes for .NET 11 Preview 3.
+
+**Expected output:** Multiple markdown files under `release-notes/11.0/preview/preview3/`:
+
+- `libraries.md` — .NET Libraries features
+- `runtime.md` — Runtime improvements
+- `aspnetcore.md` — ASP.NET Core features
+- `sdk.md` — SDK tooling updates
+- `msbuild.md` — MSBuild improvements
+- `csharp.md` — C# language features
+- (etc. for each component with changes)
+- Minimal stubs for components with no changes
+
+Each file follows the format:
+
+```markdown
+# <Component> in .NET 11 Preview 3 - Release Notes
+
+.NET 11 Preview 3 includes new <Component> features & enhancements:
+
+- [Feature Name](#anchor)
+...
+
+## Feature Name
+
+<description with why + how + code sample> ([owner/repo#NNNNN](https://github.com/owner/repo/pull/NNNNN)).
+```

.github/skills/release-notes/references/categorize-entries.md

@@ -0,0 +1,48 @@
+# Categorize Entries by Area, Theme, and Impact
+
+## Feature grouping
+
+Group related features under a **single top-level section** rather than scattering them as separate entries. Features sharing a common initiative, theme, or parent issue appear as subsections (`###`) under one heading (`##`).
+
+**Signals that features should be grouped:**
+
+- They reference the same parent issue or initiative
+- They are in the same namespace or closely related namespaces
+- One feature is a prerequisite for another
+- They would be confusing or redundant as separate TOC entries
+
+## Impact tiers
+
+Group PRs into tiers:
+
+- **Headline features**: New namespaces or types, implementations of new industry trends/algorithms, major new API surfaces
+- **Quality**: PRs or groups of PRs that improve quality across an area
+- **Performance**: PRs with benchmark data showing measurable improvements
+- **Significant API additions**: Notable new API surface that unlocks new scenarios or provides meaningful productivity gains
+- **Small improvements**: Single-mapping additions and minor fixes with public API changes. Exclude unless the change is to a widely-used type (e.g., `string`, `Span<T>`, `HttpClient`) or resolves a highly-requested issue (10+ reactions). When in doubt, check whether you can write a meaningful code sample — if the only sample is trivially obvious, the entry likely does not warrant coverage
+- **Preview feedback fixes**: Bug fixes or behavior changes responding to community feedback on a previous preview. See [editorial-rules.md](editorial-rules.md#preview-to-preview-feedback-fixes) for inclusion criteria. Rank by community signal strength:
+  - **50+ combined reactions and comments** → treat as headline-level
+  - **10–49** → standard entry in preview feedback section
+  - **Under 10** → brief mention unless behavioral change is significant
+
+Only Headline, Quality, Performance, and significant API additions go into the release notes. Use judgment — a 2-line dictionary entry addition is less noteworthy than a new numeric type.
+
+**Before assigning a tier**, check each candidate against the [partial features and building blocks](editorial-rules.md#partial-features-and-building-blocks) heuristics. Features that are independently useful but part of a larger effort should note that context. Features with no standalone value should be folded into a brief mention or omitted.
+
+Early previews (preview1–preview5) tend to include more features. Later previews (preview6, preview7, rc1) have fewer headline features and more quality improvements. RC2 and GA releases emphasize quality and performance.
+
+## Theme continuations
+
+Reference the previous release notes (loaded during [deduplication](dedup-previous-releases.md)) to identify features building on prior preview work:
+
+- Acknowledge earlier coverage briefly (e.g., "Building on the Zstandard support introduced in Preview 1...")
+- Focus on what is **new** in this preview
+- Consider a fresh full write-up if the feature has evolved substantially
+
+## Multi-faceted PRs
+
+A single PR may span multiple categories. Do not reduce to a single category — describe the full scope. Read the full PR description, not just benchmark tables.
+
+## Team-specific categorization
+
+If a team context file exists for the component, apply its categorization guidance (specific tiers, groupings, or style references) alongside these common rules.

.github/skills/release-notes/references/component-mapping.md

@@ -0,0 +1,69 @@
+# Component Mapping
+
+Maps VMR (`dotnet/dotnet`) source paths to .NET components, their source repositories, and release notes output files.
+
+## Path-to-component mapping
+
+| VMR Path Prefix | Component | Source Repo | Release Notes File | Team Context |
+|----------------|-----------|-------------|-------------------|--------------|
+| `src/runtime/src/libraries/` | Libraries | `dotnet/runtime` | `libraries.md` | `team-libraries.md` |
+| `src/runtime/src/coreclr/` | Runtime | `dotnet/runtime` | `runtime.md` | — |
+| `src/runtime/src/mono/` | Runtime | `dotnet/runtime` | `runtime.md` | — |
+| `src/runtime/src/native/` | Runtime | `dotnet/runtime` | `runtime.md` | — |
+| `src/aspnetcore/` | ASP.NET Core | `dotnet/aspnetcore` | `aspnetcore.md` | `team-aspnetcore.md` |
+| `src/sdk/` | SDK | `dotnet/sdk` | `sdk.md` | `team-sdk.md` |
+| `src/msbuild/` | MSBuild | `dotnet/msbuild` | `msbuild.md` | — |
+| `src/winforms/` | Windows Forms | `dotnet/winforms` | `winforms.md` | — |
+| `src/wpf/` | WPF | `dotnet/wpf` | `wpf.md` | — |
+| `src/efcore/` | EF Core | `dotnet/efcore` | `efcore.md` | — |
+| `src/roslyn/` | C# / Visual Basic | `dotnet/roslyn` | `csharp.md`, `visualbasic.md` | — |
+| `src/fsharp/` | F# | `dotnet/fsharp` | `fsharp.md` | — |
+| `src/maui/` | .NET MAUI | `dotnet/maui` | `dotnetmaui.md` | — |
+
+### Classification rules
+
+1. **Longest prefix wins** — when classifying a file path, match against the longest matching prefix. For example, `src/runtime/src/libraries/System.Text.Json/...` matches Libraries, not Runtime.
+2. **Ignore non-source paths** — skip files under `src/*/eng/`, `src/*/test/`, `src/*/tests/`, `src/*/docs/`, and build infrastructure files (`.proj`, `.targets`, `.props` at the repo root level). These do not represent user-facing changes.
+3. **Containers** — container image changes do not come from the VMR diff. The `containers.md` release notes are authored separately based on container image announcements. Produce a stub unless the user provides container update information.
+4. **Roslyn split** — the `src/roslyn/` path covers both C# and Visual Basic. When tracing to source repo PRs, check PR labels and titles to determine whether a change is C#-specific, VB-specific, or applies to both. Produce separate `csharp.md` and `visualbasic.md` files.
+
+## VMR release branch naming
+
+The VMR (`dotnet/dotnet`) uses this branch naming pattern:
+
+```
+release/<MAJOR>.0.1xx-<prerelease-label>
+```
+
+The `1xx` is the SDK feature band (standard for the first SDK release of a major version).
+
+### Examples
+
+| Release | Branch Name |
+|---------|-------------|
+| .NET 11 Preview 1 | `release/11.0.1xx-preview1` |
+| .NET 11 Preview 2 | `release/11.0.1xx-preview2` |
+| .NET 11 Preview 7 | `release/11.0.1xx-preview7` |
+| .NET 11 RC 1 | `release/11.0.1xx-rc1` |
+| .NET 11 RC 2 | `release/11.0.1xx-rc2` |
+
+### Constructing branch names from inputs
+
+Given the release name (e.g., ".NET 11 Preview 3"):
+- Extract major version: `11`
+- Extract prerelease label: `preview3`
+- Construct: `release/11.0.1xx-preview3`
+
+If the expected branch is not found, list branches matching `release/<MAJOR>.0*` and ask the user to select the correct one.
+
+## Source repo PR search patterns
+
+When tracing VMR changes back to source repo PRs, use these repo-specific search strategies:
+
+| Source Repo | Primary Search | Filters |
+|------------|----------------|---------|
+| `dotnet/runtime` | Area labels (`area-System.*`) + date range | Exclude: `backport`, `servicing`, test-only |
+| `dotnet/aspnetcore` | Milestone (`<MAJOR>.0-preview<N>`) | Exclude: `backport`, test-only |
+| `dotnet/sdk` | Date range + title/path inspection | Exclude: `backport`, test-only |
+| `dotnet/roslyn` | Milestone + labels | Exclude: `backport`, test-only |
+| Others | Date range | Exclude: `backport`, `servicing`, test-only |

.github/skills/release-notes/references/dedup-previous-releases.md

@@ -0,0 +1,46 @@
+# Deduplicate Against Previous Release Notes
+
+Before authoring content, check that candidate features are not already covered in an earlier preview's release notes for the same major version. This check runs for **every component** that has candidates.
+
+## Load prior release notes
+
+For each component with candidates, load its release notes file from the immediately preceding release within the same major version. For example, when generating Preview 3, load Preview 2's notes for each component.
+
+When generating **Preview 1** for a new major version, check the prior major version's late-cycle notes (RC1, RC2, GA):
+
+```
+release-notes/<prev-major>/preview/rc1/<component>.md
+release-notes/<prev-major>/preview/rc2/<component>.md
+release-notes/<prev-major>/preview/ga/<component>.md
+```
+
+These files are in the local repository clone under `release-notes/`.
+
+**Retain the previous release notes in context** — they are needed in the [authoring step](categorize-entries.md) for identifying theme continuations.
+
+## Check for overlap
+
+For each candidate PR, check whether it (or its feature) already appears in prior release notes:
+
+- **PR number references** — search for `#<number>` or the full PR URL
+- **Feature names** — search for the API name, type name, or feature title
+
+Remove any PR whose feature is already covered. A PR merged in a prior date range but not included in those release notes may still be included — only exclude PRs whose features were actually written up.
+
+## Flag earlier PRs surviving dedup
+
+If any PRs were removed during dedup, review remaining candidates merged **before** the previous release's Code Complete date. Present these to the user:
+
+> The following PRs were merged before the previous Code Complete date but were **not** found in prior release notes. Confirm whether to include:
+>
+> - dotnet/runtime#12345 — `Add Foo.Bar overload` (merged 2025-11-15)
+> - dotnet/runtime#12400 — `Optimize Baz serialization` (merged 2025-12-03)
+
+If no PRs were removed during dedup, skip this sub-step.
+
+## Handle cross-preview features
+
+Some features span multiple PRs across previews:
+
+- If the new PR is a **substantial extension** (new overloads, new scenarios, significant perf improvement, breaking changes), include it as an update referencing the earlier work. Note the theme continuation for [authoring](categorize-entries.md).
+- If the new PR is a **minor follow-up** (bug fix, test addition, doc comment), skip it.