Per-component release notes PRs in the release-notes skill (#10382)

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

@@ -18,11 +18,15 @@ This skill is the **editorial writing stage** of the pipeline. It turns a scored
 4. `api-diff` / `dotnet-inspect` verifies public APIs and confirms suspect features still exist in the shipped build
 5. `release-notes` writes curated markdown using the higher-value entries from `features.json`
 6. `review-release-notes` runs a final multi-model editorial QA pass against the scoring rubric and examples
-7. Output is one PR per release milestone in dotnet/core, maintained incrementally
+7. Output is a set of pull requests per release milestone in dotnet/core: a base PR that holds shared metadata (`changes.json`, `features.json`, `README.md`, `build-metadata.json`) and one PR per component file. Each component PR targets the base branch so component teams review and edit their file in isolation. See [`pr-layout.md`](references/pr-layout.md) for the full layout and naming scheme.
+
+## Local testing (no PRs)
+
+To dry-run the skill against a milestone, only create the branch set locally. Don't push the branches or create the PRs.
 
 ## Existing-branch reruns
 
-When the milestone branch already exists and contains drafted markdown, invoke
+When the milestone branch set already exists and contains drafted markdown, invoke
 [`update-existing-branch`](../update-existing-branch/SKILL.md). That shared
 skill is the canonical playbook for refreshing `changes.json`, merging the delta
 into `features.json`, integrating new material into existing sections, and
@@ -32,7 +36,8 @@ handling review comments without clobbering human edits.
 
 - [quality-bar.md](references/quality-bar.md) — what good release notes look like
 - [vmr-structure.md](references/vmr-structure.md) — VMR branches, tags, source-manifest.json
-- [../update-existing-branch/SKILL.md](../update-existing-branch/SKILL.md) — how to refresh a populated milestone branch incrementally
+- [pr-layout.md](references/pr-layout.md) — base + per-component branch layout
+- [../update-existing-branch/SKILL.md](../update-existing-branch/SKILL.md) — how to refresh a populated milestone branch set incrementally
 - [changes-schema.md](references/changes-schema.md) — the shared `changes.json` / `features.json` schema
 - [../editorial-scoring/SKILL.md](../editorial-scoring/SKILL.md) — the reusable scoring rubric and cut guidance
 - [feature-scoring.md](references/feature-scoring.md) — how to score and cut features

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

@@ -4,21 +4,34 @@
 
 Uses the `repo` field from `changes.json` (which matches `source-manifest.json` `path` values) to identify components.
 
-| Manifest Path | Component | Source Repo | Release Notes File |
-| ------------- | --------- | ----------- | ------------------ |
-| `runtime` | .NET Libraries | `dotnet/runtime` | `libraries.md` |
-| `runtime` | .NET Runtime | `dotnet/runtime` | `runtime.md` |
-| `aspnetcore` | ASP.NET Core | `dotnet/aspnetcore` | `aspnetcore.md` |
-| `razor` | ASP.NET Core (Razor) | `dotnet/razor` | `aspnetcore.md` |
-| `sdk` | .NET SDK | `dotnet/sdk` | `sdk.md` |
-| `templating` | .NET SDK (Templating) | `dotnet/templating` | `sdk.md` |
-| `msbuild` | MSBuild | `dotnet/msbuild` | `msbuild.md` |
-| `winforms` | Windows Forms | `dotnet/winforms` | `winforms.md` |
-| `wpf` | WPF | `dotnet/wpf` | `wpf.md` |
-| `efcore` | EF Core | `dotnet/efcore` | `efcore.md` |
-| `roslyn` | C# / Visual Basic | `dotnet/roslyn` | `csharp.md` |
-| `fsharp` | F# | `dotnet/fsharp` | `fsharp.md` |
-| `nuget-client` | NuGet | `nuget/nuget.client` | `nuget.md` |
+| Manifest Path | Component | Source Repo | Release Notes File | Default Assignee(s) |
+| ------------- | --------- | ----------- | ------------------ | ------------------- |
+| `runtime` | .NET Libraries | `dotnet/runtime` | `libraries.md` | @artl93 @jeffhandley @SamMonoRT @karelz |
+| `runtime` | .NET Runtime | `dotnet/runtime` | `runtime.md` | @richlander |
+| `aspnetcore` | ASP.NET Core | `dotnet/aspnetcore` | `aspnetcore.md` | @danroth27 |
+| `razor` | ASP.NET Core (Razor) | `dotnet/razor` | `aspnetcore.md` | @danroth27 |
+| `sdk` | .NET SDK | `dotnet/sdk` | `sdk.md` | @baronfel |
+| `templating` | .NET SDK (Templating) | `dotnet/templating` | `sdk.md` | @baronfel |
+| `msbuild` | MSBuild | `dotnet/msbuild` | `msbuild.md` | @baronfel |
+| `winforms` | Windows Forms | `dotnet/winforms` | `winforms.md` | @KlausLoeffelmann @merriemcgaw |
+| `wpf` | WPF | `dotnet/wpf` | `wpf.md` | @harshit7962 @adegeo |
+| `efcore` | EF Core | `dotnet/efcore` | `efcore.md` | @SamMonoRT @roji |
+| `roslyn` | C# / Visual Basic | `dotnet/roslyn` | `csharp.md` | @BillWagner |
+| `fsharp` | F# | `dotnet/fsharp` | `fsharp.md` | @T-Gro |
+| `nuget-client` | NuGet | `nuget/nuget.client` | `nuget.md` | @baronfel |
+
+Each release notes file gets its own per-component branch named `release-notes/{version}-{milestone-slug}-{file-stem}`, where `{file-stem}` is the release notes filename without `.md` (for example, `aspnetcore.md` → `release-notes/11.0-preview4-aspnetcore`). See [`pr-layout.md`](pr-layout.md) for the full branching scheme.
+
+The agent assigns each component PR to its default assignee(s) when opening the PR (`gh pr create --assignee ...`), so the right team sees it in their review queue.
+
+### Components contributed out-of-band (not in the VMR)
+
+These components ship with .NET but live outside the VMR, so `changes.json` won't contain entries for them. The agent still creates a stub PR for each so the component team can push their own content (or close the PR if there is nothing noteworthy this milestone).
+
+| Component | Source Repo | Release Notes File | Default Assignee(s) |
+| --------- | ----------- | ------------------ | ------------------- |
+| .NET MAUI | `dotnet/maui` | `dotnetmaui.md` | @davidortinau |
+| Containers | `dotnet/dotnet-docker` | `containers.md` | @lbussell |
 
 ### Runtime sub-component classification
 
@@ -77,5 +90,7 @@ winforms.md            # Windows Forms
 wpf.md                 # WPF
 msbuild.md             # MSBuild
 nuget.md               # NuGet client
+dotnetmaui.md          # .NET MAUI (team-authored, not in VMR)
+containers.md          # Containers (team-authored, not in VMR)
 changes.json           # Machine-readable change manifest
 ```

.github/skills/release-notes/references/editorial-rules.md

@@ -95,12 +95,15 @@ At the bottom of each component's notes, list ALL external contributors — not
 
 **Vet the list** — the `community-contribution` label is sometimes wrong. Exclude usernames containing `-msft`, `-microsoft`, or other Microsoft suffixes. When in doubt about whether someone is a Microsoft employee, leave them out of the community list.
 
+**Scope `dotnet/aspnetcore` links to the milestone.** That repo tags every PR with a release milestone (e.g. `11.0-preview4`), so the contributor link should append `+milestone%3A<slug>` to limit it to this milestone's contributions. Look up the exact slug with `gh pr view <pr> --repo dotnet/aspnetcore --json milestone`. Most other source repos don't apply milestones consistently — for those, omit the filter and link to the author's merged PRs without scope.
+
 ```markdown
 ## Community contributors
 
 Thank you contributors! ❤️
 
-- [@username](https://github.com/<owner>/<repo>/pulls?q=is%3Apr+is%3Amerged+author%3Ausername)
+- [@username](https://github.com/dotnet/aspnetcore/pulls?q=is%3Apr+is%3Amerged+author%3Ausername+milestone%3A<slug>)
+- [@username](https://github.com/<other-owner>/<other-repo>/pulls?q=is%3Apr+is%3Amerged+author%3Ausername)
 ```
 
 ## Bug fixes section

.github/skills/release-notes/references/pr-layout.md

@@ -0,0 +1,29 @@
+# PR Layout
+
+Each release-notes milestone produces a **set of pull requests** instead of one large PR, so each component team reviews its own file in isolation.
+
+## Branch set per milestone
+
+- **Base branch** `release-notes/{version}-{milestone-slug}` (e.g. `release-notes/11.0-preview4`) — holds the shared metadata for the milestone (`README.md`, `changes.json`, `features.json`, `build-metadata.json`). Its PR targets `main`.
+- **Component branch** `release-notes/{version}-{milestone-slug}-{file-stem}` (e.g. `release-notes/11.0-preview4-aspnetcore` for `aspnetcore.md`) — holds only that component's `{file-stem}.md`. Its PR targets the base branch.
+
+The set of components and their release notes files is defined in [`component-mapping.md`](component-mapping.md). Components with no noteworthy changes still get a stub PR.
+
+## Invariants
+
+- `changes.json`, `features.json`, `build-metadata.json`, and `README.md` live on the **base branch only**. Component branches never modify them; they rebase or merge from the base branch to pick up refreshed metadata.
+- Each `{component}.md` lives on its **matching component branch only**. The agent never edits another component's file from the wrong branch.
+- The milestone landing page `{version}.md` (for example, `11.0.0-preview.4.md`) is **not produced by this skill**. The .NET release team generates it through separate artifacts-publishing automation, so the agent leaves it alone on every branch.
+
+## Merge flow
+
+Each component PR merges into the base branch. When all component PRs merge, the base PR's diff is the full milestone — there is no separate consolidation PR.
+
+## PR title convention
+
+- Base PR: `[release-notes] .NET {version} {milestone-label}` (e.g. `[release-notes] .NET 11 Preview 4`).
+- Component PR: `[release-notes] {Component name} in .NET {version} {milestone-label}` (e.g. `[release-notes] ASP.NET Core in .NET 11 Preview 4`).
+
+## Draft state
+
+Open both the base PR and every component PR as **drafts** (`gh pr create --draft`). Component teams promote their PR to ready-for-review once they've vetted the AI-authored content (including any `<!-- TODO -->` placeholders). The base PR stays a draft until the milestone ships.