Refactor libraries-release-notes into shared release-notes skill

.github/copilot-instructions.md

@@ -81,6 +81,12 @@ 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 or RC release (supports team-specific context)
+
 ## Common Tasks
 
 ### Adding New Release Notes

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

@@ -0,0 +1,113 @@
+---
+name: release-notes
+description: Generate .NET release notes for a preview or RC release. Determines team context, gathers merged PRs, enriches with issue details, categorizes by impact, and produces formatted markdown. Use when asked to write, update, or draft release notes, a changelog, or a what's new summary for any .NET component.
+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: "[team] [owner/repo]"
+---
+
+# .NET Release Notes Generator
+
+Generate release notes for a .NET preview or RC release. This skill works for any .NET team that publishes release notes in the `dotnet/core` repository.
+
+## 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.** Do not run markdownlint, prettier, link checkers, or any other validation tool on the output. The outputs of this skill are the release notes markdown file and validated code sample apps.
+- **Maximize parallel tool calls.** Fetch multiple PR and issue details in a single response to minimize round trips.
+- **Follow [GitHub tool guidance](references/github-tools.md)** for all GitHub API interactions.
+
+## Process
+
+### Step 1: Identify team and collect inputs
+
+**[Process inputs](references/process-inputs.md)** — determine which team's release notes are being produced, then collect preview name, Code Complete dates, and output path.
+
+Once the team is identified, load the team context from `references/team-<team>.md`. The team context specifies:
+
+- Product name, component file, and repositories
+- PR discovery approach (area labels, milestones, or other strategies)
+- Content rules (what to include/exclude)
+- Categorization guidance
+- Community contributor details
+- Release branch verification overrides
+- Format overrides (document title, intro links, link format)
+- Optional process steps (e.g., API diff review)
+- Example release notes for reference
+
+Each process step below has a default approach defined in its reference file. **Team contexts can add to or override any step.** When a team context specifies an override, follow the team's instructions instead of (or in addition to) the defaults.
+
+Team contexts with defined references:
+
+| Team | Context file | Component file |
+|------|-------------|----------------|
+| Libraries | [team-libraries.md](references/team-libraries.md) | `libraries.md` |
+| ASP.NET Core | [team-aspnetcore.md](references/team-aspnetcore.md) | `aspnetcore.md` |
+| .NET SDK | [team-sdk.md](references/team-sdk.md) | `sdk.md` |
+
+Other teams can be added by creating a `references/team-<team>.md` file following the same structure.
+
+### Step 2: Data pipeline
+
+Gather the changes included in the release:
+
+1. **[Collect and filter PRs](references/collect-prs.md)** — search for merged PRs using the team context's PR discovery approach (area labels, milestones, or other strategy). Detect revert PRs and exclude both sides of within-release reverts; keep cross-release reverts as candidates since they represent user-visible changes. The team context overrides the default method when specified.
+2. **[Enrich — fetch PR and issue details](references/enrich-prs.md)** — fetch full PR bodies, discover linked issues, gather reactions and Copilot summaries.
+3. **API diff review** (optional) — if the team context specifies API diff review, follow [api-diff-review.md](references/api-diff-review.md) to cross-reference new APIs with candidate PRs.
+
+### Step 3: Verify scope
+
+Validate the candidate list:
+
+1. **[Deduplicate from previous release notes](references/dedup-previous-releases.md)** — ensure features aren't already covered in an earlier preview. Load the previous release notes for the team's component file (e.g., `libraries.md` for Libraries). **Retain these previous release notes in context** — they are needed during the authoring step for theme continuations.
+2. **[Confirm inclusion in release branch](references/verify-release-branch.md)** — spot-check that candidate changes shipped in the target preview. Uses the VMR by default; team contexts can override the repo, branch pattern, and verification steps.
+
+### Step 4: Author content
+
+Write the release notes:
+
+1. **[Categorize entries by area, theme, and impact](references/categorize-entries.md)** — group PRs into impact tiers using common criteria plus any team-specific guidance from the team context. Reference the previous release notes (loaded during deduplication) to identify **theme continuations** — features that build on work from prior previews should acknowledge the earlier coverage and describe what's new.
+2. **[Apply formatting rules](references/format-template.md)** — follow the standard .NET release notes document structure. Apply team context format overrides (document title, intro links, link format) when specified.
+3. **[Apply editorial rules](references/editorial-rules.md)** — follow attribution, benchmark, naming, and ranking guidelines. Apply team context content rules (e.g., bug fix exclusions, PR link policy) when specified.
+
+### Step 5: 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 in a `samples/` folder alongside the release notes file, and verify each sample compiles and runs. Fix any code samples in the release notes that fail validation (with user confirmation). A `.gitignore` at `release-notes/.gitignore` ensures the samples folders are not committed.
+
+### Step 6: Suggest reviewers
+
+**[Suggest reviewers](references/suggest-reviewers.md)** — gather authors, coauthors, assignees, and mergers from candidate PRs and present suggested reviewers grouped by area.
+
+### Step 7: Confirm and finalize
+
+Present the complete draft to the user:
+
+1. Feature list with categorization and ordering
+2. Suggested reviewers grouped by area
+3. Any unresolved items (ambiguous PRs, or for teams using API diff review, any unmatched API surface area)
+
+Get user confirmation before writing the output file.
+
+## Example usage
+
+**User prompt:**
+
+> Write the .NET Libraries release notes for .NET 11 Preview 2. The repo is dotnet/runtime.
+
+**Expected output:** A markdown file at `release-notes/11.0/preview/preview2/libraries.md` following the format:
+
+```markdown
+# .NET Libraries in .NET 11 Preview 2 - Release Notes
+
+.NET 11 Preview 2 includes new .NET Libraries features & enhancements:
+
+- [Support for Zstandard compression](#support-for-zstandard-compression)
+- [Faster time zone conversions](#faster-time-zone-conversions)
+...
+
+## Support for Zstandard compression
+
+The new `ZstandardStream` class brings native Zstandard compression
+support to `System.IO.Compression` ([dotnet/runtime#NNNNN](https://github.com/dotnet/runtime/pull/NNNNN)).
+...
+```

