Today the Write Release Notes agentic workflow (.github/workflows/release-notes.md) produces a single PR per milestone containing every component''s markdown plus changes.json / features.json. That makes review hard: each component team has to scan a large diff for the parts they own, and edits from different teams collide on one branch.

Proposal

Emit one PR per component file so each team reviews and edits in isolation, with a small base PR for shared metadata and a final consolidation PR.

Branch layout per milestone (example: 11.0 Preview 4):

• release-notes/11.0-preview4 — base branch off main. Contains changes.json, features.json, README.md, build-metadata.json. One PR → main.
• release-notes/11.0-preview4-{component} — one branch per component file (aspnetcore, runtime, libraries, sdk, csharp, fsharp, efcore, winforms, wpf, msbuild, nuget, plus any others from component-mapping.md). Each branched off the base branch and PR''d back to it. Assigned to the component owner from the table in .github/prompts/createprs-for-preview.prompt.md.
• Consolidation PR: base branch → main, body lists every component PR.

Required changes

• .github/workflows/release-notes.md
  • PR creation step: emit per-component PRs instead of one combined PR.
  • Bump safe-outputs.create-pull-request.max and push-to-pull-request-branch.max from 5 to ~14.
• .github/skills/release-notes/SKILL.md + references/component-mapping.md — add branch-name and default-assignee columns; document per-file output routing.
• .github/skills/update-existing-branch/SKILL.md — generalize from "the milestone branch" to the set of per-component branches; refresh changes.json/features.json on the base branch only.
• Move the assignee table out of .github/prompts/createprs-for-preview.prompt.md into the skill so there''s one source of truth.

/cc @richlander @jeffhandley