.github/skills/release-notes/references/api-diff-review.md

@@ -0,0 +1,65 @@
+# API Diff Review (Optional Step)
+
+> **This step is optional.** It applies only to teams whose team context specifies API diff review. Teams that produce components with significant public API surface (e.g., Libraries, WinForms, ASP.NET Core) benefit from cross-referencing new APIs with candidate PRs.
+
+## Locate the API diff
+
+Locate and load the API diff for the target release. The API diff provides context about which APIs were added or changed and significantly improves the quality of the generated release notes.
+
+The API diff lives under the `release-notes` folder within an `api-diff` subfolder for the target release. The team context specifies the exact path pattern. For example:
+* .NET 11 Preview 1: `release-notes/11.0/preview/preview1/api-diff/Microsoft.NETCore.App/11.0-preview1.md`
+* .NET 10 RC 2: `release-notes/10.0/preview/rc2/api-diff/Microsoft.NETCore.App/10.0-RC2.md`
+
+The API diff may not be available in the current branch yet. If the expected API diff path does not exist in the local clone, search for a pull request in `dotnet/core` that introduces the needed API diff:
+
+```
+search_pull_requests(
+  owner: "dotnet",
+  repo: "core",
+  query: "API diff <version> <preview>"
+)
+```
+
+If a PR with the API diff is found, fetch the diff files from that PR's branch. If no API diff is available from any source, warn the user and ask whether to proceed without it.
+
+## Load the API diff
+
+Once the API diff is located, load all of the API difference files under the appropriate subfolder. Read every diff file to understand the full set of APIs that have been added or changed in the release.
+
+## Cross-reference with candidate PRs
+
+After candidate PRs are collected (see [collect-prs.md](collect-prs.md)), cross-reference them against the new APIs. For each new API or namespace in the diff, verify that at least one candidate PR covers it. If an API in the diff has **no matching PR**, search for the implementing PR explicitly:
+
+```
+search_pull_requests(
+  owner: "<owner>",
+  repo: "<repo>",
+  query: "is:merged <API name or type name>"
+)
+```
+
+This catches PRs that were missed by the date range or that lacked a recognized area label. Add any discovered PRs to the candidate list.
+
+Also use the API diff to discover **issues** that drove new APIs. Many approved APIs originate from `api-approved` issues. Use `search_issues` to find related issues:
+
+```
+search_issues(
+  owner: "<owner>",
+  repo: "<repo>",
+  query: "label:api-approved <API name or type name>"
+)
+```
+
+If such issues exist, trace them to their implementing PRs and ensure those PRs are in the candidate list.
+
+## Unmatched API surface area
+
+After cross-referencing, if any substantial new APIs in the diff still cannot be correlated to a PR or issue, include a placeholder section in the release notes. Use a `**TODO**` marker so the author can manually resolve it later:
+
+```markdown
+## <New API or Feature Name>
+
+**TODO:** The API diff shows new surface area for `<Namespace.TypeName>` but the implementing PR/issue could not be found. Investigate and fill in this section.
+```
+
+Report these unmatched APIs during the [confirm and finalize](../SKILL.md) step so the user is aware.

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

@@ -0,0 +1,52 @@
+# 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 that share a common initiative, theme, or parent issue should 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 doesn't warrant coverage
+- **Preview feedback fixes**: Bug fixes or behavior changes made in response 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 (combined reaction + comment count on the backing issue):
+  - **50+ combined reactions and comments** on the backing issue → treat as a headline-level entry
+  - **10–49** → include as a standard entry in the preview feedback section
+  - **Under 10** → include as a brief mention unless the behavioral change is significant enough to warrant a fuller write-up
+
+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. If a candidate is part of a broader initiative, it may still deserve its own entry — the key question is whether a user can try it today. Features that are independently useful but part of a larger effort should note that context. Features that have no standalone value should be folded into a brief mention or omitted.
+
+The early previews (preview1 through preview5) tend to include more features, and the later previews (preview6, preview7, and rc1) tend to have fewer headline features and more quality improvements and small additions. The RC2 and GA releases typically have fewer changes so quality and performance improvements can be emphasized more.
+
+## Theme continuations
+
+Reference the previous release notes (loaded during [deduplication](dedup-previous-releases.md)) to identify features that build on work from prior previews. When a feature extends earlier work:
+
+- Acknowledge the earlier coverage briefly (e.g., "Building on the Zstandard support introduced in Preview 1...")
+- Focus on what's **new** in this preview
+- If the feature has evolved substantially, consider whether it warrants a fresh full write-up rather than just an update note
+
+## Multi-faceted PRs
+
+A single PR may span multiple categories — for example, a PR that rewrites an implementation may improve correctness, fix bugs, simplify the codebase, *and* deliver performance gains. Do not reduce such PRs to a single category. When writing the release notes entry, describe the full scope of the improvement. Read the full PR description, not just benchmark tables.
+
+## Team-specific categorization
+
+The team context may provide additional categorization guidance, such as:
+- Specific example release notes to follow for style reference
+- Additional tiers or groupings specific to the team's domain
+- Guidance on how to handle certain types of changes (e.g., API review outcomes)
+
+Follow the team context's guidance when it extends or overrides these common rules.